Origens: um formato de diretório que virou a camada de identidade da web

O não foi desenhado para a web. Chegou em 1988 como parte do X.500, um sistema de diretório da ITU-T que pretendia dar a cada entidade do mundo um nome distinto numa hierarquia global. Aquele projeto nunca aconteceu, e o formato de certificado sobreviveu a ele.

A herança explica quase tudo o que hoje parece estranho. Nomes distintos com componentes de país, organização e nome comum são entradas de diretório, não identidades web. O .1 com codificação é uma serialização de telecom dos anos 1980, e é por isso que um certificado não é texto legível. E a premissa de que uma hierarquia global nomearia todo mundo é a razão de nada no desenho original dizer qual autoridade pode falar por qual nome - problema remendado depois por registros CAA e log público.

As versões registram os reparos:

  • v1 (1988) - sujeito, emissor, chave, validade. Sem extensões, logo sem como dizer para que servia o certificado.
  • v2 - acrescentou identificadores únicos de emissor e sujeito; quase não foi usada.
  • v3 (1996) - acrescentou extensões, que é onde mora todo o significado moderno: para que a chave pode ser usada, quais nomes ela cobre, onde conferir revogação, se ela pode assinar outros certificados.
  • PKIX ( 5280 e sucessoras) - o perfil de internet que restringe o formato geral a algo interoperável, porque o X.509 sozinho permite muito mais do que a web pode aceitar com segurança.

A web então passou duas décadas corrigindo o modelo de nomes: o nome comum foi usado para nomes de host, depois foi depreciado em favor da extensão nome alternativo do sujeito, que é o único campo que um cliente moderno lê para essa finalidade.

O que é um certificado

Um certificado X.509 é uma declaração assinada que vincula uma chave pública a uma identidade. Quando um navegador se conecta a um site por HTTPS, o servidor apresenta um certificado que diz, com efeito, "esta chave pública pertence a test.ronutz.com, e uma autoridade certificadora atesta isso". O perfil que define quais campos um certificado carrega e como são interpretados é a RFC 5280.

O vínculo é o que importa. Qualquer um pode gerar um par de chaves, então uma chave pública nua não prova nada sobre quem está do outro lado. Um certificado adiciona uma assinatura de um emissor em que a parte confiante já confia, transformando uma chave anônima em uma chave com um nome anexado. Esta é a fundação da infraestrutura de chave pública ( (infraestrutura de chaves públicas)) da web.

A cadeia de confiança

Um único certificado raramente é confiável por si só. Ele é confiável porque foi assinado por um emissor, que por sua vez foi assinado por outro emissor, até uma raiz que a parte confiante já mantém em um repositório de confiança:

Root CA  (self-signed, in the OS/browser trust store)
   |  signs
Intermediate CA
   |  signs
Leaf / end-entity certificate  (test.ronutz.com)

Cada elo é uma assinatura: o emissor assina o certificado do filho com a chave privada do emissor, e um verificador checa essa assinatura com a chave pública do emissor. Uma raiz é autoemitida e autoassinada, e é por isso que um certificado autoassinado é um útil substituto local para uma raiz, mas não carrega nenhuma autoridade externa. A ferramenta X.509 sinaliza um certificado autoemitido (emissor igual ao sujeito) e se o certificado está marcado como uma , ambos os quais lhe dizem onde um certificado se situa nesta figura.

ASN.1 e DER: o leiaute de bytes

Um certificado não é JSON nem texto. Ele é descrito em ASN.1 (Abstract Syntax Notation One) e codificado com as Distinguished Encoding Rules (DER), especificadas na ITU-T X.690. O DER é um formato tag-length-value (TLV): cada elemento começa com um byte de tag dizendo que tipo ele é, depois um comprimento, depois aquela quantidade de bytes de conteúdo. Tipos construídos como SEQUENCE e SET contêm elementos filhos, então o certificado inteiro é uma árvore de TLVs.

Um arquivo (Correio com Privacidade Aprimorada, do inglês Privacy-Enhanced Mail) é apenas aquele DER, codificado em e envolto em linhas de armadura:

-----BEGIN CERTIFICATE-----
MIIELDCCAxSgAwIBAgIG...    (Base64 of the DER)
-----END CERTIFICATE-----

Então decodificar um certificado significa remover a armadura, decodificar de Base64 para DER, e então percorrer a árvore de TLVs. A ferramenta X.509 faz exatamente isso no seu navegador, sem biblioteca e sem chamada de rede.

A estrutura de nível superior

No nível mais externo, a RFC 5280 define três partes:

Certificate ::= SEQUENCE {
  tbsCertificate       TBSCertificate,
  signatureAlgorithm   AlgorithmIdentifier,
  signatureValue       BIT STRING
}

