Respuesta breve. Un cliente TLS identifica a un servidor solo por el Subject Alternative Name (nombre alternativo del sujeto): las entradas dNSName e iPAddress, nunca por el Common Name (nombre común) del sujeto. Key Usage (uso de clave) dice qué puede hacer la clave desde el punto de vista matemático (firmar, cifrar, firmar certificados); Extended Key Usage (uso extendido de clave) dice para qué aplicación (serverAuth, clientAuth, firma de código). Basic Constraints con CA:TRUE es lo que permite a un certificado emitir otros; un certificado hoja tiene CA:FALSE. Authority Key Identifier y Subject Key Identifier son pistas que ayudan al cliente a encontrar el emisor, no comprobaciones de seguridad. CRL Distribution Points y Authority Information Access indican al cliente dónde comprobar la revocación y de dónde descargar un certificado intermedio que falta; los certificados de Let's Encrypt ya no llevan URL de OCSP. Las SCT demuestran que el certificado se registró en Certificate Transparency, algo que exigen Chrome y Safari.
Cómo obtener un certificado real para examinarlo
openssl s_client -showcerts muestra todos los certificados que envía el servidor; openssl x509 -text decodifica uno. Las pruebas se hicieron en debian:forky-20261005-slim con OpenSSL 3.6.5 y pyca/cryptography 49.0.0:
openssl s_client -connect letsencrypt.org:443 -servername letsencrypt.org -showcerts </dev/null 2>/dev/null \
| awk '/-----BEGIN CERTIFICATE-----/{n++; f=sprintf("letsencrypt.org-%d.pem", n); p=1} p{print >> f} /-----END CERTIFICATE-----/{p=0; close(f)}'
openssl x509 -in letsencrypt.org-1.pem -noout -text
-servername envía SNI; sin él, muchos servidores devuelven un certificado predeterminado emitido para otro nombre. El certificado hoja de letsencrypt.org, tal como se servía ese día (la clave pública se muestra completa; las firmas de las dos SCT están abreviadas):
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
05:43:93:3b:e3:86:b3:a2:b3:ad:d5:34:f2:10:3b:c8:b6:5f
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=US, O=Let's Encrypt, CN=YE2
Validity
Not Before: Sep 4 14:34:32 2026 GMT
Not After : Dec 3 14:34:31 2026 GMT
Subject: CN=letsencrypt.org
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:e9:e5:40:7b:43:1e:46:b9:8e:45:e4:aa:cb:40:
ab:e6:3f:99:27:b8:b7:81:e3:32:56:e7:14:74:5f:
fa:43:5b:52:c6:a6:b5:66:c5:56:0e:07:21:56:e3:
4c:fe:35:55:4f:f0:92:2f:eb:22:4a:f1:7a:39:51:
39:04:c2:b3:0d
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
16:68:8D:1E:2A:32:48:8C:B5:F1:10:0A:16:08:37:08:3B:9D:30:23
X509v3 Authority Key Identifier:
B9:59:F2:8E:CF:22:F0:86:D3:37:48:FF:76:14:18:BA:82:D8:55:87
Authority Information Access:
CA Issuers - URI:http://ye2.i.lencr.org/
X509v3 Subject Alternative Name:
DNS:cp.letsencrypt.org, DNS:cp.root-x1.letsencrypt.org, DNS:cps.letsencrypt.org, DNS:cps.root-x1.letsencrypt.org, DNS:lencr.org, DNS:letsencrypt.com, DNS:letsencrypt.org, DNS:www.lencr.org, DNS:www.letsencrypt.com, DNS:www.letsencrypt.org
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://ye2.c.lencr.org/96.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : D8:09:55:3B:94:4F:7A:FF:C8:16:19:6F:94:4F:85:AB:
B0:F8:FC:5E:87:55:26:0F:15:D1:2E:72:BB:45:4B:14
Timestamp : Sep 4 15:33:02.377 2026 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:D0:2E:25:A4:9D:7F:C8:18:D6:7B:5E:...
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 46:AF:86:3D:3B:3E:E5:9F:A5:77:DE:A8:24:5D:36:B0:
D9:ED:22:A2:23:F4:61:77:41:22:94:52:EE:95:50:5F
Timestamp : Sep 4 15:33:02.552 2026 GMT
Extensions: 00:00:05:00:24:DF:DB:0C
Signature : ecdsa-with-SHA256
30:44:02:20:31:2F:83:D6:42:65:26:0D:58:D7:DD:C3:...
Signature Algorithm: ecdsa-with-SHA384
Signature Value:
30:65:02:31:00:ee:1d:b0:7c:35:88:98:15:57:b8:88:73:23:
92:a9:bf:40:bf:e8:ae:02:48:e6:f4:7a:2d:18:fc:43:52:d3:
80:9a:ff:ce:e0:2a:0d:4a:29:e6:80:a2:94:f5:4f:14:d9:02:
30:35:08:99:3b:bc:89:5b:23:a0:ef:64:24:e2:b2:b3:b8:c2:
d8:d5:95:45:de:f3:03:e8:e7:82:78:a5:9e:c2:1f:ad:eb:14:
fc:39:51:c7:e1:18:e9:16:b4:a5:48:de:09
El resto de esta página lo recorre de arriba abajo. La estructura en sí está definida en la RFC 5280 (§4.1 para los campos, §4.2 para las extensiones); lo que puede contener un certificado TLS de confianza pública figura en los Baseline Requirements (BR) del CA/Browser Forum, versión 2.3.1 del 4 de octubre de 2026, §7.1.
Versión, número de serie, algoritmo de firma, validez
- Versión 3 es la única versión que tiene extensiones; los BR la exigen.
- Número de serie. Único para cada emisor y, en las CA públicas, «un número no secuencial mayor que cero (0) y menor que 2¹⁵⁹ que contenga al menos 64 bits de salida de un CSPRNG» (BR §7.1.2.7). Aquí la aleatoriedad protege contra los ataques de colisión de prefijo elegido sobre el hash de la firma; por eso los números de serie parecen ruido. Un número de serie es lo que enumeran las CRL.
- Algoritmo de firma (Signature Algorithm). Aparece dos veces, dentro de la parte firmada y junto a la firma, y las dos apariciones deben ser idénticas byte a byte. Aquí
ecdsa-with-SHA384informa sobre la clave del emisor (YE2 tiene una clave P-384), no sobre la del sujeto. El valor de firma del final es una firma ECDSA en DER, el formato que se explica en Formatos de firma ECDSA. - Validez.
notBeforeynotAfterson inclusivos. Este certificado tiene una validez de 90 días; el máximo de los BR es de 200 días para los certificados emitidos desde el 15 de marzo de 2026, de 100 días a partir del 15 de marzo de 2027 y de 47 días a partir del 15 de marzo de 2029 (BR §6.3.2). Let's Encrypt ya emite certificados de 45 días con su perfil opcionaltlsservery prevé reducir la validez de su perfil predeterminado a 64 días el 10 de febrero de 2027 y a 45 días el 16 de febrero de 2028.
El sujeto y el nombre alternativo del sujeto (SAN)
El sujeto es un nombre distintivo: aquí solo CN=letsencrypt.org. Los certificados con validación de dominio no llevan nada más, porque la CA no validó nada más. Los nombres que comprueba un cliente están en la extensión nombre alternativo del sujeto (Subject Alternative Name, SAN): diez entradas DNS: en este certificado.
El nombre común (CN) dejó de contar hace mucho tiempo. La RFC 9525 (2023), que sustituyó a la RFC 6125, dice que «el RDN del nombre común NO DEBE (MUST NOT) usarse para identificar un servicio». Chrome dejó de compararlo en la versión 58 (2017), y Go rechaza los certificados que solo tienen CN con x509: certificate relies on legacy Common Name field. Los BR conservan el CN solo como copia: si está presente, «DEBE contener exactamente una entrada que sea uno de los valores contenidos en la extensión subjectAltName del certificado» (§7.1.4.3).
Un SAN también puede contener direcciones IP. El certificado del resolvedor DNS de Cloudflare:
subject=C=US, ST=California, L=San Francisco, O=Cloudflare, Inc., CN=cloudflare-dns.com
X509v3 Subject Alternative Name:
DNS:cloudflare-dns.com, DNS:*.cloudflare-dns.com, IP Address:1.0.0.1, IP Address:1.1.1.1, IP Address:162.159.36.1, IP Address:162.159.46.1, IP Address:2606:4700:4700:0:0:0:0:1001, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:64, IP Address:2606:4700:4700:0:0:0:0:6400, DNS:one.one.one.one
https://1.1.1.1 funciona porque 1.1.1.1 es una entrada iPAddress; una entrada DNS:1.1.1.1 no coincidiría con una dirección IP, que es de lo que trata el error de Go cannot validate certificate for … because it doesn't contain any IP SANs. Aquí el sujeto también incluye la organización y la localidad, y el certificado declara la política OV 2.23.140.1.2.2 (consulta DV, OV y EV); el navegador no muestra nada de eso. Se emitió el 31 de diciembre de 2025 por 355 días, antes de que entrara en vigor el límite de 200 días.
Un comodín como *.cloudflare-dns.com cubre exactamente una etiqueta: a.cloudflare-dns.com, pero no cloudflare-dns.com en sí ni a.b.cloudflare-dns.com (RFC 9525 §6.3). OpenSSL comprueba los nombres de la misma forma:
Hostname www.lencr.org does match certificate
Hostname lencr.org.evil.test does NOT match certificate
Hostname mail.letsencrypt.org does NOT match certificate
La clave pública del sujeto (SPKI)
El campo subjectPublicKeyInfo (SPKI) contiene el algoritmo y la clave: un punto sin comprimir de P-256 (04 seguido de las coordenadas x e y, de 32 bytes cada una). Es la única parte del certificado relacionada con la clave privada del sujeto; por eso la fijación de clave pública calcula el hash del SPKI y no el del certificado entero: una renovación con la misma clave conserva el pin (consulta la fijación de certificados en 2026).
Key Usage y Extended Key Usage
Son dos preguntas distintas:
- Key Usage (uso de clave; RFC 5280 §4.2.1.3) restringe las operaciones criptográficas de la clave:
digitalSignature,keyEncipherment,keyAgreement,keyCertSign,cRLSigny algunos bits menos frecuentes. Para un certificado hoja ECDSA, los BR exigendigitalSignaturey prohíbenkeyEncipherment(una clave EC no puede cifrar). Un certificado hoja RSA puede añadirkeyEnciphermentpara el antiguo intercambio de claves RSA de TLS 1.2, que los BR describen como compatibilidad con «conjuntos de cifrado inseguros». Los BR también dicen que la extensión DEBERÍA (SHOULD) estar presente y marcada como crítica, como aquí. - Extended Key Usage (uso extendido de clave; §4.2.1.12) nombra aplicaciones:
serverAuth(1.3.6.1.5.5.7.3.1),clientAuth(…3.2),codeSigning(…3.3),emailProtection(…3.4),timeStamping(…3.8). Un certificado de servidor TLS DEBE contenerserverAuthy NO DEBE contener firma de código, correo electrónico, sellado de tiempo, firma OCSP nianyExtendedKeyUsage(BR §7.1.2.7.10).
Lo que cambió es clientAuth. Los BR siguen diciendo MAY (PUEDE), pero la política del Chrome Root Program, versión 1.8, exige jerarquías «dedicadas a la autenticación de servidores TLS»: las CA subordinadas notificadas a partir del 15 de junio de 2026 solo pueden incluir serverAuth, y los certificados de suscriptor emitidos a partir del 15 de marzo de 2027 también. Let's Encrypt eliminó clientAuth de su perfil predeterminado el 11 de febrero de 2026 y dejó de emitirlo por completo el 8 de julio de 2026; el certificado hoja de letsencrypt.org de más arriba solo tiene serverAuth. Si tu servicio autenticaba a los clientes con certificados TLS públicos, necesita una CA privada (consulta cómo funciona mTLS).
Los verificadores aplican el EKU. Con una CA desechable, un certificado cuyo EKU es solo clientAuth:
CN=worker-7
error 26 at 0 depth lookup: unsuitable certificate purpose
error worker-7.pem: verification failed
worker-7.pem: OK
Es el error 26 de OpenSSL; Go informa de la misma situación con x509: certificate specifies an incompatible key usage.
Basic Constraints: quién puede emitir certificados
La extensión Basic Constraints (restricciones básicas) contiene un booleano y un número. CA:TRUE permite que la clave del certificado firme otros certificados; pathlen limita cuántas CA intermedias pueden seguir por debajo de él. La RFC 5280 §4.2.1.9 dice de forma explícita que, sin cA activado, «la clave pública certificada NO DEBE usarse para verificar firmas de certificados». Subiendo por la cadena de letsencrypt.org:
| Certificado | Basic Constraints | Key Usage |
|---|---|---|
CN=letsencrypt.org | crítica, CA:FALSE | Digital Signature |
CN=YE2 (intermedio) | crítica, CA:TRUE, pathlen:0 | Digital Signature, Certificate Sign, CRL Sign |
CN=Root YE (con firma cruzada de ISRG Root X2) | crítica, CA:TRUE | Certificate Sign, CRL Sign |
pathlen:0 en YE2 significa que solo puede emitir certificados hoja. Para ver cómo se aplica la regla, en las pruebas se usó la clave de un certificado de servidor corriente (CA:FALSE, Key Usage digitalSignature) para firmar otro certificado:
CN=api.example.test
error 79 at 1 depth lookup: invalid CA certificate
CN=api.example.test
error 32 at 1 depth lookup: key usage does not include certificate signing
error forged.example.test.pem: verification failed
Se activan las dos reglas: el error 79 por la falta de CA:TRUE y el error 32 por la falta de keyCertSign. Por omitir esta comprobación, Internet Explorer aceptaba en 2002 cualquier certificado hoja como CA. Python 3.13 y posteriores activan además el modo estricto de OpenSSL, que también rechaza los certificados de CA cuya extensión Basic Constraints no está marcada como crítica.
Identificadores de clave de la autoridad y del sujeto
El Subject Key Identifier identifica la clave del propio certificado; el Authority Key Identifier identifica la clave que lo firmó. Cada AKI coincide con el SKI del certificado siguiente hacia arriba:
subject=CN=letsencrypt.org
16:68:8D:1E:2A:32:48:8C:B5:F1:10:0A:16:08:37:08:3B:9D:30:23
B9:59:F2:8E:CF:22:F0:86:D3:37:48:FF:76:14:18:BA:82:D8:55:87
subject=C=US, O=Let's Encrypt, CN=YE2
B9:59:F2:8E:CF:22:F0:86:D3:37:48:FF:76:14:18:BA:82:D8:55:87
A3:C8:26:5A:8E:A1:4C:D0:35:63:FC:9B:23:C8:3A:AE:56:F3:4F:56
subject=C=US, O=ISRG, CN=Root YE
A3:C8:26:5A:8E:A1:4C:D0:35:63:FC:9B:23:C8:3A:AE:56:F3:4F:56
7C:42:96:AE:DE:4B:48:3B:FA:92:F8:9E:8C:CF:6D:8B:A9:72:37:95
subject=C=US, O=Internet Security Research Group, CN=ISRG Root X2
7C:42:96:AE:DE:4B:48:3B:FA:92:F8:9E:8C:CF:6D:8B:A9:72:37:95
79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E
Los identificadores de clave ayudan al verificador a elegir el emisor correcto cuando varios certificados de CA comparten nombre (CA que cambiaron de clave o que tienen firma cruzada, como los dos certificados ISRG Root X2 que existen). No demuestran nada: eso lo hace la comprobación de la firma. La RFC 5280 exige el AKI en todos los certificados salvo en las raíces autofirmadas, y el SKI en todos los certificados de CA; la RFC 5280 sugiere un hash SHA-1 de la clave como una forma de calcular el SKI, pero los emisores pueden usar cualquier valor único. Los BR califican el SKI del certificado hoja de «NOT RECOMMENDED» (no recomendado); tanto Let's Encrypt como Sectigo siguen incluyéndolo. La verificación estricta falla ante un certificado de CA sin AKI, como muestra el error de Python Missing Authority Key Identifier.
La cadena también muestra que la ruta que validas no siempre es la que envía el servidor. El servidor de letsencrypt.org envía cuatro certificados, el último de los cuales es ISRG Root X2 con firma cruzada de ISRG Root X1; OpenSSL, con el almacén de confianza de Debian, se detiene en la raíz X2, en la que ya confía:
letsencrypt.org-1.pem: OK
Chain:
depth=0: CN=letsencrypt.org (untrusted)
depth=1: C=US, O=Let's Encrypt, CN=YE2 (untrusted)
depth=2: C=US, O=ISRG, CN=Root YE (untrusted)
depth=3: C=US, O=Internet Security Research Group, CN=ISRG Root X2
CRL Distribution Points, AIA y OCSP
Dos extensiones apuntan a URL:
- CRL Distribution Points (RFC 5280 §4.2.1.13): dónde publica el emisor su CRL. Los BR exigen esta extensión salvo que el certificado sea de corta duración (7 días o menos desde el 15 de marzo de 2026) o lleve una URL de OCSP, y la URL debe ser
httpsimple: la CRL está firmada, así que TLS no aporta nada y crearía un bucle. - Authority Information Access (§4.2.2.1):
CA Issuersindica dónde descargar el certificado de la CA emisora, yOCSPes el respondedor OCSP del emisor.
El certificado hoja de Let's Encrypt tiene una URL de CRL y ninguna URL de OCSP: Let's Encrypt eliminó las URL de OCSP de sus certificados en mayo de 2025 y apagó sus respondedores el 6 de agosto de 2025, después de que los BR hicieran opcional OCSP. Sectigo sigue operando OCSP; el certificado hoja de github.com tiene los dos métodos de acceso y dos políticas:
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.2.7
CPS: https://sectigo.com/CPS
Policy: 2.23.140.1.2.1
Authority Information Access:
CA Issuers - URI:http://crt.sectigo.com/SectigoPublicServerAuthenticationCADVE36.crt
OCSP - URI:http://ocsp.sectigo.com
La CRL del certificado hoja de letsencrypt.org, descargada y verificada con el certificado de YE2:
crl=$(openssl x509 -in letsencrypt.org-1.pem -noout -ext crlDistributionPoints | grep -o 'http://[^ ]*')
curl -sS -o leaf.crl "$crl"
openssl crl -inform DER -in leaf.crl -noout -issuer -lastupdate -nextupdate
openssl crl -inform DER -in leaf.crl -noout -text | grep -c 'Serial Number:'
openssl crl -inform DER -in leaf.crl -noout -CAfile letsencrypt.org-2.pem
issuer=C=US, O=Let's Encrypt, CN=YE2
lastUpdate=Oct 20 15:03:57 2026 GMT
nextUpdate=Oct 29 15:03:56 2026 GMT
1590
verify OK
El 96.crl de la URL es un fragmento: la CA reparte sus revocaciones entre muchas CRL pequeñas e indica la que corresponde en cada certificado, así que un cliente descarga 1590 entradas en lugar de todas las revocaciones. Los navegadores rara vez descargan CRL en tiempo real; Chrome y Firefox envían ellos mismos los datos de revocación a los clientes. Las ventajas e inconvenientes de cada mecanismo están en CRL frente a OCSP.
CA Issuers importa cuando un servidor olvida enviar su certificado intermedio. Los navegadores y los verificadores de plataforma de Windows y macOS siguen esa URL («AIA chasing»); OpenSSL (y con él curl, Python y PHP en Linux), Go en Linux y Java con la configuración predeterminada no lo hacen, así que el mismo servidor mal configurado funciona en un navegador y falla en código con «unable to get local issuer certificate».
Políticas de certificado (Certificate Policies)
Todo certificado TLS público declara exactamente un identificador de política del CA/Browser Forum que indica cómo se validó el sujeto: 2.23.140.1.2.1 validación de dominio, 2.23.140.1.2.2 validación de organización, 2.23.140.1.2.3 validación individual, 2.23.140.1.1 validación extendida (BR §7.1.6.1). Las CA añaden sus propios OID de política y un enlace a su declaración de prácticas (CPS), como Sectigo más arriba. Los clientes que muestran niveles de validación leen esta extensión, no el sujeto.
Marcas de tiempo de certificado firmadas (SCT)
Antes de emitir el certificado, la CA envía un precertificado (el mismo contenido con una extensión de «veneno», poison) a logs de transparencia de certificados, y cada log responde con una promesa firmada de publicarlo: la SCT. La CA incrusta esas SCT en el certificado final (OID 1.3.6.1.4.1.11129.2.4.2, RFC 6962 §3.3). El ID del log es un hash de la clave del log; la lista de logs de Chrome lo asocia a un nombre:
"""List the SCTs embedded in a certificate and name their logs from Chrome's CT log list."""
import base64
import json
import sys
from cryptography import x509
log_list = json.load(open(sys.argv[1]))
logs = {}
for operator in log_list["operators"]:
for log in operator["logs"] + operator.get("tiled_logs", []):
logs[base64.b64decode(log["log_id"])] = (operator["name"], log["description"])
cert = x509.load_pem_x509_certificate(open(sys.argv[2], "rb").read())
scts = cert.extensions.get_extension_for_class(x509.PrecertificateSignedCertificateTimestamps).value
for sct in scts:
operator, name = logs.get(sct.log_id, ("unknown operator", "unknown log"))
print(f"{sct.timestamp:%Y-%m-%d %H:%M:%S} UTC {operator}: {name} ({sct.entry_type.name})")
2026-09-04 15:33:02 UTC Google: Google Xenon2026h2 (PRE_CERTIFICATE)
2026-09-04 15:33:02 UTC Geomys: Geomys Tuscolo2026h2 (PRE_CERTIFICATE)
2026-09-01 00:10:32 UTC Google: Google Argon2026h2 (PRE_CERTIFICATE)
2026-09-01 00:10:31 UTC Sectigo: Sectigo Tiger2026h2 (PRE_CERTIFICATE)
La lista de logs se descargó de https://www.gstatic.com/ct/log_list/v3/log_list.json el mismo día. Cada certificado tiene dos SCT de dos operadores distintos, que es lo que pide la política CT de Chrome para un certificado válido durante 180 días o menos (tres para los de mayor duración). El Extensions: 00:00:05:00:24:DF:DB:0C de la SCT de Tuscolo es la extensión leaf_index que deben añadir los logs que implementan la static CT API: tipo 0, longitud 5 y un índice de 40 bits, aquí la entrada 618.650.380 de ese log. Gracias a las SCT, cualquiera puede buscar todos los certificados emitidos para su dominio, y un certificado emitido indebidamente no puede quedar en secreto. El decodificador de SCT las decodifica sin necesidad de la línea de comandos.
Errores frecuentes
- Un certificado con el nombre solo en el CN. Los navegadores muestran NET::ERR_CERT_COMMON_NAME_INVALID y Java dice No subject alternative names present. Todos los nombres, incluido el del CN, van en el SAN. Este error aparece sobre todo con CA internas y con comandos
openssl reqde una sola línea que solo establecen-subj. - Falta el certificado intermedio. Funciona en los navegadores y en los verificadores de plataforma de Windows y macOS gracias al AIA chasing, y falla en los clientes basados en OpenSSL, en Go en Linux y en Java. Sirve la cadena completa (primero el certificado hoja; la raíz es opcional).
- Depender de
clientAuthen un certificado público. Está desapareciendo de las jerarquías TLS públicas; las integraciones con socios que fijaron como requisito «cualquier certificado público conclientAuth» necesitan una CA privada. - Un certificado de CA creado con
CA:TRUEpero sinkeyCertSign, o con Basic Constraints sin marcar como crítica. Los verificadores estrictos (Python 3.13+, Go para algunos campos) lo rechazan; el mensaje de Go es parent certificate cannot sign this kind of certificate. - Tratar el SKI como una huella digital. Contiene lo que la CA haya puesto ahí. Para identificar un certificado, calcula el hash de todo el DER (
openssl x509 -fingerprint -sha256); para identificar una clave, calcula el hash del SPKI. - Leer la validez en hora local.
notBeforeynotAfterestán en UTC. Un servidor cuyo reloj va unas horas atrasado rechaza un certificado recién emitido por no ser aún válido.
Fuentes
- RFC 5280: §4.1 (campos del certificado), §4.2.1.1–4.2.1.13 (AKI, SKI, Key Usage, SAN, Basic Constraints, EKU, CRL DP), §4.2.2.1 (AIA)
- RFC 9525: identidad de servicio en TLS (§2, §6.3)
- RFC 6962: Certificate Transparency (§3.3) y la static CT API
- Baseline Requirements del CA/Browser Forum 2.3.1 (4 de octubre de 2026): §6.3.2, §7.1.2.7, §7.1.2.10, §7.1.2.11, §7.1.4.3, §7.1.6.1
- Política del Chrome Root Program, versión 1.8 y política CT de Chrome
- Let's Encrypt: Fin del soporte de OCSP en 2025, Fin del soporte de certificados de autenticación de cliente TLS en 2026, Cadenas de confianza