Analizador de CSR

¿Por qué analizar un CSR antes de enviarlo?

Un decodificador de CSR muestra campos. Responde a «qué hay en este archivo», nunca a la pregunta que se plantea antes de pagar un certificado: ¿lo va a aceptar mi autoridad de certificación y, si no, por qué?

La diferencia es medible. Un Common Name ausente de los SAN, un wildcard colocado sobre *.co.uk, un guion bajo en un nombre DNS, un nombre en .local, una dirección IP privada en los SAN, o ningún SAN en absoluto: otras tantas solicitudes que una autoridad pública rechaza y que los decodificadores del mercado muestran sin decir palabra.

Este analizador decodifica el CSR por completo y luego contrasta cada dato medido con los CA/Browser Forum Baseline Requirements y con los RFC aplicables. Emite un veredicto de tres estados, conforme, advertencia o no conforme, con los hallazgos y su fuente. El catálogo cuenta con 59 códigos; el número de controles ejecutados depende del CSR analizado.

Tres usos que se repiten:

• Antes del envío: corregir los puntos bloqueantes y enviar una sola vez el CSR correcto.
• Al recibir el certificado: comprobar que procede realmente de ese CSR, con la huella de clave pública como prueba.
• Al retomar una PKI heredada: localizar nombres internos, claves cortas y campos prohibidos.

Qué contiene un CSR

Un Certificate Signing Request es un objeto ASN.1 definido por el RFC 2986, codificado en DER y transportado en base64 dentro de un sobre PEM. Lleva tres cosas:

• una clave pública, RSA o de curva elíptica, y solo ella;
• unos identificadores solicitados: el sujeto (CN, O, L, ST, C) y, dentro de un atributo PKCS#9 llamado extensionRequest, las extensiones deseadas, entre ellas los SAN;
• una firma producida con la clave privada correspondiente.

Los SAN no son, por tanto, un campo de primer nivel: viajan dentro de un atributo. Eso explica que una configuración de openssl incompleta produzca un CSR sin un solo SAN sin que nada proteste.

Qué hace realmente tu autoridad de certificación con el CSR

Aquí está el punto que casi todos los decodificadores pasan por alto: la autoridad reconstruye el certificado, no copia el CSR. Genera ella misma el authorityInformationAccess, el authorityKeyIdentifier, las certificatePolicies, el extKeyUsage e incluso el subjectAltName del certificado emitido. Un solo campo se reproduce byte a byte: el SubjectPublicKeyInfo, tu clave pública y su identificador de algoritmo.

Esto dicta la severidad de cada hallazgo, y es el calibrado central de la herramienta. Un contenido solo pasa a bloqueante si hace imposible un certificado conforme: clave fuera de perfil, clave comprometida, identificador ilícito, o violación del RFC 2986 por parte del propio CSR. Todo lo que la autoridad sobrescribe o ignora, una unidad organizativa o una extensión exótica, se queda como mucho en advertencia.

Qué demuestra la firma y qué no demuestra

