Inspeccionar una CSR o un certificado X.509

Distinguir los formatos

Una solicitud de firma de certificado (CSR) contiene un sujeto y una clave pública, firmados por el solicitante. Un certificado X.509 emitido también incluye emisor, número de serie, periodo de validez y extensiones. Una CSR no tiene un periodo de validez asignado por el emisor. Ambos pueden aparecer como texto PEM con datos DER codificados en Base64.

Examinar los campos

Abra el decodificador X.509 y CSR y pegue un bloque PEM completo. Conserve las etiquetas BEGIN y END. CERTIFICATE identifica un certificado; CERTIFICATE REQUEST, una CSR. El analizador lee la estructura ASN.1 localmente, sin instalar OpenSSL.

-----BEGIN CERTIFICATE REQUEST-----
(base64 DER data)
-----END CERTIFICATE REQUEST-----

Comprobar el resultado

Compare el sujeto con la identidad prevista. En un certificado, revise emisor, fechas y nombres alternativos cuando existan. Examine algoritmo y tamaño de la clave pública. En una CSR, compruebe la identidad solicitada antes de enviarla a la autoridad certificadora. Decodificar no valida una cadena, comprueba revocaciones ni demuestra la seguridad de un sitio.

Separar las claves privadas

Nunca pegue un bloque PRIVATE KEY. Los certificados públicos pueden revelar nombres internos o información de la organización: comparta ejemplos. La IA opcional es independiente y puede enviar datos fuera del navegador tras el consentimiento. Compruebe la disponibilidad sin conexión antes de depender de una instalación guardada en caché.

Puntos de Control Normativos (RFC 2986 y RFC 5280)

Al diagnosticar certificados PKI y fallos de enlace TLS en producción, tenga en cuenta estas reglas criptográficas:

1. Nombres Alternativos del Sujeto (SAN) frente a CN: Los navegadores modernos (RFC 5280 y RFC 6125) descartan el uso del atributo clásico commonName. Si su CSR o certificado no incluye una extensión subjectAltName con los dominios o direcciones IP, los clientes rechazarán la conexión con ERR_CERT_COMMON_NAME_INVALID.
2. Prueba de Posesión (POP): En una solicitud CSR PKCS#10 válida (RFC 2986), la clave privada firma la estructura CertificationRequestInfo. El decodificador verifica esta autofirma para asegurar que el solicitante posee realmente la clave privada correspondiente antes de remitir la solicitud a una Autoridad de Certificación (CA).
3. Restricciones de Uso Extendido de Clave (EKU): Compruebe los identificadores OID para garantizar que el certificado declare serverAuth (1.3.6.1.5.5.7.3.1) para servidores web o clientAuth (1.3.6.1.5.5.7.3.2) para arquitecturas mTLS.