14.4.4. Certificados firmados por una CA (de confianza pública)

Los certificados autofirmados funcionan cuando controlas ambos extremos. Si, en cambio, clientes arbitrarios (navegadores, teléfonos, software de terceros) deben conectarse a la cámara sin que se les indique que confíen en un certificado personalizado, el certificado tiene que estar firmado por una Autoridad de Certificación (CA) pública en la que esos clientes ya confíen. El código TLS de la cámara es idéntico al del caso autofirmado (load_cert_chain con un certificado y una clave en formato DER); solo cambia la forma de obtener ese certificado.

El punto más importante de todos: la clave privada la generas tú mismo y nunca sale de tu máquina. La CA nunca la ve. Lo que envías a la CA es una solicitud de firma de certificado (CSR), un pequeño archivo que contiene tu clave pública y tu nombre de dominio, y lo que recibes de vuelta es un certificado (tu clave pública y tu nombre, firmados por la CA). La clave y el certificado son dos archivos distintos producidos por dos pasos distintos; la CA solo maneja la mitad pública.

El flujo general, todo realizado en una máquina normal (nunca en la cámara):

  1. Consigue un nombre de dominio. Las CA públicas certifican un nombre DNS que controles (p. ej. cam.example.com); no emitirán para una dirección IP a secas ni para un nombre solo local como mycam.

  2. Genera una clave y una CSR. Un solo comando de OpenSSL produce la clave privada y la CSR correspondiente. Usa el mismo tipo de clave que usarías para un certificado autofirmado (consulta Conceptos: confianza, claves y formato de archivo); se recomienda ECDSA P-256.

    ECDSA P-256 – recomendado:

    openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    ECDSA P-384 – más fuerte, más grande/lento:

    openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    RSA-2048 – máxima compatibilidad:

    openssl req -new -newkey rsa:2048 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

    Mantén domain.key en secreto: este es el archivo de clave que finalmente pondrás en la cámara. domain.csr es el archivo que entregas a la CA; no contiene secretos.

  3. Envía la CSR y demuestra que controlas el dominio. Aquí es donde difieren las dos vías habituales:

    • Una CA ACME automatizada como Let’s Encrypt, manejada con una herramienta como certbot o acme.sh, hace los pasos 2 y 3 por ti: genera la clave, construye la CSR, responde el desafío automáticamente (HTTP-01: servir un token por el puerto 80 del dominio, o DNS-01: publicar un registro TXT en su DNS) y escribe los archivos finalizados.

    • Una CA comercial (comprada directamente o a través de un revendedor de dominios/alojamiento): pegas el texto de domain.csr en un formulario web, y luego demuestras el control respondiendo a un correo de validación, publicando un registro DNS o colocando un archivo en un servidor web de ese dominio. Una vez validado, descargas los archivos emitidos.

  4. Recopila los archivos emitidos. Para entender lo que recibes, ayuda saber que los certificados forman una cadena de confianza: el certificado de tu dominio está firmado por una CA intermedia, que a su vez está firmada por una CA raíz. Cada eslabón avala al que tiene debajo. Acabas con:

    • Tu clave privada (del paso 2). La CA nunca la tuvo; permanece en tu máquina y es la clave que finalmente pondrás en la cámara.

    • El certificado de hoja, también llamado certificado de entidad final o de servidor. Es el certificado de tu dominio específico (cam.example.com): contiene tu clave pública y tu nombre, y está firmado por el intermedio de la CA. Este es el certificado que la cámara presenta para identificarse.

    • Uno o varios certificados de CA intermedia (la «cadena» o «paquete de CA»). Una CA no firma tu hoja directamente con su raíz (la clave de la raíz se mantiene fuera de línea y muy protegida), sino que firma con un intermedio, que a su vez está firmado por la raíz. El intermedio es el eslabón que conecta tu hoja hasta la raíz.

    El certificado raíz es el ancla de confianza: un certificado autofirmado perteneciente a la CA que se sitúa en la cima de la cadena. No te lo entregan y nunca lo despliegas, porque todos los clientes ya lo tienen: los sistemas operativos, los navegadores, los teléfonos y los entornos de ejecución de los lenguajes vienen con un «almacén de confianza» integrado de certificados raíz. Un cliente confía en tu hoja recorriendo la cadena: ya confía en la raíz, la raíz avala el intermedio y el intermedio avala tu hoja. (Este es exactamente el trabajo que hace tu único server.der / cafile en el caso autofirmado: allí tú eres tu propia raíz.)

    Un archivo de cadena completa (fullchain) es simplemente la hoja y el/los intermedio(s) concatenados en un único archivo, la hoja primero, deliberadamente sin la raíz (enviar la raíz es inútil: un cliente solo confía en las raíces que ya tiene). Un servidor normal presenta toda esta cadena completa para que cualquier cliente pueda recorrerla. La cámara no puede: carga y presenta un certificado (la hoja) y no puede enviar además el/los certificado(s) intermedio(s) que te dio la CA.

    Nombres de archivo que verás en la práctica: una herramienta ACME como certbot escribe privkey.pem (tu clave), cert.pem (solo la hoja), chain.pem (solo el/los intermedio(s)) y fullchain.pem (hoja + intermedio(s)). Una CA comercial suele darte un .crt para la hoja y un .ca-bundle para el/los intermedio(s), siendo el .key el que generaste tú mismo.

  5. Convierte y copia. Convierte la clave privada y el certificado de hoja a DER y cópialos en la cámara exactamente como en Certificados autofirmados. La cámara los presenta entonces como su certificado de servidor y los clientes estándar aceptan la conexión automáticamente, porque ya confían en la CA: no se necesita ninguna configuración del lado del cliente.

Truco

En la práctica, el hecho de que la cámara presente solo la hoja (y nunca los intermedios) se traduce en lo siguiente:

  • Los clientes que ya tienen el intermedio de la CA en caché (los navegadores y las bibliotecas HTTPS más extendidos suelen tenerlo) completan la cadena por sí mismos y se conectan bien.

  • Los clientes que dependen de que el servidor proporcione el intermedio fallarán en el handshake contra la cámara.

Si todos los clientes posibles deben tener éxito, no termines TLS público directamente en la cámara. Coloca delante de ella una puerta de enlace / proxy inverso que sirva la cadena completa al mundo exterior, y haz que el proxy llegue a la cámara mediante el flujo autofirmado descrito arriba.