Visualizador de Certificado SSL e CSR

Visão geral

Um certificado é um conjunto assinado de afirmações em DER, uma codificação binária, embrulhado em Base64 para transporte. Tudo o que corre mal com certificados na prática é visível nessas afirmações: um nome ausente da lista SAN, uma janela de validade que termina mais cedo do que se esperava, um intermédio colado onde vai uma folha, um uso de chave que proíbe o uso para que foi comprado.

Este visualizador descodifica o PEM, analisa o DER e apresenta o conteúdo — tanto para certificados X.509 como para pedidos de certificado PKCS#10. Fá-lo no seu navegador, e recusa terminantemente chaves privadas.

Como usar

1. Cole um bloco PEM que comece por -----BEGIN CERTIFICATE----- ou -----BEGIN CERTIFICATE REQUEST-----.
2. Leia a síntese: tipo, sujeito, emissor, validade, dias restantes.
3. Confronte a lista SAN com os nomes de anfitrião que espera servir.

Para obter um certificado em uso a partir de um servidor: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509

Os nomes alternativos são os únicos que contam

O Common Name do sujeito parece o nome do certificado e, para a validação do nome de anfitrião, não é usado. O Chrome ignorou-o desde a versão 58, e os outros navegadores seguiram. Apenas a extensão subjectAltName é consultada.

As consequências práticas:

• Um certificado cujo nome de anfitrião aparece apenas no CN falha a validação em todos os navegadores atuais, e ao mesmo tempo parece completamente correto em qualquer ferramenta que exiba o sujeito em destaque.
• Um curinga *.example.com corresponde a uma só etiqueta. Cobre www.example.com e não a.b.example.com, e não cobre o example.com nu — esse nome precisa da sua própria entrada SAN, e por isso os certificados listam habitualmente ambos.
• Os SAN têm tipo. As entradas dNSName, iPAddress, rfc822Name e URI são todas exibidas, e um nome de anfitrião colocado no tipo errado não corresponde.

Como ler a chave e o seu uso

O algoritmo e o tamanho da chave são lidos da estrutura da chave pública. Para RSA, o comprimento do módulo dá diretamente o tamanho em bits. Para EC é indicada a curva nomeada quando existe uma e, quando o certificado transporta parâmetros explícitos em vez de um nome de curva, isso é declarado como tal — os parâmetros explícitos são rejeitados pela maioria das pilhas TLS modernas, pelo que vale a pena vê-lo. Sem nome de curva, o tamanho é deduzido do comprimento do ponto público, e é por isso que uma chave P-521 é relatada como 521 e não como os 528 que uma contagem ingénua de bytes daria.

keyUsage e extendedKeyUsage descrevem o que a chave está autorizada a fazer, e ambos são impostos. Um certificado sem serverAuth no seu EKU não funcionará para TLS mesmo que tudo o resto esteja correto — resultado frequente quando um certificado de cliente é instalado por engano num servidor.

basicConstraints diz se o certificado é uma AC. Se colou aquilo que julgava ser o seu certificado folha e ele é relatado como AC, colou o intermédio — a causa habitual de uma cadeia que valida localmente e falha noutros lugares.

A lista de extensões mostra cada extensão presente com o seu indicador de crítica. Uma extensão crítica que o cliente não compreenda tem de provocar a rejeição, segundo a RFC 5280, pelo que uma extensão crítica desconhecida merece ser investigada.

Exemplos

• Um nome que não valida — verifique a lista SAN, não o sujeito. Se o nome de anfitrião só estiver no CN, o certificado tem de ser reemitido.
• Ler uma CSR antes de a enviar — a CSR fixa o sujeito e a chave pública. Confirmar os nomes antes da submissão evita um ciclo de reemissão, sobretudo quando a AC o cobra.
• Confirmar que certificado tem — folha, intermédio e raiz parecem-se como texto. basicConstraints e a relação entre sujeito e emissor identificam-nos de imediato: uma raiz tem sujeito e emissor idênticos.
• Planear renovações — os dias restantes são exibidos diretamente. Com o sector a avançar para durações máximas muito mais curtas, um processo de renovação manual que funcionava para certificados anuais não sobrevive a essa mudança.
• Auditar um conjunto — cole cada bloco à vez. Um conjunto na ordem errada, ou com um certificado sem relação incluído, é uma causa frequente de erro de cadeia que só aparece em alguns clientes.

Observações

Apenas os blocos PEM CERTIFICATE e CERTIFICATE REQUEST são aceites. Qualquer outro tipo de bloco, incluindo todos os formatos de chave privada, é recusado com um erro que nomeia o que foi encontrado. De um bloco recusado nada é analisado nem exibido.

O analisador DER rejeita o que o DER proíbe: codificações de comprimento indefinido, comprimentos que passam do fim do tampão e aninhamento além de 32 níveis. Uma colagem truncada produz uma mensagem concreta como ASN.1 length exceeds buffer em vez de um relatório parcialmente preenchido, porque um certificado analisado a meio convida à leitura errada. Quando a análise falha, qualquer resultado anterior é apagado pela mesma razão.

As datas são exibidas tal como estão codificadas no certificado. GeneralizedTime transporta um ano de quatro dígitos; UTCTime transporta dois, e a RFC 5280 fixa a interpretação em 50–99 para 19xx e 00–49 para 20xx. Os dias restantes são calculados contra o relógio do seu dispositivo, pelo que uma hora de sistema errada dá um número errado.

Esta ferramenta lê um certificado isoladamente. A construção da cadeia, a revogação e a confiança não são avaliadas. Para ver o que um servidor envia realmente e como responde, use cabeçalhos HTTP e o verificador de cabeçalhos de segurança. Tudo aqui acontece no seu navegador — ver a política de privacidade.