Visor de CSR

El Visor de CSR analiza Certificate Signing Requests codificadas en PEM y muestra toda la información que aparecerá en el certificado resultante -- campos del sujeto, SANs, detalles de la clave pública y algoritmo de firma -- para que puedas detectar errores antes de enviar a una Autoridad Certificadora. Pega un CSR que comience con -----BEGIN CERTIFICATE REQUEST----- y revisa al instante cada campo.

Entendiendo los Certificate Signing Requests

Un Certificate Signing Request es la solicitud formal que envías a una Autoridad Certificadora cuando necesitas un nuevo certificado. Contiene tu información de identidad (nombre de dominio, detalles de la organización), tu clave pública y una lista de extensiones solicitadas como Subject Alternative Names. El CSR se firma con tu clave privada para demostrar que posees el par de claves correspondiente. La CA revisa esta información, verifica tu identidad a través de validación de dominio o validación de organización, y emite un certificado basado en el contenido del CSR.

Lo crítico que debes entender es que una vez que se emite un certificado, corregir errores es costoso. Si enviaste un CSR con un error tipográfico en el Common Name, una entrada SAN faltante o el algoritmo de clave incorrecto, necesitarás generar un nuevo CSR, reenviarlo y esperar a que la CA lo procese nuevamente. Para certificados de Domain Validation a través de Let's Encrypt, esto es un inconveniente menor. Para certificados de Organization Validation o Extended Validation de CAs comerciales, la reemisión puede tomar días y puede involucrar costos adicionales. Verificar el CSR antes del envío siempre vale los treinta segundos que toma.

Este visor decodifica el CSR y presenta cada campo en formato legible. Puedes verificar que el Common Name coincida con tu dominio previsto, que todos los Subject Alternative Names estén presentes y correctamente escritos, que el algoritmo y tamaño de clave cumplan tus requisitos, y que el algoritmo de firma sea actual. El visor también señala problemas potenciales como tamaños de clave débiles, algoritmos obsoletos o entradas SAN faltantes que podrían causar problemas durante la emisión.

Cómo ver un Certificate Signing Request

1. Pega tu CSR codificado en PEM (que comienza con -----BEGIN CERTIFICATE REQUEST-----)
2. El visor extrae y muestra todos los campos del CSR
3. Revisa los detalles del sujeto, SANs, información de clave y cualquier advertencia de validación
4. Verifica la precisión antes de enviar el CSR a tu CA

Ejemplo de salida de CSR

Pegando un CSR multi-dominio típico:

Subject:
  Common Name (CN):  www.example.com
  Organization (O):  Example Inc.
  Locality (L):      San Francisco
  State (ST):        California
  Country (C):       US

Requested SANs:
  DNS: www.example.com
  DNS: example.com
  DNS: api.example.com
  DNS: cdn.example.com

Public Key:
  Algorithm:  RSA
  Key Size:   2048 bits

Signature:
  Algorithm:  SHA-256 with RSA

Verificaciones de validación de clave

El visor señala problemas potenciales automáticamente:

Cuándo usar esta herramienta

• Verificación previa al envío -- revisa un CSR antes de enviarlo a una Autoridad Certificadora, especialmente para certificados EV (Extended Validation) u OV (Organization Validation) costosos donde la reemisión cuesta tiempo y dinero
• Auditoría automatizada de CSRs -- verifica que los CSRs generados por clientes ACME, Terraform, Ansible u otras herramientas de automatización contengan los dominios y detalles de organización correctos
• Depuración de fallos en emisión de certificados -- cuando una CA rechaza un CSR, inspecciónalo para identificar claves débiles, campos faltantes o problemas de formato
• Revisión de equipo -- audita CSRs creados por otros miembros del equipo antes de que se envíen, asegurando que las convenciones de nombres y cobertura de dominios sean correctas
• Comparación del CSR con el certificado emitido -- verifica que la CA emitió un certificado que coincide con lo solicitado
• Verificación de algoritmo de clave -- confirma si un CSR usa RSA o ECDSA antes de enviar, especialmente al migrar tipos de clave

Cómo funcionan los Certificate Signing Requests

Un CSR es un mensaje enviado por un solicitante a una Autoridad Certificadora para solicitar un certificado de identidad digital. El CSR contiene:

1. Subject Distinguished Name -- identifica quién solicita el certificado (campos CN, O, OU, L, ST, C)
2. Clave pública -- la clave pública del solicitante que será incrustada en el certificado
3. Extensiones solicitadas -- atributos adicionales como Subject Alternative Names
4. Firma -- el CSR se firma con la clave privada del solicitante, demostrando que posee el par de claves correspondiente

Generando un CSR con OpenSSL

Un comando típico de generación de CSR:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=Example Inc./CN=www.example.com"

