Decodificador CSR

O que um CSR contém, e o que não contém

Uma solicitação de assinatura de certificado (CSR) carrega três coisas: o subject com o qual você quer ser identificado, a metade pública do seu par de chaves e as extensões que você está pedindo - principalmente os nomes alternativos do subject (SANs). Ela é assinada com a sua chave privada, o que prova à autoridade certificadora (CA) que você realmente possui a chave que está pedindo para certificar.

O CSR não contém a chave privada, e nada nele permite derivá-la. Por isso um CSR não é um segredo como uma chave, e é razoável colá-lo numa ferramenta. Mas também não é nada: ele descreve hostnames, uma organização e às vezes convenções internas de nomenclatura, então vale saber se o decodificador que você usa o envia para algum lugar. Muitos enviam, porque a maioria é mantida por empresas que vendem certificados.

Também vale saber quão pouco do CSR sobrevive. A CA valida os nomes e emite o certificado com o próprio número de série, as próprias datas de validade, o próprio emissor e a própria visão de quais extensões devem constar. Os campos de organização e localização vêm dos registros validados pela CA, não do que você digitou. Na prática, o que chega ao certificado são a chave pública e os nomes.

O Common Name está obsoleto; o que importa são os SANs

Por razões históricas, o common name do subject parece ser o campo que nomeia o site, e há anos ele não funciona assim. O Chrome deixou de considerá-lo em 2017, os outros navegadores fizeram o mesmo, e o CA/Browser Forum exige que todo nome coberto por um certificado apareça na extensão subject alternative name. Um certificado com CN e sem SAN é rejeitado por todos os clientes atuais, não importa o que o CN diga.

Então a lista de SANs é o primeiro campo a ler, e ela precisa conter todos os hostnames que o certificado vai atender - inclusive o domínio sem www, se ele também for servido. Curingas cobrem exatamente um rótulo: *.example.com corresponde a www.example.com, mas não a example.com nem a a.b.example.com.

Num CSR, é fácil não ver os SANs, e muitos decodificadores não veem. Num certificado emitido eles são uma extensão de primeiro nível; numa solicitação ficam aninhados dentro de um atributo extensionRequest, dois níveis abaixo. Esta ferramenta procura no lugar certo, então uma lista vazia aqui significa que o CSR realmente não tem SANs - algo que vale corrigir antes de enviá-lo.

Lendo um certificado

Além do subject e da validade, algumas extensões determinam o que um certificado pode fazer, e é nelas que costumam estar as respostas interessantes.

Basic constraints diz se é um certificado de CA. CA:TRUE num certificado final é uma emissão incorreta grave; CA:FALSE é o que um certificado de servidor deve mostrar. Key usage e extended key usage restringem para que a chave pode ser usada - serverAuth para um servidor TLS, clientAuth para TLS mútuo - e um certificado sem o uso que o cliente espera será rejeitado mesmo que todo o resto esteja correto.

Authority information access traz a URL do certificado emissor, que é como alguns clientes consertam uma cadeia incompleta, e a URL do respondedor OCSP. Os carimbos de certificate transparency mostram que o certificado foi registrado publicamente, o que os navegadores hoje exigem. Os identificadores de chave da autoridade e do subject são o que a montagem da cadeia realmente compara, e são mais confiáveis do que comparar strings de emissor e subject a olho.

Para impressões digitais, prefira SHA-256; o SHA-1 aparece só porque muitos consoles e configurações de pinning ainda o exibem. Ambos são calculados sobre a codificação DER e batem com o que o openssl mostra.

Problemas de cadeia

A falha de certificado mais comum não está no certificado. Está na cadeia: um servidor que funciona no navegador do desktop e falha no curl, num app mobile ou num cliente JVM.

O servidor precisa apresentar o próprio certificado e todos os intermediários até a raiz, sem incluí-la. Navegadores costumam disfarçar um intermediário ausente buscando-o pela URL de authority information access ou usando uma cópia em cache de outro site, então o problema fica invisível para quem testa no Chrome e aparece na hora para todo o resto. Enviar também a raiz não faz mal, mas é inútil - o cliente já a tem ou não confia nela.

A ordem importa na cadeia TLS clássica: primeiro o certificado final, depois cada emissor em sequência. Colar uma cadeia completa aqui decodifica cada bloco separadamente, na ordem informada, o que deixa evidente um intermediário ausente ou fora de lugar. Compare o emissor de cada certificado com o subject do seguinte e verifique também as datas de expiração dos intermediários - eles também expiram, e um intermediário expirado quebra um certificado final perfeitamente válido.

Gerar a requisição e a chave por trás dela

Um CSR é sempre produzido junto com um par de chaves, e a chave é a parte que importa. O comando convencional gera os dois de uma vez: openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr. A flag -nodes deixa a chave sem criptografia, que é o que um servidor web precisa para subir sem pedir uma senha, e é também por isso que esse arquivo tem de ser legível apenas pela conta de serviço.

