Decodificador de certificados X.509

¿La herramienta me dice si un certificado es válido para un dominio concreto?

No, y esta es la limitación más importante antes de usarla. La herramienta solo lee y muestra los campos que ya vienen dentro de un certificado X.509; no reproduce ninguno de los pasos que un navegador real ejecuta al abrir una conexión HTTPS. Un navegador reconstruye toda la cadena de confianza hasta una raíz que ya tiene guardada, revisa las Basic Constraints y el Key Usage de cada intermedio para confirmar que tenía permiso de firmar el siguiente eslabón, y además consulta el estado de revocación vía OCSP o CRL. Aquí no ocurre nada de eso: no hay ninguna lista de raíces incluida, no se hace ninguna petición de red para preguntar "¿este certificado sigue vigente?", y no hay validación de ruta (path validation) de ningún tipo. Pegas un certificado, y la herramienta responde exactamente una pregunta — "qué dice este certificado de sí mismo" — nunca "si debería confiarse en él". Para responder eso segundo, la vía correcta es openssl verify con el bundle de CA adecuado, o simplemente abrir el dominio en un navegador real y mirar el candado.

¿Por qué la herramienta marca algunos certificados como "Autofirmado"? ¿Es siempre mala señal?

La etiqueta viene de una sola comparación: el campo issuer es idéntico al campo subject, y la firma fue generada con la propia clave privada del certificado en lugar de la de una CA distinta. La herramienta intenta primero llamar a cert.isSelfSigned() de la biblioteca @peculiar/x509 para verificarlo con la firma real; si el WebCrypto del navegador no soporta ese algoritmo de firma en particular, cae a un método más simple — comparar la cadena subject contra la cadena issuer, el mismo respaldo que usan los propios navegadores. Ser autofirmado es completamente normal en un certificado raíz de CA (la cima de cualquier cadena de confianza tiene que autofirmarse por definición) y en certificados internos que uno mismo genera para pruebas. Solo es una señal preocupante en un contexto específico: si un navegador muestra una advertencia de seguridad para un sitio público y el certificado recibido es autofirmado, significa que ninguna CA reconocida lo avaló, y no hay tercero confirmando que el servidor es quien dice ser.

Cuando subo un archivo con varios bloques BEGIN CERTIFICATE, ¿en qué orden los lee?

Exactamente en el orden en que aparecen en el archivo, ni más ni menos. La herramienta busca cada bloque -----BEGIN CERTIFICATE-----...-----END CERTIFICATE----- con una expresión regular, los decodifica uno por uno, y los muestra etiquetados "Certificado 1 de N", "Certificado 2 de N" siguiendo ese mismo orden de lectura — no reordena nada según relaciones issuer/subject. Esto importa en la práctica: la convención habitual al armar un fullchain.pem es certificado hoja primero, luego cada intermedio, y la raíz al final (o sin incluirla, porque el cliente ya la tiene). Si tu archivo se ensambló en un orden distinto, la herramienta te mostrará fielmente ese orden equivocado en vez de corregirlo en silencio — lo cual la hace útil precisamente para detectar una cadena mal armada.

¿Qué archivo sube distinto a pegar el PEM directamente en el cuadro de texto?

El cuadro de texto siempre trata el contenido como PEM — texto ASCII envuelto en -----BEGIN CERTIFICATE-----. Al subir un archivo, en cambio, la herramienta no confía en la extensión: la mayoría de archivos .cer/.crt/.der son DER binario, pero también existen no pocos archivos PEM en texto plano guardados con esas mismas extensiones por error. La solución es leer todos los bytes del archivo, intentar decodificarlos como UTF-8, y comprobar si el resultado contiene -----BEGIN CERTIFICATE-----. Si lo contiene, se procesa igual que la ruta de pegar PEM (incluyendo separar varios bloques si es una cadena); si no, el buffer binario completo se pasa directo a X509Certificate de @peculiar/x509 como DER. Esta detección por contenido es más segura que fiarse de la extensión, y por eso renombrar un .pem a .crt sigue funcionando sin problema.

¿En qué se diferencian las huellas SHA-1 y SHA-256, y cuál debería usar?

Una huella (fingerprint) es un hash de los bytes DER crudos del certificado — sirve para identificar exactamente un certificado concreto, igual que un checksum identifica un archivo exacto. Dos certificados con la misma huella son idénticos byte a byte; con volver a emitir un certificado con el mismo subject ya cambia la huella por completo. La herramienta calcula ambas con cert.getThumbprint('SHA-1') y cert.getThumbprint('SHA-256'), y las muestra en hexadecimal en mayúsculas separado por dos puntos, el formato que usa casi cualquier otra herramienta. SHA-1 se sigue mostrando porque bastante documentación antigua, configuraciones de certificate pinning y herramientas legacy todavía la referencian, pero SHA-1 en sí está roto para propósitos que requieren resistencia a colisiones y no debería usarse para nada crítico de seguridad de aquí en adelante. SHA-256 es la que hay que usar para comparar contra logs de certificate transparency, configuraciones de pinning modernas, o cualquier herramienta escrita en los últimos años.

¿Cómo se calculan los "días restantes" y qué significan Key Usage / Extended Key Usage?

Los días restantes se calculan de la diferencia entre el campo notAfter del certificado y el momento exacto en que decodificaste, convertida a la zona horaria que reporta el propio objeto Date de tu navegador — normalmente tu hora local, no UTC. Por eso dos personas en zonas horarias distintas viendo el mismo certificado pueden ver una cifra distinta en un día, simplemente porque la medianoche UTC ya pasó localmente para una y no para la otra; si algo necesita precisión al segundo (un script de renovación automática, por ejemplo), compara siempre contra el notAfter crudo en UTC, no contra la cuenta de días redondeada. Key Usage es una máscara de bits de nueve indicadores según RFC 5280 (Digital Signature, Key Encipherment, Certificate Signing…) que quien emitió el certificado incrusta para declarar qué operaciones puede hacer la clave; Extended Key Usage acota el propósito aún más con OIDs concretos como "TLS Server Authentication" o "Code Signing". La herramienta trae una tabla con seis OIDs de EKU comunes; un OID que no esté en esa tabla se muestra igual en su forma numérica cruda en vez de ocultarse.