Também disponível em: English · Español · Français · العربية
Decodificador de certificado SSL
Leia um certificado X.509 no seu próprio navegador e veja onde ele cumpre e onde não cumpre a RFC 5280.
O que um decodificador de certificado mostra
Um certificado SSL é uma estrutura X.509 codificada em DER, normalmente embrulhada na armadura base64 que forma um arquivo PEM. Dentro dele estão o nome do titular e o do emissor, um número de série, as duas datas entre as quais o certificado vale, uma chave pública e uma lista de extensões — das quais a que importa para um site é o nome alternativo do titular, já que os navegadores deixaram de aceitar o nome comum como nome de host há anos.
Decodificar tudo isso não precisa de servidor. É uma leitura em nível de bytes de um perfil bem estreito de uma codificação, e é por isso que esta página faz o trabalho na aba que você já tem aberta em vez de pedir que envie algo. Isso importa menos num certificado público de servidor do que numa chave privada, mas o hábito de colar material criptográfico no formulário dos outros não é um hábito que valha a pena ter, e este site mantém a mesma posição no decodificador de JWT.
O que quase nenhum decodificador conta é se o certificado realmente segue as regras. A RFC 5280 é bem específica em várias coisas fáceis de conferir e fáceis de errar, e há certificados reais no seu próprio repositório de confiança que as quebram.
Como usar
- Cole o certificado. Um bloco PEM inteiro, só o base64 entre as linhas da armadura, ou hex puro. Os três funcionam, e espaços são ignorados.
- Leia os campos. Nomes, série, validade, chave e extensões. As duas datas mostram ainda qual tipo de tempo ASN.1 as codifica, que é justamente a parte que acaba importando.
- Confira a lista de conformidade. Tudo o que o certificado faz e a RFC 5280 proíbe ou desaconselha vem explicado, com o motivo. Um certificado conforme também é dito como tal.
A regra que quase ninguém confere, e as raízes que a quebram
A seção 4.1.2.5 da RFC 5280 é peculiar. Ela não apenas permite duas formas de escrever uma data: ela impõe qual usar, conforme o ano. Datas até 2049 têm de ser UTCTime, e datas de 2050 em diante têm de ser GeneralizedTime. O motivo é que UTCTime carrega um ano de dois dígitos, com 00 a 49 lidos como 20xx e 50 a 99 como 19xx, então a codificação simplesmente não consegue expressar 2050.
Isso dá à regra um formato estranho. Metade dela é imposta pela codificação e não pode ser quebrada — nenhum certificado consegue pôr 2050 num UTCTime, porque não há onde. A outra metade não é imposta por nada, e é quebrada. Dos 150 certificados raiz de um repositório de confiança padrão, 149 codificam suas datas como UTCTime e um usa GeneralizedTime vencendo em 2046, quatro anos antes de a troca ser permitida. O Certum Trusted Network CA 2 está no repositório de confiança padrão de praticamente todo navegador e sistema operacional, e você pode carregá-lo na caixa acima e ver o aviso.
O mesmo repositório revela uma segunda violação com mais frequência. A seção 4.1.2.2 diz que o número de série de um certificado tem de ser um inteiro positivo. Oito das 150 raízes têm número de série zero, entre elas duas raízes da Go Daddy e duas da autoridade Hellenic Academic and Research Institutions. Zero não é positivo, e o OpenSSL vai imprimir serial=00 para todas elas se você preferir conferir com outra coisa que não esta página.
Nenhuma das duas torna um certificado perigoso. São daquelas coisas que eram permitidas por seja lá o que gerou o certificado uma década ou mais atrás e vêm sendo herdadas em silêncio desde então. Vale mostrá-las porque um decodificador que só informa os campos está dizendo o que o certificado diz, não se ele está bem formado.
Limites honestos e como isto foi conferido
Isto lê um certificado; não verifica um. Não há checagem de assinatura, nem construção de cadeia, nem consulta de revogação, nem decisão de confiança, porque tudo isso precisa do certificado do emissor e de uma fonte de revogação atual, e uma página não pode fingir honestamente ter nenhum dos dois. Se a ferramenta diz que um certificado é autoassinado, isso é uma afirmação sobre dois nomes iguais, não sobre a assinatura ser válida.
Ela também decodifica apenas as extensões que vale a pena resumir, e mostra o resto como identificador de objeto e bytes crus. Políticas de certificado e marcas de tempo de transparência são estruturas por si só, e decodificá-las pela metade seria pior do que mostrá-las como estão.
O parser é conferido contra o OpenSSL sobre os 150 certificados raiz de um repositório real: todos os números de série, todas as versões, os dois instantes de validade e todos os atributos do titular batem, com 326 verificações e 15 controles negativos. Três divergências apareceram nesse trabalho e as três eram erros da comparação, não do parser, inclusive uma que só surgiu porque o OpenSSL escapa texto não ASCII na saída enquanto o parser o decodifica. Os casos que um repositório de confiança não fornece — uma série com mais de vinte octetos, um certificado que não seja autoassinado, um nome em BMPString — são construídos do zero na suíte de testes, porque uma regra que nada no corpus viola não está sendo testada de verdade.
Por que é grátis?
Não há servidor envolvido. Ler DER é aritmética sobre bytes, roda no seu navegador, e não há o que cobrar nem cadastro a fazer.
Nada do que você colar é enviado, guardado ou registrado. Um certificado público não é segredo, mas a caixa acima aceita de bom grado coisas que são, e o único desenho seguro é aquele em que isso não pode importar.