RSA de 2048 bits continua sendo o padrão seguro em termos de compatibilidade. ECDSA na curva P-256 oferece segurança equivalente com chaves muito menores e handshakes mais rápidos, é gerado com openssl ecparam -genkey -name prime256v1, e todo navegador atual aceita. Alguns middleboxes antigos e clientes Java legados não aceitam, e esse é o único argumento real que ainda resta a favor do RSA.

Os subject alternative names são o campo que as pessoas esquecem, porque os prompts interativos não perguntam por eles. Eles precisam ser fornecidos por um arquivo de configuração ou pela flag -addext, como em -addext "subjectAltName=DNS:example.com,DNS:www.example.com". Uma requisição sem eles será recusada ou, pior, dará origem a um certificado que navegador nenhum vai aceitar.

A emissão automatizada mudou o fluxo de trabalho

O ciclo manual - gerar um CSR, colá-lo no portal de um fornecedor, esperar, baixar um certificado, instalá-lo e repetir tudo no ano seguinte - hoje é exceção. O protocolo ACME, que o Let's Encrypt lançou em 2016, automatiza a troca inteira: o cliente prova que controla o domínio, envia um CSR e recebe um certificado, normalmente em segundos e sem nenhum humano envolvido.

O controle do domínio é provado de uma entre três maneiras. O HTTP-01 serve um token em um caminho well-known, o que exige que a porta 80 esteja acessível. O DNS-01 publica um registro TXT, e é o único método capaz de emitir curingas e o único que funciona para um host sem servidor web público. O TLS-ALPN-01 responde a um handshake especial na porta 443, útil onde apenas essa porta está aberta.

Certificados emitidos assim valem 90 dias por decisão de projeto, partindo da ideia de que uma vida curta limita o estrago de uma chave vazada e obriga o caminho de renovação a ser automatizado em vez de lembrado. Os clientes renovam por volta de dois terços da validade, de modo que uma falha tem tempo de ser notada antes que algo expire.

Níveis de validação, curingas e o que um certificado prova

A validação de domínio prova apenas que quem pediu o certificado controlava o domínio naquele momento. As validações de organização e estendida acrescentam verificações sobre a pessoa jurídica por trás dele, que aparecem nos campos de assunto do certificado emitido. Os navegadores deixaram de dar qualquer tratamento visual especial ao EV há anos, então a diferença prática hoje é sobretudo contratual e processual, e não algo que um visitante consiga ver.

Um curinga cobre exatamente um rótulo: *.example.com casa com www e api, mas não com example.com em si nem com a.b.example.com. É por isso que a maioria dos certificados curinga lista o domínio puro como um SAN adicional. Curingas também concentram risco, já que o comprometimento de uma única chave afeta todos os hosts sob aquele nome, e não podem ser emitidos sem controle do DNS.

Nada disso diz qualquer coisa sobre o site ser confiável. Um certificado significa que a conexão está criptografada e que o nome confere; nunca significou que o operador é honesto. Sites de phishing têm certificados válidos como regra, e é por isso que as interfaces dos navegadores pararam de sugerir o contrário.

Expiração é um problema de operação, não do certificado

Quedas causadas por certificados expirados são comuns o bastante para formar um gênero próprio: já derrubaram redes de pagamento, operadoras de telefonia móvel e consoles de nuvem. O certificado fez exatamente o que foi projetado para fazer; o que falhou foi o processo em volta dele.

O monitoramento deve alertar pelos dias restantes, e não pela falha, com um limiar distante o suficiente para dar tempo de agir - duas semanas para um certificado de 90 dias, um mês para um de um ano. Monitore o endpoint, e não o arquivo, porque o certificado que importa é o que o servidor está realmente apresentando, e verifique também os intermediários: eles expiram do mesmo jeito, e um intermediário expirado quebra um certificado folha perfeitamente válido.

Os logs de certificate transparency dão a você um inventário gratuito. Todo certificado publicamente confiável é registrado, então uma busca pelo seu domínio mostra o que existe, inclusive certificados que outra pessoa da organização emitiu e esqueceu de avisar.

Ler a cadeia quando algo não funciona

O comando isolado mais útil é openssl s_client -connect host:443 -servername host, que mostra o que o servidor apresenta em vez do que está no seu arquivo de configuração. A cadeia impressa deve começar pelo certificado folha e seguir com cada emissor na ordem, e a linha de issuer de cada certificado deve bater com a linha de subject do certificado seguinte.

Um intermediário faltando é a falha clássica, e ela é invisível em um navegador de desktop, porque os navegadores buscam o certificado ausente ou já o têm em cache de outro site. Curl, aplicativos móveis e clientes JVM não fazem isso, então o sintoma é um site que funciona para quem está testando e falha para uma parcela grande do tráfego real.

Quando a cadeia parece correta e a conexão ainda assim falha, os próximos pontos a verificar são as extensões de key usage, se o cliente confia na raiz em primeiro lugar, e o relógio do cliente - um dispositivo com a data errada rejeita um certificado perfeitamente válido como ainda não válido.