Decodificador CSR

Qué contiene un CSR y qué no

Una solicitud de firma de certificado (CSR) contiene tres cosas: el sujeto con el que pides que se te identifique, la mitad pública de tu par de claves y las extensiones que solicitas, sobre todo los nombres alternativos del sujeto (SAN). Va firmada con tu clave privada, lo que demuestra a la autoridad de certificación (CA) que realmente posees la clave que le pides certificar.

No contiene la clave privada, y nada en ella permite derivarla. Por eso un CSR no es un secreto como lo es una clave, y es razonable pegarlo en una herramienta. Pero tampoco es irrelevante: describe nombres de host, una organización y a veces convenciones internas de nombres, así que conviene saber si el decodificador que usas lo envía a algún sitio. Muchos lo hacen, porque la mayoría los gestionan empresas que venden certificados.

También conviene saber qué poco del CSR llega al final. La CA valida los nombres y emite un certificado con su propio número de serie, sus fechas de validez, su emisor y su propio criterio sobre qué extensiones deben figurar. Los campos de organización y ubicación salen de los registros validados por la CA, no de lo que escribiste. En la práctica, lo que se conserva son la clave pública y los nombres.

El Common Name está obsoleto; lo que importa son los SAN

Por motivos históricos, el common name del sujeto parece el campo que da nombre al sitio, y hace años que no funciona así. Chrome dejó de tenerlo en cuenta en 2017, el resto de navegadores le siguió, y el CA/Browser Forum exige que cada nombre que cubre un certificado figure en la extensión subject alternative name. Un certificado con CN y sin SAN lo rechazan todos los clientes actuales, diga lo que diga el CN.

Así que la lista de SAN es el primer campo que hay que leer, y debe incluir todos los nombres de host que el certificado va a servir, incluido el dominio sin www si también se sirve. Los comodines cubren exactamente una etiqueta: *.example.com coincide con www.example.com, pero no con example.com ni con a.b.example.com.

En un CSR es fácil pasar por alto los SAN, y muchos decodificadores lo hacen. En un certificado emitido son una extensión de primer nivel; en una solicitud van anidados dentro de un atributo extensionRequest, dos niveles más abajo. Esta herramienta mira en el lugar correcto, así que si aquí la lista aparece vacía, el CSR realmente no los tiene, y conviene corregirlo antes de enviarlo.

Cómo leer un certificado

Más allá del sujeto y la validez, unas cuantas extensiones determinan lo que un certificado puede hacer, y ahí suelen estar las respuestas interesantes.

Basic constraints indica si es un certificado de CA. CA:TRUE en un certificado final es una emisión incorrecta grave; CA:FALSE es lo que debe mostrar un certificado de servidor. Key usage y extended key usage limitan para qué puede usarse la clave - serverAuth para un servidor TLS, clientAuth para TLS mutuo - y un certificado sin el uso que espera el cliente será rechazado aunque todo lo demás esté bien.

Authority information access contiene la URL del certificado emisor, con la que algunos clientes reparan una cadena incompleta, y la URL del respondedor OCSP. Las marcas de tiempo de certificate transparency muestran que el certificado se registró públicamente, algo que hoy exigen los navegadores. Los identificadores de clave de la autoridad y del sujeto son lo que realmente se compara al construir la cadena, y son más fiables que comparar a ojo las cadenas de emisor y sujeto.

Para las huellas digitales, usa preferentemente SHA-256; SHA-1 se muestra solo porque muchas consolas y configuraciones de pinning todavía lo imprimen. Ambas se calculan sobre la codificación DER y coinciden con lo que muestra openssl.

Problemas de cadena

El fallo de certificado más habitual no está en el certificado. Está en la cadena: un servidor que funciona en un navegador de escritorio y falla en curl, en una app móvil o en un cliente JVM.

Un servidor debe presentar su propio certificado más todos los intermedios hasta la raíz, sin incluirla. Los navegadores suelen tapar un intermedio que falta descargándolo desde la URL de authority information access o usando uno que tienen en caché de otro sitio, así que el problema es invisible para quien prueba en Chrome e inmediato para todo lo demás. Enviar también la raíz no hace daño, pero no sirve de nada: el cliente ya la tiene o no confía en ella.

El orden importa en la cadena TLS clásica: primero el certificado final y después cada emisor por turno. Si pegas aquí una cadena completa, se decodifica cada bloque por separado en el orden indicado, lo que deja claro si falta un intermedio o está mal colocado. Compara el emisor de cada certificado con el sujeto del siguiente y revisa también las fechas de caducidad de los intermedios: también caducan, y un intermedio caducado inutiliza un certificado final perfectamente válido.

Generar la solicitud y la clave que hay detrás

Un CSR siempre se produce junto con un par de claves, y la clave es la parte que de verdad importa. El comando habitual genera ambos a la vez: openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr. La opción -nodes deja la clave sin cifrar, que es lo que un servidor web necesita para arrancar sin pedir una frase de contraseña, y también la razón por la que ese archivo solo debe poder leerlo la cuenta de servicio.