O tbsCertificate ("to be signed", a ser assinado) contém todo o conteúdo real. O signatureAlgorithm nomeia como o emissor o assinou, por exemplo sha256WithRSAEncryption ou ecdsa-with-SHA256. O signatureValue é a assinatura em si, computada sobre os bytes DER do tbsCertificate. Vale a pena guardar esse último ponto: a assinatura cobre o corpo a-ser-assinado exatamente como codificado, e é por isso que mesmo uma mudança de um byte em qualquer lugar do corpo quebra a verificação.

Dentro do TBSCertificate

O corpo a-ser-assinado é onde a ferramenta gasta a maior parte de seu tempo:

  • A Versão é quase sempre v3, a versão que introduziu as extensões.
  • O Número de série é um inteiro grande que o emissor atribui. Combinado com o nome do emissor, ele identifica unicamente o certificado, e é o que uma lista de revogação referencia.
  • O Emissor (Issuer) e o Sujeito (Subject) são Nomes Distintos (Distinguished Names). Um DN é uma sequência de atributos como CN (common name), O (organization), OU (organizational unit), L (locality), ST (state) e C (country). A RFC 4514 define a renderização de uma linha, mais-específico-primeiro, que você vê, por exemplo CN=test.ronutz.com, O=NTZ Technology, C=BR.
  • A Validade (Validity) é um carimbo de tempo notBefore e um notAfter. Estes são codificados como UTCTime ou GeneralizedTime; a ferramenta converte ambos para ISO-8601 e, contra o seu relógio local, lhe diz se o certificado é válido agora, ainda-não-válido, ou expirado.
  • O subjectPublicKeyInfo carrega a chave pública mais seu algoritmo. Para a ferramenta reporta o tamanho do módulo (por exemplo 2048-bit) e o expoente público (quase sempre 65537). Para chaves de curva elíptica ela reporta a curva nomeada (P-256, P-384, P-521), conforme a RFC 5480.

As extensões v3

As extensões são onde os certificados modernos codificam a maior parte de sua política. Cada extensão tem um identificador, um sinalizador crítico e um valor. O sinalizador crítico importa: se uma parte confiante não entende uma extensão marcada como crítica, ela deve rejeitar o certificado em vez de ignorar o campo. A ferramenta decodifica as que carregam mais peso:

  • O Subject Alternative Name () lista as identidades para as quais o certificado é de fato válido, como nomes DNS, endereços IP, endereços de e-mail ou URIs. Para TLS, este é o campo que os navegadores checam, não o CN. Um certificado para test.ronutz.com que omite esse nome de seu SAN falhará na validação em um cliente moderno mesmo se o CN combinar.
  • O Key Usage restringe o que a chave pode fazer em baixo nível: digitalSignature, keyEncipherment, keyCertSign, cRLSign e outros. Um certificado de CA carrega keyCertSign; uma folha TLS tipicamente carrega digitalSignature e keyEncipherment.
  • O Extended Key Usage (EKU) nomeia propósitos de nível mais alto como serverAuth (servidor TLS), clientAuth (cliente TLS), codeSigning ou emailProtection.
  • O Basic Constraints declara se o certificado é uma CA e, se for, quantas CAs intermediárias podem aparecer abaixo dele (o comprimento do caminho). Este é o campo que impede que um certificado folha seja usado para assinar outros certificados.
  • O Subject Key Identifier e o Authority Key Identifier são hashes que permitem a um verificador combinar rapidamente um certificado ao seu emissor ao construir uma cadeia.

Validação, e por que decodificar é a metade fácil

Um certificado analisado diz o que ele afirma. A validação pergunta se a afirmação se sustenta, e é uma sequência sem passos opcionais: montar uma cadeia até uma âncora de confiança que o cliente tenha; verificar cada assinatura; conferir as datas de validade em todos os níveis; confirmar que o nome casa pelo nome alternativo do sujeito; confirmar que uso de chave e uso estendido permitem esta finalidade; impor as restrições básicas para que um certificado de ponta não assine outros; conferir o comprimento do caminho; e consultar a revogação.

A revogação é o elo fraco. As listas de certificados revogados ficaram pesadas; o (Online Certificate Status Protocol) vaza navegação para o emissor e falha de forma leniente quando inalcançável, porque falhar fechado quebraria a web a cada queda de respondedor. O grampeamento move a conferência para o servidor, o must-staple a torna obrigatória para aquele certificado, e a resposta prática da indústria foi vida curta - um certificado que não se consegue revogar de forma confiável ao menos deveria expirar logo.

A montagem de caminho é onde as implementações divergem. Raízes com assinatura cruzada significam que mais de uma cadeia válida pode existir, e um cliente que só encontra a expirada falha enquanto outro tem sucesso - causa de várias quedas amplamente sentidas que pareciam expiração e eram diferença de escolha de cadeia.