La firma de un CSR establece una cosa: en el momento de fabricarlo, su autor poseía la clave privada asociada a la clave pública, y el trío sujeto, clave y atributos no se ha movido desde entonces. No demuestra ningún control del dominio, ninguna autoridad del solicitante, ninguna prueba de actualidad (PKCS#10 no lleva marca de tiempo) y ninguna exclusividad: la clave puede andar suelta en un repositorio público.

Una firma inválida no interrumpe el análisis, es un hallazgo más, y la causa suele ser benigna: truncamiento al copiar y pegar, CSR recodificado por el panel de un proveedor de alojamiento. La herramienta distingue tres estados y no dos, válida, inválida y no verificable; nunca acusa de manipulación a un CSR que no ha sabido verificar.

Los rechazos que una simple decodificación no ve

El CN debe figurar en los SAN

El Common Name es opcional y está desaconsejado en los perfiles actuales. Pero si está presente, debe reproducir exactamente uno de los valores del subjectAltName: un CN que no aparece en ninguna parte de los SAN hace que el certificado no sea conforme.

Un caso muy parecido es aún más común, el CSR sin ningún SAN. Con un CN, depende de una reconstrucción benévola por parte de la autoridad, algo que hay que evitar. Sin CN ni SAN, la autoridad no tiene nada que validar y el rechazo es seguro.

Las dos capas de reglas sobre los wildcards

La capa sintáctica viene del RFC 9525: un solo wildcard, único contenido de la etiqueta más a la izquierda. *.captaindns.com es válido; *.*.captaindns.com y www*.captaindns.com no lo son, y un cliente conforme debe ignorar el nombre. El certificado se emitiría y luego resultaría inservible.

La capa política viene de los Baseline Requirements: una autoridad debe rechazar un wildcard colocado sobre un sufijo público de la sección ICANN, *.co.uk por ejemplo. En la sección privada de esa misma lista, el rechazo es solo una recomendación, de ahí una simple advertencia.

Recordatorio que suele olvidarse: un wildcard solo baja un nivel. *.captaindns.com no cubre ni captaindns.com ni a.b.captaindns.com.

Los nombres internos ya no se pueden emitir desde 2015

servidor.local, intranet.corp, nas.lan, localhost, una etiqueta única sin punto, o un TLD ausente de la zona raíz: son nombres internos. Su emisión está prohibida desde el 1 de noviembre de 2015 y los certificados existentes fueron revocados de oficio el 1 de octubre de 2016. Aun así, siguen apareciendo en CSR procedentes de antiguas PKI internas, reciclados hacia una autoridad pública.

Misma lógica para las direcciones IP reservadas en los SAN, ya sean del RFC 1918, de loopback, de enlace local, de CGNAT o ULA: una autoridad no valida lo que no puede alcanzar. Novedad: desde el 15 de marzo de 2026, un nombre que termina en .in-addr.arpa o .ip6.arpa también está prohibido.

La unidad organizativa ha desaparecido de los certificados

El campo organizationalUnit está prohibido desde el 1 de septiembre de 2022, en aplicación del ballot SC047v2 adoptado el 29 de junio de 2021; la referencia habitual al «ballot SC62» es inexacta. La autoridad no rechaza el CSR por ello, elimina el campo, de ahí una advertencia.

Una dirección de correo en el sujeto está obsoleta según el RFC 5280 y no tiene ningún uso legítimo en un certificado TLS de servidor. Y un punto contraintuitivo: un sujeto vacío es conforme, e incluso moderno. El perfil de validación de dominio solo acepta el país, opcional, y el Common Name, desaconsejado.

Tamaños de clave, algoritmos y claves ya comprometidas

RSA 2048 sigue siendo conforme: 3072 bits es una recomendación con horizonte 2030, señalada a título informativo. Una firma en SHA-1 no es bloqueante en el sentido de los Baseline Requirements, cuya cláusula anti-SHA-1 apunta a los objetos firmados por una autoridad y no por el suscriptor; se clasifica como advertencia, con el matiz de que en la práctica las autoridades la rechazan desde 2016.

Dos controles van más lejos. Son los únicos puntos de los Baseline Requirements donde está escrito que la autoridad debe rechazar la solicitud:

• ROCA (CVE-2017-15361): las claves RSA producidas por una biblioteca muy extendida en tarjetas inteligentes y TPM tienen una estructura reconocible que reduce drásticamente su entropía. La detección no factoriza nada, es una prueba de huella sobre el módulo.
• Claves débiles de Debian (CVE-2008-0166): entre septiembre de 2006 y mayo de 2008, un generador de aleatoriedad roto redujo el espacio de claves a unas pocas decenas de miles de valores por tamaño. La lista va incorporada en el servicio y se consulta fuera de línea.

En ambos casos, hay que regenerar el par de claves entero: reutilizar la misma clave en un CSR nuevo arrastraría la debilidad.

La huella SPKI, la que empareja todo lo demás

Todos los decodificadores muestran una «huella» del CSR. Es el hash del archivo entero: cambia si regeneras el CSR con la misma clave, y no guarda ninguna relación con el certificado que vas a recibir.

La huella que sirve es la del SubjectPublicKeyInfo, definida por el RFC 7469: el hash SHA-256 de la estructura de clave pública codificada en DER. Como es el único campo copiado byte a byte, el mismo valor aparece en el CSR, en el certificado emitido y en la clave privada correspondiente, y sobrevive a una reemisión.

Tres usos inmediatos: emparejar un certificado recibido con su CSR, sin comparar sujetos que la autoridad ha reescrito de todas formas; comprobar en local que tu clave privada es la correcta, con el comando que aparece más abajo; componer un registro DANE 3 1 1, cuyo selector 1 es exactamente esa huella, que el verificador DANE/TLSA comprueba después en el DNS. La huella se publica en hexadecimal y en base64.

Comparar el CSR con el certificado desplegado

Opción facultativa, desmarcada por defecto: indica un host y el analizador recupera el certificado que sirve realmente, y luego compara las dos huellas SPKI. Tres casos, misma clave, otra clave, o host inaccesible, siendo este último el más frecuente ya que un CSR se analiza antes de la emisión.

Es el único camino de red de la herramienta: casilla desmarcada, ninguna conexión saliente. El resultado nunca entra en el veredicto de conformidad, porque lo que está desplegado en otro sitio no dice nada de la validez de una solicitud, y nada del CSR se transmite al host.

Para juzgar el propio certificado desplegado, cadena de confianza y vencimiento incluidos, la herramienta dedicada es el SSL Certificate Checker. Después viene la gestión del ciclo de vida de los certificados, más aún cuando la duración de validez baja a 47 días de aquí a 2029.

Comandos openssl útiles

Archivo san.cnf, sin el cual openssl produce un CSR sin ningún SAN:

[ req ]
prompt = no
distinguished_name = dn
req_extensions = v3_req
[ dn ]
CN = www.captaindns.com
[ v3_req ]
subjectAltName = @alt
[ alt ]
DNS.1 = www.captaindns.com
DNS.2 = captaindns.com

# RSA 3072
openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf

# ECDSA P-256
openssl ecparam -name prime256v1 -genkey -noout -out captaindns.key
openssl req -new -key captaindns.key -out captaindns.csr -config san.cnf

Calcular la huella SPKI del CSR, del certificado recibido y de la clave privada, y luego comprobar que las tres coinciden, sin enviar nada a ninguna parte:

openssl req  -in captaindns.csr -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl x509 -in captaindns.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl pkey -in captaindns.key -pubout       | openssl pkey -pubin -outform DER | openssl dgst -sha256

Para un dominio internacionalizado, escribe la forma punycode (prefijo xn--) en los SAN: el analizador muestra la forma Unicode al lado y nunca invalida una etiqueta xn-- correcta.

Confidencialidad

No pegues nunca tu clave privada, aquí ni en ningún otro sitio: un CSR solo lleva la clave pública. Una cabecera PEM de clave privada se detecta antes de cualquier envío y el análisis se rechaza en el acto. Si la clave ya se ha pegado en un formulario web, considérala comprometida y regenera el par.

El CSR, en cambio, no es un secreto: lleva identificadores destinados a figurar en un certificado, publicado después en los registros de Certificate Transparency. Se procesa en memoria para analizarlo y mostrarlo. Única excepción, el valor del atributo challengePassword no se devuelve nunca, ni se muestra ni se registra: solo se señala su presencia.

FAQ - Preguntas frecuentes

P: ¿Qué es un CSR (Certificate Signing Request)?

R: Un archivo PKCS#10, transportado en PEM, que lleva tu clave pública, los identificadores solicitados (sujeto y SAN) y una firma producida con la clave privada correspondiente. Nunca contiene la clave privada. Se lo entregas a una autoridad de certificación, que comprueba tu control de los dominios y luego emite el certificado.

P: ¿Por qué una autoridad de certificación rechaza un CSR?

R: Casi siempre un Common Name ausente de los SAN, un wildcard mal formado o colocado sobre un sufijo público, un carácter ilegal en un nombre DNS (el guion bajo el primero de todos), un nombre interno en .local o .corp, una dirección IP privada en los SAN, una clave por debajo de 2048 bits, o la ausencia total de SAN.

P: ¿El Common Name debe figurar en los SAN?

R: Sí, siempre que esté presente: los Baseline Requirements exigen que reproduzca exactamente uno de los valores del subjectAltName. Lo más sencillo es no rellenarlo, ya que los navegadores llevan años leyendo únicamente los SAN.

P: Mi CSR está firmado en SHA-1, ¿es bloqueante?

R: No en el sentido de los Baseline Requirements: la cláusula que prohíbe SHA-1 apunta a los objetos firmados con la clave privada de una autoridad, y un CSR lo firma el suscriptor. La herramienta lo clasifica como advertencia. En la práctica, las autoridades públicas rechazan los CSR en SHA-1 desde 2016, así que regenéralo en SHA-256. MD5 y MD2 sí son bloqueantes.

P: ¿Hay que rellenar los campos O, OU, L y ST del sujeto?

R: No para un certificado de validación de dominio: el perfil solo acepta el país, opcional, y el Common Name, desaconsejado. Un sujeto vacío es perfectamente conforme. La unidad organizativa está incluso prohibida desde el 1 de septiembre de 2022.

P: ¿Para qué sirve la huella SPKI?

R: Es el hash SHA-256 de la estructura de clave pública, el único campo que una autoridad copia byte a byte del CSR al certificado. Demuestra que un CSR, un certificado recibido y una clave privada llevan la misma clave, y sirve de selector 1 en un registro DANE TLSA. La huella que publican los demás decodificadores se calcula sobre el archivo entero y no permite ninguna de estas comprobaciones.

P: ¿El certificado ya en línea corresponde a mi CSR?

R: Marca la opción de comparación e indica el host. El analizador recupera el certificado servido y compara su huella SPKI con la del CSR: misma clave, otra clave, o host inaccesible. Esta comparación nunca influye en el veredicto de conformidad y no transmite nada del CSR al host consultado.

P: ¿Cómo generar un CSR con SAN usando openssl?

R: Crea un archivo de configuración que liste DNS.1, DNS.2, etc., y luego ejecuta openssl req -new -newkey rsa:3072 -nodes -keyout captaindns.key -out captaindns.csr -config san.cnf. Para una clave elíptica, genera primero la clave con openssl ecparam -name prime256v1 -genkey -noout y después llama a openssl req -new -key. Sin ese archivo, openssl produce un CSR sin ningún SAN.

Herramientas complementarias

Recursos útiles

• RFC 2986 - sintaxis de solicitud de certificación (estructura PKCS#10 del CSR)
• RFC 9525 - verificación de identidad de servicio (reglas de wildcard, sustituye al RFC 6125)
• RFC 7469 - fijación de clave pública (definición normativa de la huella SPKI)
• CA/Browser Forum - Baseline Requirements (reglas de emisión de los certificados TLS)