Decodificador de certificados X.509

A ferramenta diz se um certificado é válido para um domínio específico?

Não, e essa é a limitação mais importante antes de usar. A ferramenta só lê e exibe os campos já presentes dentro de um certificado X.509; ela não reproduz nenhuma das etapas que um navegador real executa ao abrir uma conexão HTTPS. Um navegador reconstrói toda a cadeia de confiança até uma raiz que já tem guardada, verifica as Basic Constraints e o Key Usage de cada intermediário para confirmar se ele tinha permissão para assinar o elo seguinte, e ainda consulta o status de revogação via OCSP ou CRL. Nada disso acontece aqui: não há nenhuma lista de raízes embutida, nenhuma requisição de rede é feita para perguntar "esse certificado ainda está válido?", e não existe path validation de nenhum tipo. Você cola um certificado, e a ferramenta responde exatamente uma pergunta — "o que este certificado declara sobre si mesmo" — nunca "se deveria ser confiado". Para responder essa segunda pergunta, o caminho correto é openssl verify com o bundle de CA adequado, ou simplesmente abrir o domínio num navegador real e olhar o cadeado.

Por que a ferramenta marca alguns certificados como "Autoassinado"? Isso é sempre ruim?

O rótulo vem de uma única comparação: o campo issuer é idêntico ao campo subject, e a assinatura foi gerada com a própria chave privada do certificado, não por uma CA separada. A ferramenta tenta primeiro chamar cert.isSelfSigned() da biblioteca @peculiar/x509 para verificar com a assinatura real; se o WebCrypto do navegador não suportar aquele algoritmo de assinatura específico, ela recorre a um método mais simples — comparar a string do subject com a do issuer, o mesmo fallback que os próprios navegadores usam. Ser autoassinado é completamente normal em um certificado raiz de CA (o topo de qualquer cadeia de confiança precisa se autoassinar por definição) e em certificados internos gerados para testes. Só é um sinal preocupante em um contexto específico: se um navegador exibe um aviso de segurança para um site público e o certificado recebido é autoassinado, significa que nenhuma CA reconhecida o validou, e nenhum terceiro está confirmando que o servidor é quem diz ser.

Ao enviar um arquivo com vários blocos BEGIN CERTIFICATE, em que ordem eles são lidos?

Exatamente na ordem em que aparecem no arquivo, nem mais nem menos. A ferramenta procura cada bloco -----BEGIN CERTIFICATE-----...-----END CERTIFICATE----- com uma expressão regular, decodifica um por um, e os exibe rotulados "Certificado 1 de N", "Certificado 2 de N" seguindo essa mesma ordem de leitura — não reordena nada com base em relações issuer/subject. Isso importa na prática: a convenção usual ao montar um fullchain.pem é certificado folha primeiro, depois cada intermediário, e a raiz por último (ou sem incluí-la, já que o cliente já a possui). Se seu arquivo foi montado numa ordem diferente, a ferramenta mostra fielmente essa ordem errada em vez de corrigi-la silenciosamente — o que a torna útil justamente para detectar uma cadeia montada de forma incorreta.

Enviar um arquivo .der/.crt/.cer é diferente de colar o PEM na caixa de texto?

A caixa de texto sempre trata o conteúdo como PEM — texto ASCII envolto em -----BEGIN CERTIFICATE-----. Já ao enviar um arquivo, a ferramenta não confia na extensão: a maioria dos arquivos .cer/.crt/.der é DER binário, mas também existem vários arquivos PEM em texto salvos por engano com essas mesmas extensões. A solução é ler todos os bytes do arquivo, tentar decodificá-los como UTF-8, e verificar se o resultado contém -----BEGIN CERTIFICATE-----. Se contiver, é processado igual ao caminho de colar PEM (incluindo separar vários blocos, caso seja uma cadeia); se não, o buffer binário inteiro é passado direto para o X509Certificate do @peculiar/x509 como DER. Essa detecção pelo conteúdo é mais segura do que confiar na extensão, e é por isso que renomear um .pem para .crt continua funcionando sem problema.

Qual a diferença entre as fingerprints SHA-1 e SHA-256, e qual devo usar?

Uma fingerprint é um hash dos bytes DER brutos do certificado — serve para identificar exatamente um certificado específico, da mesma forma que um checksum identifica um arquivo exato. Dois certificados com a mesma fingerprint são idênticos byte a byte; basta reemitir um certificado com o mesmo subject para a fingerprint mudar completamente. A ferramenta calcula ambas com cert.getThumbprint('SHA-1') e cert.getThumbprint('SHA-256'), e as exibe em hexadecimal maiúsculo separado por dois-pontos, o formato que praticamente qualquer outra ferramenta usa. O SHA-1 ainda é exibido porque bastante documentação antiga, configurações de certificate pinning e ferramentas legadas ainda o referenciam, mas o SHA-1 em si está quebrado para propósitos que exigem resistência a colisões e não deveria ser usado para nada crítico de segurança daqui em diante. O SHA-256 é o valor a usar para comparar com logs de certificate transparency, configurações de pinning modernas, ou qualquer ferramenta escrita nos últimos anos.

Como são calculados os "dias restantes", e o que significam Key Usage / Extended Key Usage?

Os dias restantes são calculados pela diferença entre o campo notAfter do certificado e o momento exato em que você decodificou, convertida para o fuso horário que o próprio objeto Date do seu navegador reporta — normalmente seu horário local, não UTC. Por isso duas pessoas em fusos horários diferentes olhando o mesmo certificado podem ver um número que difere em um dia, simplesmente porque a meia-noite UTC já passou localmente para uma e não para a outra; para qualquer coisa que precise de precisão ao segundo (um script de renovação automática, por exemplo), sempre compare contra o notAfter bruto em UTC, não contra a contagem de dias arredondada. Key Usage é uma máscara de bits com nove indicadores segundo a RFC 5280 (Digital Signature, Key Encipherment, Certificate Signing…) que quem emitiu o certificado embute para declarar quais operações a chave pode realizar; Extended Key Usage restringe ainda mais o propósito com OIDs específicos como "TLS Server Authentication" ou "Code Signing". A ferramenta traz uma tabela com seis OIDs de EKU comuns; um OID fora dessa tabela ainda é exibido na sua forma numérica crua em vez de ser ocultado.