O ecossistema, por categoria

  • Autoridades públicas - emissores comerciais ao lado do Let's Encrypt e de outras organizações automatizadas sem fins lucrativos, todas presas às regras dos programas de raiz dos navegadores e ao log de Transparência de Certificados.
  • PKI privada e corporativa - Microsoft Certificate Services, EJBCA, Dogtag, HashiCorp Vault, e emissores nativos de nuvem. Mesmo formato, âncoras de confiança diferentes, e em geral o lugar de onde as quedas por expiração de fato saem.
  • Identidade de carga de trabalho e de vida curta - SPIFFE/SPIRE, emissores de service mesh, e identidade de instância na nuvem: certificados medidos em horas, emitidos automaticamente, nunca tocados por uma pessoa.
  • Ferramental - OpenSSL para inspeção e geração, clientes para emissão e renovação, e monitores de logs CT para detectar certificados que você não pediu.
  • Proteção em hardware - módulos de segurança em hardware e elementos seguros para chaves que não podem ser exportáveis, requisito de qualquer autoridade e cada vez mais de pontas de alto valor.

A regra operacional que sobrevive a qualquer arquitetura: automatize a renovação ou uma hora tome uma queda, porque expiração de certificado é a única falha agendada com antecedência que ainda assim surpreende as pessoas.

Impressões digitais

Uma impressão digital (fingerprint) de certificado é simplesmente um hash criptográfico dos bytes DER do certificado, geralmente (e, para referências mais antigas, SHA-1). Ela não é um campo dentro do certificado; é computada sobre a coisa inteira. Impressões digitais lhe dão um valor curto, de comprimento fixo, para comparar dois certificados quanto à igualdade ou para fixar um certificado conhecido. A ferramenta computa tanto SHA-256 quanto SHA-1 localmente com a Web Crypto API, então os bytes que você cola nunca são enviados a lugar algum. Para mais sobre o que um hash é e não é, veja o artigo de hashing.

Decodificar não é validar

Esta é a única ideia mais importante, e ela espelha a mesma cautela que se aplica aos JSON Web Tokens. Ler os campos de um certificado lhe diz o que ele afirma. Não lhe diz que a afirmação é verdadeira. A validação completa é um processo separado e mais pesado: checar que a assinatura encadeia até uma raiz confiável, que nenhum dos certificados na cadeia está expirado ou revogado, que o nome ao qual você se conectou está no SAN, e que os usos da chave permitem o que você está fazendo.

Um decodificador de certificados, este incluído, é um instrumento de inspeção e aprendizado. Ele lhe mostra precisamente o que um emissor afirmou e como foi codificado. Trate a saída como uma leitura fiel do documento, não como um veredito sobre confiar nele ou não.

Esta série, em ordem

Este artigo abre a série Certificados: o objeto e a confiança. Depois de desmontar um certificado byte a byte, a série o acompanha pela vida (o arquivo em que é guardado, a requisição que o cria, a validação e a montagem de cadeia que um cliente faz, os ponteiros e a revogação que podem cancelá-lo) e termina no próprio modelo de confiança: quem tem permissão para atestar, o que aconteceu quando um deles quebrou e como o desenho chegou a ser o que é.

  1. PEM, DER e os formatos de arquivo de certificado. PEM, DER e o que arquivos .crt, .pem, .pfx e .p12 realmente contêm.
  2. Requisições de assinatura de certificado e como certificados são emitidos. O que uma contém, por que a chave privada nunca deixa a sua máquina e como uma CA valida e emite.
  3. Como a validação de certificados de fato funciona. Os passos que um cliente executa: montar a cadeia, checar assinaturas e datas, casar o nome, impor as restrições.
  4. Cadeias de certificados: a ordem, a âncora e o que as quebra. Da folha a uma raiz confiável: a ordem da cadeia, o que o TLS 1.3 relaxou, por que a raiz fica de fora e as falhas que a quebram.
  5. Authority Information Access: as URLs de OCSP e CA Issuers. Os dois ponteiros da extensão AIA: onde perguntar sobre revogação (OCSP) e onde buscar o emissor (CA Issuers).
  6. Revogação de certificados: CRL, OCSP e certificados de vida curta. A lista de revogação de certificados (), o OCSP e os certificados de vida curta: por que cancelar um certificado antes da expiração funciona mal, e o que o substitui.
  7. OCSP Must-Staple: como fechar a brecha do soft-fail. A brecha do soft-fail nas checagens OCSP ao vivo, e como o stapling e a flag Must-Staple a fecham, a um preço operacional.
  8. Autoridades certificadoras: o cadeado é uma lista de gente que você nunca conheceu. Algumas centenas de organizações, qualquer uma capaz de emitir um certificado para qualquer nome: o desenho, e como ele falhou.
  9. 2011: o ano em que as âncoras de confiança quebraram. O ano em que as âncoras de confiança quebraram: a invasão da RSA SecurID e a autoridade certificadora que emitiu 531 certificados fraudulentos.
  10. PKI: uma monografia de graduação, e um modelo de confiança que ninguém projetaria hoje. Da monografia de graduação de 1978 que nomeou o certificado a um modelo de confiança que ninguém projetaria hoje.