Resposta curta. Um cliente TLS identifica um servidor apenas pelo Subject Alternative Name: as entradas dNSName e iPAddress, nunca o Common Name do titular. A Key Usage diz o que a chave pode fazer matematicamente (assinar, criptografar, assinar certificados); a Extended Key Usage diz para qual aplicação (serverAuth, clientAuth, assinatura de código). A Basic Constraints com CA:TRUE é o que permite a um certificado emitir outros; um certificado folha tem CA:FALSE. Os Authority e Subject Key Identifiers são pistas que ajudam o cliente a encontrar o emissor, não verificações de segurança. As extensões CRL Distribution Points e Authority Information Access dizem ao cliente onde verificar a revogação e de onde baixar um intermediário ausente; os certificados da Let’s Encrypt não trazem mais URL de OCSP. Os SCTs provam que o certificado foi registrado no Certificate Transparency, o que o Chrome e o Safari exigem.
Como obter um certificado real para examinar
O openssl s_client -showcerts imprime todos os certificados que o servidor envia; o openssl x509 -text decodifica um deles. O laboratório rodou em debian:forky-20261005-slim com o OpenSSL 3.6.5 e o 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
O -servername envia o SNI; sem ele, muitos servidores retornam um certificado padrão para outro nome. O certificado folha de letsencrypt.org, como era servido naquele dia (a chave pública aparece completa; as duas assinaturas dos SCTs estão encurtadas):
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
O restante desta página percorre esse certificado de cima a baixo. A estrutura em si é definida na RFC 5280 (§4.1 para os campos, §4.2 para as extensões); o que um certificado TLS publicamente confiável pode conter está nos Baseline Requirements (BR) do CA/Browser Forum, versão 2.3.1 de 4 de outubro de 2026, §7.1.
Versão, número de série, algoritmo de assinatura, validade
- A versão 3 é a única que tem extensões; os BR a exigem.
- Número de série. Único por emissor e, nas CAs públicas, “um número não sequencial maior que zero (0) e menor que 2¹⁵⁹, contendo pelo menos 64 bits de saída de um CSPRNG” (BR §7.1.2.7). Aqui a aleatoriedade é uma defesa contra ataques de colisão com prefixo escolhido sobre o hash da assinatura; é por isso que os números de série parecem ruído. É o número de série que as CRLs listam.
- O algoritmo de assinatura (Signature Algorithm) aparece duas vezes, dentro da parte assinada e ao lado da assinatura, e as duas ocorrências precisam ser idênticas byte a byte. Aqui,
ecdsa-with-SHA384informa sobre a chave do emissor (a YE2 tem uma chave P-384), não sobre a do titular. O valor da assinatura no final é uma assinatura ECDSA em DER, o formato explicado em formatos de assinatura ECDSA. - Validade.
notBeforeenotAftersão inclusivos. Este certificado vale por 90 dias; o máximo dos BR é de 200 dias para certificados emitidos desde 15 de março de 2026, 100 dias a partir de 15 de março de 2027 e 47 dias a partir de 15 de março de 2029 (BR §6.3.2). A Let’s Encrypt já emite certificados de 45 dias no perfil opcionaltlsservere planeja mudar o padrão para 64 dias em 10 de fevereiro de 2027 e para 45 dias em 16 de fevereiro de 2028.
Titular e Subject Alternative Name
O titular (subject) é um nome distinto: aqui, apenas CN=letsencrypt.org. Certificados com validação de domínio não trazem mais nada, porque a CA não validou mais nada. Os nomes que o cliente verifica ficam na extensão Subject Alternative Name (SAN): dez entradas DNS: neste certificado.
O Common Name deixou de contar há muito tempo. A RFC 9525 (2023), que substituiu a RFC 6125, diz: “O RDN Common Name NÃO DEVE ser usado para identificar um serviço”. O Chrome deixou de compará-lo com o nome do servidor na versão 58 (2017), e o Go recusa certificados que só têm CN com x509: certificate relies on legacy Common Name field. Os BR mantêm o CN apenas como cópia: se presente, ele “DEVE conter exatamente uma entrada que seja um dos valores contidos na extensão subjectAltName do certificado” (§7.1.4.3).
O SAN também pode conter endereços IP. O certificado do resolvedor da 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 é uma entrada iPAddress; uma entrada DNS:1.1.1.1 não corresponderia a um endereço IP, e é disso que trata o erro cannot validate certificate for … because it doesn't contain any IP SANs do Go. Aqui o titular também traz organização e localidade, e o certificado declara a política OV 2.23.140.1.2.2 (veja DV vs OV vs EV); o navegador não mostra nada disso. Ele foi emitido em 31 de dezembro de 2025 com validade de 355 dias, antes de o limite de 200 dias entrar em vigor.
Um nome curinga como *.cloudflare-dns.com corresponde a exatamente um rótulo: a a.cloudflare-dns.com, mas não ao próprio cloudflare-dns.com nem a a.b.cloudflare-dns.com (RFC 9525 §6.3). O OpenSSL verifica os nomes da mesma 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
A chave pública do titular (SPKI)
O subjectPublicKeyInfo (SPKI) contém o algoritmo e a chave: um ponto não comprimido da curva P-256 (04 seguido de x e y, de 32 bytes cada). É a única parte do certificado com a qual a chave privada do titular se relaciona, e é por isso que a fixação de chave pública calcula o hash do SPKI, e não do certificado inteiro: uma renovação com a mesma chave mantém o pin válido (veja fixação de certificados em 2026).
Key Usage e Extended Key Usage
São duas perguntas diferentes:
- A Key Usage (RFC 5280 §4.2.1.3) restringe as operações criptográficas da chave:
digitalSignature,keyEncipherment,keyAgreement,keyCertSign,cRLSigne alguns bits mais raros. Para um certificado folha ECDSA, os BR exigemdigitalSignaturee proíbemkeyEncipherment(uma chave EC não consegue criptografar). Um certificado folha RSA pode acrescentarkeyEnciphermentpara a antiga troca de chaves RSA do TLS 1.2, o que os BR chamam de suporte a “cipher suites inseguras”. Os BR também dizem que a extensão DEVERIA estar presente e marcada como crítica, como aqui. - A Extended Key Usage (§4.2.1.12) nomeia aplicações:
serverAuth(1.3.6.1.5.5.7.3.1),clientAuth(…3.2),codeSigning(…3.3),emailProtection(…3.4),timeStamping(…3.8). Um certificado de servidor TLS DEVE conterserverAuthe NÃO DEVE conter assinatura de código, e-mail, carimbo do tempo, assinatura de OCSP nemanyExtendedKeyUsage(BR §7.1.2.7.10).
O clientAuth é a parte que mudou. Os BR ainda dizem PODE, mas a Chrome Root Program Policy 1.8 exige hierarquias “dedicadas à autenticação de servidores TLS”: CAs subordinadas divulgadas a partir de 15 de junho de 2026 só podem declarar serverAuth, e os certificados de assinantes emitidos a partir de 15 de março de 2027 também terão de seguir essa regra. A Let’s Encrypt removeu o clientAuth do perfil padrão em 11 de fevereiro de 2026 e deixou de emiti-lo por completo em 8 de julho de 2026; o certificado folha de letsencrypt.org acima tem apenas serverAuth. Se o seu serviço autenticava clientes com certificados TLS públicos, ele precisa de uma CA privada (veja o guia de mTLS).
Os verificadores aplicam a EKU. Com uma CA descartável, um certificado cuja EKU é apenas clientAuth:
CN=worker-7
error 26 at 0 depth lookup: unsuitable certificate purpose
error worker-7.pem: verification failed
worker-7.pem: OK
Esse é o erro 26 do OpenSSL; o Go relata a mesma condição como x509: certificate specifies an incompatible key usage.
Basic Constraints: quem pode emitir certificados
A extensão Basic Constraints traz um booleano e um número. CA:TRUE permite que a chave do certificado assine outros certificados; pathlen limita quantas CAs intermediárias podem vir abaixo dele. A RFC 5280 §4.2.1.9 é explícita: sem cA declarado, “a chave pública certificada NÃO DEVE ser usada para verificar assinaturas de certificados”. Subindo pela cadeia de letsencrypt.org:
| Certificado | Basic Constraints | Key Usage |
|---|---|---|
CN=letsencrypt.org | crítica, CA:FALSE | Digital Signature |
CN=YE2 (intermediário) | crítica, CA:TRUE, pathlen:0 | Digital Signature, Certificate Sign, CRL Sign |
CN=Root YE (com assinatura cruzada da ISRG Root X2) | crítica, CA:TRUE | Certificate Sign, CRL Sign |
O pathlen:0 na YE2 significa que ela só pode emitir certificados folha. Para ver a regra sendo aplicada, o laboratório usou a chave de um certificado de servidor comum (CA:FALSE, Key Usage digitalSignature) para assinar outro 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
As duas regras disparam: o erro 79 pela falta de CA:TRUE e o erro 32 pela falta de keyCertSign. Foi por pular essa verificação que, em 2002, o Internet Explorer aceitava qualquer certificado folha como CA. O Python 3.13 e versões posteriores também ativam o modo estrito do OpenSSL, que além disso rejeita certificados de CA cuja extensão Basic Constraints não está marcada como crítica.
Authority Key Identifier e Subject Key Identifier
O Subject Key Identifier identifica a chave do próprio certificado; o Authority Key Identifier identifica a chave que o assinou. Cada AKI é igual ao SKI do certificado seguinte, um nível acima:
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
Os identificadores de chave ajudam o verificador a escolher o emissor certo quando vários certificados de CA têm o mesmo nome (CAs que trocaram de chave ou com assinatura cruzada, como os dois certificados ISRG Root X2 que existem). Eles não provam nada: quem prova é a verificação da assinatura. A RFC 5280 exige o AKI em todo certificado, exceto nas raízes autoassinadas, e o SKI em todo certificado de CA; a RFC 5280 sugere um hash SHA-1 da chave como uma das formas de calcular o SKI, mas os emissores podem usar qualquer valor único. Os BR classificam o SKI do certificado folha como “NÃO RECOMENDADO”; tanto a Let’s Encrypt quanto a Sectigo ainda incluem um. Em verificadores estritos, a verificação falha diante de um certificado de CA sem AKI, como mostra o erro Missing Authority Key Identifier do Python.
A cadeia também mostra que o caminho que você valida nem sempre é o caminho que o servidor envia. O letsencrypt.org envia quatro certificados, terminando com a ISRG Root X2 com assinatura cruzada da ISRG Root X1; o OpenSSL com o trust store do Debian para na raiz X2, na qual já confia:
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 e OCSP
Duas extensões apontam para URLs:
- CRL Distribution Points (RFC 5280 §4.2.1.13): onde o emissor publica sua CRL. Os BR exigem essa extensão, a menos que o certificado seja de curta duração (7 dias ou menos desde 15 de março de 2026) ou traga uma URL de OCSP, e a URL precisa ser
httpsimples: a CRL é assinada, então o TLS não acrescenta nada e criaria um loop. - Authority Information Access (§4.2.2.1):
CA Issuersindica onde baixar o certificado da CA emissora, eOCSPé o respondedor OCSP do emissor.
O certificado folha da Let’s Encrypt tem uma URL de CRL e nenhuma URL de OCSP: a CA removeu as URLs de OCSP dos certificados em maio de 2025 e desligou seus respondedores em 6 de agosto de 2025, depois que os BR tornaram o OCSP opcional. A Sectigo ainda mantém OCSP; o certificado folha de github.com tem os dois métodos de acesso e duas 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
A CRL por trás do certificado folha de letsencrypt.org, baixada e verificada com o certificado da 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
O 96.crl na URL é um fragmento (shard): a CA divide suas revogações em muitas CRLs pequenas e indica a certa em cada certificado, de modo que o cliente baixa 1.590 entradas em vez de todas as revogações. Os navegadores raramente buscam CRLs em tempo real; o Chrome e o Firefox distribuem por conta própria os dados de revogação aos clientes. Os prós e contras de cada abordagem estão em CRL vs OCSP.
O CA Issuers importa quando um servidor esquece de enviar o intermediário. Os navegadores e os verificadores das plataformas Windows e macOS seguem esse endereço (“AIA chasing”); o OpenSSL (e, com ele, o curl, o Python e o PHP no Linux), o Go no Linux e o Java com as configurações padrão não seguem, então o mesmo servidor mal configurado funciona no navegador e falha no código com “unable to get local issuer certificate”.
Certificate Policies
Todo certificado TLS público declara exatamente um identificador de política do CA/Browser Forum que diz como o titular foi validado: 2.23.140.1.2.1 validação de domínio, 2.23.140.1.2.2 validação de organização, 2.23.140.1.2.3 validação de pessoa física, 2.23.140.1.1 validação estendida (BR §7.1.6.1). As CAs acrescentam seus próprios OIDs de política e um link para sua declaração de práticas (CPS), como a Sectigo acima. Os clientes que exibem níveis de validação leem esta extensão, não o titular.
Signed Certificate Timestamps
Antes de emitir, a CA envia um pré-certificado (o mesmo conteúdo com uma extensão “poison”) aos logs do Certificate Transparency, e cada log responde com uma promessa assinada de publicá-lo, o SCT. A CA incorpora esses SCTs ao certificado final (OID 1.3.6.1.4.1.11129.2.4.2, RFC 6962 §3.3). O ID do log é um hash da chave do log; a lista de logs do Chrome associa cada ID a um nome:
"""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)
A lista de logs foi baixada de https://www.gstatic.com/ct/log_list/v3/log_list.json no mesmo dia. Cada certificado tem dois SCTs de dois operadores diferentes, como pede a política de CT do Chrome para um certificado com validade de 180 dias ou menos (três para os mais longos). O Extensions: 00:00:05:00:24:DF:DB:0C no SCT do Tuscolo é a extensão leaf_index que os logs que implementam a static CT API precisam adicionar: tipo 0, comprimento 5 e um índice de 40 bits, aqui a entrada 618.650.380 desse log. É graças aos SCTs que qualquer pessoa pode buscar todos os certificados emitidos para o próprio domínio e que um certificado emitido indevidamente não consegue ficar em segredo. O decodificador de SCT decodifica os SCTs sem linha de comando.
Erros comuns
- Certificado com o nome só no CN. Os navegadores relatam NET::ERR_CERT_COMMON_NAME_INVALID, o Java diz No subject alternative names present. Todo nome, inclusive o que está no CN, vai no SAN. O problema aparece com mais frequência em CAs internas e em comandos
openssl reqde uma linha que definem apenas-subj. - Intermediário ausente. Funciona nos navegadores e nos verificadores das plataformas Windows e macOS graças ao AIA chasing, mas falha em clientes baseados no OpenSSL, em Go no Linux e em Java. Sirva a cadeia completa (certificado folha primeiro, raiz opcional).
- Depender de
clientAuthem um certificado público. Ele está desaparecendo das hierarquias TLS públicas; integrações com parceiros que fixaram a regra “qualquer certificado público comclientAuth” precisam de uma CA privada. - Certificado de CA criado com
CA:TRUE, mas semkeyCertSignou sem marcar a extensão como crítica. Verificadores estritos (Python 3.13+, Go para alguns campos) o rejeitam; no Go, a mensagem é parent certificate cannot sign this kind of certificate. - Tratar o SKI como impressão digital. Ele é o que a CA tiver colocado ali. Para identificar um certificado, calcule o hash do DER inteiro (
openssl x509 -fingerprint -sha256); para identificar uma chave, calcule o hash do SPKI. - Ler a validade no horário local.
notBeforeenotAfterestão em UTC. Um servidor com o relógio algumas horas atrasado rejeita um certificado recém-emitido como ainda não válido.
Fontes
- RFC 5280: §4.1 (campos do 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: identidade de serviço no TLS (§2, §6.3)
- RFC 6962: Certificate Transparency (§3.3) e a static CT API
- Baseline Requirements do CA/Browser Forum 2.3.1 (4 de outubro 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
- Chrome Root Program Policy 1.8 e política de CT do Chrome
- Let’s Encrypt: Fim do suporte ao OCSP em 2025, Fim do suporte a certificados de autenticação de cliente TLS em 2026, Cadeias de confiança