RSA de 2048 bits sigue siendo el valor por defecto seguro en términos de compatibilidad. ECDSA sobre la curva P-256 da una seguridad equivalente con claves mucho más pequeñas y handshakes más rápidos, se genera con openssl ecparam -genkey -name prime256v1, y todos los navegadores actuales lo aceptan. Algunos middleboxes antiguos y clientes Java heredados no lo hacen, y ese es el único argumento real que le queda a RSA.

Los subject alternative names son el campo que la gente olvida, porque las preguntas interactivas no lo piden. Hay que aportarlos mediante un archivo de configuración o con la opción -addext, como en -addext "subjectAltName=DNS:example.com,DNS:www.example.com". Una solicitud sin ellos será rechazada o, peor aún, dará lugar a un certificado que ningún navegador va a aceptar.

La emisión automatizada cambió el flujo de trabajo

El ciclo manual - generar un CSR, pegarlo en el portal de un proveedor, esperar, descargar un certificado, instalarlo y repetir al año siguiente - hoy es la excepción. El protocolo ACME, que Let's Encrypt presentó en 2016, automatiza todo el intercambio: un cliente demuestra que controla el dominio, envía un CSR y recibe un certificado, normalmente en segundos y sin intervención humana.

El control del dominio se demuestra de una de tres maneras. HTTP-01 sirve un token en una ruta well-known, lo que exige que el puerto 80 sea alcanzable. DNS-01 publica un registro TXT y es el único método que puede emitir comodines y el único que funciona para un host sin servidor web público. TLS-ALPN-01 responde a un handshake especial en el puerto 443, útil cuando solo ese puerto está abierto.

Los certificados emitidos así son válidos durante 90 días por diseño, bajo la idea de que una vida corta limita el daño de una clave filtrada y obliga a que la renovación esté automatizada en lugar de depender de que alguien se acuerde. Los clientes renuevan alrededor de los dos tercios de la vigencia, de modo que un fallo tiene tiempo de detectarse antes de que algo caduque.

Niveles de validación, comodines y qué demuestra un certificado

La validación de dominio solo demuestra que quien pidió el certificado controlaba el dominio en ese momento. Las validaciones de organización y extendida añaden comprobaciones sobre la entidad legal que hay detrás, que aparecen en los campos de sujeto del certificado emitido. Los navegadores dejaron hace años de darle a EV cualquier tratamiento especial en su interfaz, así que hoy la diferencia práctica es sobre todo contractual y de procedimiento, más que algo que un visitante pueda ver.

Un comodín cubre exactamente una etiqueta: *.example.com coincide con www y api, pero no con example.com en sí ni con a.b.example.com. Por eso la mayoría de los certificados comodín incluyen el dominio a secas como SAN adicional. Los comodines también concentran el riesgo, porque el compromiso de una sola clave afecta a todos los hosts bajo ese nombre, y no pueden emitirse sin control del DNS.

Nada de esto dice nada sobre si el sitio es de fiar. Un certificado significa que la conexión está cifrada y que el nombre coincide; nunca ha significado que el operador sea honesto. Los sitios de phishing tienen certificados válidos como cosa normal, y por eso las interfaces de los navegadores dejaron de insinuar lo contrario.

La caducidad es un problema operativo, no del certificado

Las caídas provocadas por certificados caducados son tan frecuentes que forman un género propio: han tumbado redes de pagos, operadoras móviles y consolas de nube. El certificado hizo exactamente aquello para lo que fue diseñado; lo que falló fue el proceso a su alrededor.

El monitoreo debería alertar por los días restantes y no por el fallo, con un umbral lo bastante amplio para poder actuar: dos semanas para un certificado de 90 días, un mes para uno de un año. Vigila el endpoint y no el archivo, porque el certificado que importa es el que el servidor está presentando de verdad, y revisa también los intermedios: también caducan, y un intermedio caducado rompe un certificado final perfectamente válido.

Los registros de certificate transparency te regalan un inventario. Todo certificado de confianza pública queda registrado, así que una búsqueda por tu dominio muestra lo que existe, incluidos certificados que otra persona de la organización emitió y olvidó comentarte.

Leer la cadena cuando algo no funciona

El comando aislado más útil es openssl s_client -connect host:443 -servername host, que muestra lo que el servidor presenta en lugar de lo que dice tu archivo de configuración. La cadena que imprime debería empezar por el certificado final y seguir con cada emisor por orden, y la línea de issuer de cada certificado debería coincidir con la línea de subject del siguiente.

Un intermedio ausente es el fallo clásico, y resulta invisible en un navegador de escritorio, porque los navegadores descargan el certificado que falta o lo tienen en caché de otro sitio. Curl, las aplicaciones móviles y los clientes de la JVM no lo hacen, así que el síntoma es un sitio que funciona para quien lo está probando y falla para una parte grande del tráfico real.

Cuando la cadena parece correcta y aun así la conexión falla, lo siguiente que hay que revisar son las extensiones de key usage, si el cliente confía siquiera en la raíz, y el reloj del cliente: un dispositivo con la fecha mal puesta rechazará un certificado perfectamente válido por considerarlo aún no vigente.