Para CSRs con SANs, necesitas un archivo de configuración de OpenSSL que especifique la extensión subjectAltName, o usa la bandera -addext:

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

CSR vs. certificado

Mejores prácticas para revisión de CSR

El error más común en CSR es olvidar incluir el Common Name en los Subject Alternative Names. Desde Chrome 58 (lanzado en 2017), los navegadores ignoran completamente el campo CN para la validación de nombre de host y solo verifican los SANs. Si tu CSR tiene CN=www.example.com pero no tiene una entrada SAN DNS:www.example.com, el certificado emitido producirá errores de discrepancia de nombre de host en todos los navegadores modernos. Siempre asegúrate de que cada dominio que deba estar cubierto aparezca como una entrada SAN, incluyendo el propio CN.

Otro problema frecuente es generar un CSR con una clave demasiado pequeña. Las CAs no emitirán certificados para claves RSA menores a 2048 bits, y algunos marcos de cumplimiento requieren RSA de 4096 bits o ECDSA P-384. Si tus herramientas de automatización tienen tamaños de clave por defecto, verifícalos antes de desplegar en producción. Regenerar un CSR con una clave más grande es simple; descubrir el problema después de que el certificado ha sido emitido y desplegado no lo es.

Para equipos que usan herramientas de infraestructura como código como Terraform o Ansible para generar CSRs, incorpora un paso de verificación en tu pipeline. Haz que el CSR se analice y valide automáticamente antes de enviarlo a la CA. Esto detecta desviaciones de configuración, sustituciones de variables incorrectas y errores de plantilla que de otro modo resultarían en certificados con dominios incorrectos o SANs faltantes. Una verificación de una línea que confirme que la lista de CN y SAN del CSR coincide con los valores esperados puede ahorrar horas de solución de problemas.

Preguntas frecuentes

¿Puede una CA cambiar lo que está en mi CSR? Sí. La CA controla lo que va en el certificado final. Para certificados DV, las CAs típicamente eliminan los campos de organización y solo mantienen el CN y los SANs. Para certificados OV/EV, la CA verifica y puede ajustar los detalles de la organización. La CA siempre establece el período de validez, número de serie y campos del emisor. Revisar tanto tu CSR como el certificado emitido es una buena práctica.

¿Por qué mi CSR muestra SHA-256 with RSA pero lo generé con una clave ECDSA? El algoritmo de firma en el CSR refleja cómo se firmó el CSR mismo, lo que depende de tu tipo de clave. Una clave ECDSA produce ecdsa-with-SHA256 o similar. Si ves sha256WithRSAEncryption, tu clave es RSA. Verifica la sección de clave pública para confirmar que el algoritmo y tamaño de clave coincidan con tus expectativas.

¿Necesito incluir SANs en el CSR, o puede la CA agregarlos? Esto depende de la CA. La mayoría de las CAs modernas te permiten especificar SANs durante el proceso de pedido, incluso si no están en el CSR. Sin embargo, incluir SANs en el CSR es una buena práctica porque documenta tu intención y es requerido por algunas CAs. Siempre verifica que el certificado emitido incluya todos los SANs esperados.

¿Cómo verifico que un CSR y una clave privada coincidan? Extrae la clave pública tanto del CSR como de la clave privada, luego compáralas. Con OpenSSL: openssl req -in csr.pem -noout -pubkey y openssl pkey -in key.pem -pubout. Si la salida es idéntica, el CSR fue generado con esa clave privada. El Public Key Extractor también puede ayudar con esta comparación.

¿Cuál es la diferencia entre PKCS#10 y un Certificate Signing Request? Son lo mismo. PKCS#10 (RFC 2986) es el estándar formal que define el formato del CSR. Cuando las herramientas se refieren a una "solicitud PKCS#10" o un "CSR", se refieren a la misma estructura de datos. El header PEM -----BEGIN CERTIFICATE REQUEST----- se usa para CSRs PKCS#10.

¿Puedo reusar un CSR después de que el certificado expire? Técnicamente sí, si todavía tienes la clave privada correspondiente. Sin embargo, la mejor práctica es generar un nuevo par de claves y CSR para cada renovación. Esto limita la ventana de exposición si la clave privada fue comprometida en algún momento durante el tiempo de vida del certificado anterior.

Herramientas relacionadas

• X.509 Certificate Viewer - Ve los detalles del certificado emitido para comparar con el CSR original
• Public Key Extractor - Extrae la clave pública tanto del CSR como del certificado para verificar que coincidan
• SAN Extractor - Extrae SANs del certificado emitido para confirmar que todos los dominios solicitados están cubiertos
• Certificate Fingerprint Generator - Genera huellas digitales para el certificado emitido
• Certificate Expiry Checker - Verifica el período de validez del certificado emitido