Analisador de certificado VMC

Por que analisar um certificado de marca

Um certificado de marca custa de 1.000 a 1.500 dólares por ano. Recebê-lo não prova nada sobre o funcionamento dele.

Entre o arquivo entregue pela autoridade e o logo que aparece em uma caixa de entrada existem um registro DNS, um endereço https, uma política DMARC e um domínio de envio que precisa constar no certificado. Quando o logo não aparece, a causa se esconde nessa cadeia, e os decodificadores clássicos se limitam a mostrar um titular e duas datas.

Este analisador decodifica o certificado e depois confronta cada fato medido com o perfil VMC, com o RFC 3709 para o logotype e com o RFC 5280 para o resto. Ele retorna um veredicto de quatro estados e a lista das constatações que o fundamentam, com a fonte de cada uma. O catálogo tem 44 códigos; o número de constatações emitidas depende do certificado analisado.

Os momentos em que ele serve:

• Ao receber o certificado, antes de publicar qualquer coisa no DNS.
• Quando o logo continua invisível apesar de uma configuração que parece correta.
• Antes de uma renovação, para comparar o arquivo antigo e o novo nos domínios cobertos.

O que o analisador verifica

Sete famílias de controles, 44 códigos, três níveis de gravidade. A tabela mostra a pergunta que cada família resolve.

VMC ou CMC, o relatório nomeia o perfil. O programa BIMI emite dois tipos de certificado de marca: o VMC, apoiado em uma marca registrada, e o CMC, emitido mediante prova de uso anterior do logo. Nenhum identificador de política separa os dois, e isso foi medido em 37 certificados reais: dois certificados de perfis diferentes, emitidos pela mesma autoridade, declaram exatamente as mesmas políticas. Por isso o analisador lê o atributo de titular markType, aquele que o programa define para essa finalidade, e o relatório diz qual dos dois você tem em mãos. Um CMC continua sendo um perfil legítimo: a constatação é reportada como informação, não rebaixa o veredicto e apenas lembra que o suporte dos provedores de e-mail é mais estreito.

A calibragem das gravidades segue uma regra única: só classificar como bloqueante aquilo que com certeza é culpa do certificado. Uma extensão mal codificada que o nosso decodificador não conseguiu ler continua sendo um aviso, porque a dúvida está do nosso lado. Essa disciplina tem um custo, e também um benefício: quando o veredicto sai como não conforme, a frase é forte e o leitor pode acreditar nela.

A verificação do logo embutido

É o controle que separa esta ferramenta de um decodificador. Ele responde a uma pergunta que nenhuma outra página faz: a imagem que este certificado carrega é a que a autoridade validou?

O mecanismo vem do RFC 3709 §4.1. A extensão logotype 1.3.6.1.5.5.7.1.12 transporta, para cada imagem, um par formado por algoritmo e impressão digital. O RFC 6170 detalha o resto: a imagem é um SVG Tiny, compactado em gzip, codificado em uma URI data:. O analisador extrai essa imagem, descompacta, recalcula a impressão digital com o algoritmo que o certificado declara, e compara.

Três desfechos, três mensagens. Impressões digitais iguais, o caso nominal, relatado como informação porque é a prova que você veio buscar. Impressões digitais divergentes, constatação bloqueante: o arquivo foi modificado depois da verificação da autoridade, e esse certificado não deve ser publicado. Nenhuma imagem embutida, aviso: o logo só é referenciado por URI, a integridade deixa de ser verificável offline e a exibição depende de um servidor terceiro.

A decodificação recusa várias armadilhas que até aqui produziam falsas divergências. Só o subjectLogo, ramo direto, é lido: o logo da autoridade e os de uma comunidade carregam outras impressões digitais e não têm nada a fazer na comparação. Só a primeira imagem da sequência é considerada, senão a impressão digital da segunda acabaria confrontada com a primeira.

Diante de uma divergência confirmada, a ação não se discute: recupere o SVG que você forneceu à autoridade no pedido, ou solicite uma reemissão. Republicar uma imagem retocada depois da emissão quebra o vínculo, e o gerador de logo BIMI lembra as restrições de formato a respeitar.

Dois falsos defeitos, medidos em certificados reais

Um analisador que manda corrigir aquilo que a DigiCert e a GlobalSign emitem não analisa mais nada. Duas constatações foram recalibradas depois de medições em seis certificados reais, nas três autoridades do programa.

A impressão digital do logo apenas em SHA-1. Quatro certificados em seis declaram só esse algoritmo, todos emitidos pela DigiCert. O papel dessa impressão digital é emparelhar uma imagem e um certificado; o verificador já possui a imagem e recalcula o valor por conta própria, sem deixar uma segunda escolha a um adversário. Classificar esse caso como aviso produziria um falso positivo em massa na principal autoridade do programa. O analisador o relata como informação.

A extensão keyUsage ausente. Cinco certificados em seis não a trazem, em duas autoridades de três, e eles exibem o logo em produção. O RFC 5280 §4.2.1.3 exige keyUsage somente nos certificados cuja chave valida assinaturas de outros certificados, ou seja, nas autoridades. Em uma folha, ela é opcional. A constatação continua aparecendo, como informação, porque explica por que os controles de uso da chave não foram avaliados.

Essas duas linhas valem sobretudo como manual de leitura do relatório. Uma constatação em informação não pede nenhuma ação: ela documenta. Não peça uma reemissão de 1.200 dólares por causa de um fato relatado.

Os quatro veredictos, e o que cada um pede

Quatro veredictos possíveis, um por análise, cada um com a ação que pede.

O quarto estado existe porque o caso é frequente, e escrever "o seu certificado de marca não está conforme" a respeito de um objeto que não é um seria falso. Dois caminhos levam até ele. Nem política de marca nem extensão logotype: é o certificado TLS do site, colado por engano, e a presença do uso serverAuth confirma isso. Ou então basicConstraints declara cA=TRUE, e o objeto é uma autoridade de certificação, quase sempre o intermediário entregue no mesmo arquivo PEM que o certificado folha.

Esse segundo caso produzia antes um relatório inteiramente falso. O intermediário recebia críticas escritas para uma folha, entre elas um uso keyCertSign julgado excessivo quando uma autoridade precisa carregá-lo, e uma linha afirmando que se tratava de um Verified Mark Certificate. Agora ele é reconhecido e nomeado, sem outro julgamento.

O domínio esperado, campo opcional

Esse campo comanda exatamente duas das 44 constatações. Se ficar vazio, você perde só essas duas, e nada mais.

Informe nele o domínio que publica o seu registro BIMI. O analisador procura então uma entrada dNSName do certificado que o cubra, e retorna coberto ou uma divergência bloqueante. A armadilha habitual é o wildcard: no sentido do RFC 9525 §6.3, ele desce um só nível. *.exemplo.com.br cobre mail.exemplo.com.br, mas nem exemplo.com.br, nem a.b.exemplo.com.br.

Uma divergência aqui não se conserta com uma alteração no DNS. O certificado não cobre esse domínio, é preciso pedir uma reemissão. Melhor pensar nisso já no pedido, subdomínios transacionais incluídos.

O que este analisador não diz

Três limites, declarados porque uma ferramenta que os cala deixa acreditar em garantias que ela não oferece.

A revogação não é verificada. Nenhuma consulta OCSP, nenhuma lista de revogação. Um certificado revogado pela sua autoridade sai como conforme se o conteúdo dele for conforme.

A organização emissora não é julgada. Nenhuma lista de autoridades credenciadas está fixada no código, e isso é deliberado: uma lista assim ficaria errada no dia em que o BIMI Group credenciar um novo emissor, e ficaria errada em silêncio. O julgamento passa pela política de certificação declarada e pelo vínculo da cadeia, não por um nome.

A cadeia não sobe até uma raiz de marca. As raízes do programa, medidas no corpus, estão ausentes dos dois repositórios verificáveis localmente: o repositório de sistema da Apple, 127 raízes, e o pacote Mozilla distribuído pelo curl, 190 raízes. Elas formam um repositório próprio do programa, que nem um sistema operacional nem uma imagem de contêiner carregam. Consequência aplicada na ferramenta: uma falha de verificação nunca vira uma constatação bloqueante, já que ela não prova mais nada. Uma cadeia que verifica continua sendo uma boa notícia; uma cadeia que não verifica não diz nada sobre o certificado.

Publicar o certificado, uma vez validado

O veredicto não faz o logo aparecer. Quatro coisas precisam se sustentar juntas.

DMARC primeiro: o domínio de envio precisa estar em p=quarantine ou p=reject; caso contrário, nenhum provedor de e-mail olhará o resto. O arquivo PEM depois, servido em https em um endereço estável, aquele que a tag a= do seu registro _bimi indica. O logo SVG, servido do mesmo modo, referenciado pela tag l=. O domínio de envio, enfim, presente entre os domínios certificados.

Sirva sempre o arquivo completo, folha seguida dos intermediários, tal como a autoridade o entregou. Um certificado servido sozinho dispara um aviso de cadeia incompleta, e alguns verificadores param por aí.

Quanto ao calendário, um certificado de marca vive um ano. O analisador passa a aviso nos 30 últimos dias e sinaliza o vencimento já nos 60 últimos, mas um relatório pontual não substitui um monitoramento. Anote a data e leia o nosso guia sobre os certificados VMC e CMC para escolher entre os dois perfis no momento da renovação. Se o logo continuar ausente depois da publicação, cinco causas comuns cobrem a maioria dos casos.

Privacidade

Dois caminhos, dois comportamentos, e a ferramenta diz qual se aplica antes de você clicar.

Um certificado colado no formato PEM é analisado offline: decodificação em memória, nenhuma conexão de saída, nenhum arquivo guardado. Já um endereço https será baixado pelos nossos servidores em uma única requisição limitada, o que a nota abaixo do botão indica em tempo real. De todo modo, um certificado não é um segredo: ele carrega uma chave pública e identificadores destinados a serem publicados.

O campo domínio esperado só é usado para o controle de cobertura. Acima de dez blocos CERTIFICATE em um mesmo envio, o excedente é ignorado e o relatório avisa.

FAQ - Perguntas frequentes

P: O que é um certificado VMC?

R: Um Verified Mark Certificate é um certificado X.509 que vincula um logo a uma organização cujos direitos de marca foram verificados. Ele embute a imagem em uma extensão logotype (RFC 3709) e declara uma política de certificação própria do programa. Gmail, Yahoo Mail e Apple Mail usam esse certificado para exibir o seu logo, desde que o DMARC esteja em p=quarantine ou p=reject. Três autoridades o emitem hoje: DigiCert, Entrust e GlobalSign.

P: Por que o meu logo não aparece mesmo com o certificado válido?

R: O certificado é apenas um dos elos. Confira na ordem: DMARC em p=quarantine ou p=reject no domínio de envio, o registro _bimi publicado, a tag a= apontando para um endereço https que serve o PEM, e o domínio de envio presente entre os domínios certificados. É esse último ponto que o campo domínio esperado resolve aqui. Os caches dos provedores de e-mail acrescentam depois um atraso de várias horas.

P: O analisador confere se o logo embutido é o que a autoridade validou?

R: Sim, e é o controle que distingue esta ferramenta. A imagem SVG é extraída da extensão logotype, descompactada, e sua impressão digital é recalculada com o algoritmo que o próprio certificado declara. Se o valor recalculado diferir do valor declarado, a constatação é bloqueante: o arquivo mudou depois da verificação pela autoridade. Essa comparação não funcionava em nenhum certificado real antes da reformulação da ferramenta.

P: O meu certificado declara a impressão digital do logo em SHA-1, isso é um defeito?

R: Não. Em seis certificados reais medidos em três autoridades, quatro declaram a impressão digital do logo apenas em SHA-1: é o que a DigiCert emite. O papel dessa impressão digital é emparelhar uma imagem e um certificado, não erguer uma barreira anticolisão, já que o verificador tem a imagem em mãos e recalcula o valor. O analisador relata o fato sem rebaixar o veredicto.

P: A extensão keyUsage está ausente do meu VMC, preciso pedir uma reemissão?

R: Não. A extensão falta em cinco dos seis certificados medidos, em duas das três autoridades do programa, e esses certificados exibem o logo em produção. O RFC 5280 §4.2.1.3 só exige keyUsage nos certificados de autoridade; em uma folha, ela continua opcional. A constatação é relatada como informação, para explicar por que os controles de uso da chave não foram avaliados.

P: O que significa o veredicto "não é um certificado de marca"?

R: Que o objeto colado não pertence ao perfil VMC, e há dois caminhos para chegar lá. O primeiro: nem política de marca nem extensão logotype, ou seja, o certificado TLS do site colado no lugar do VMC. O segundo: basicConstraints declara cA=TRUE, portanto trata-se de uma autoridade de certificação, muitas vezes o intermediário entregue no mesmo arquivo PEM. Nesse caso, o certificado folha é o primeiro bloco do arquivo.

P: Para que serve o campo domínio esperado?

R: Para conferir se o domínio que publica o seu registro BIMI está entre os domínios certificados do certificado. O campo é opcional e comanda exatamente duas das 44 constatações: coberto, ou em divergência. Atenção ao wildcard, que desce um só nível no sentido do RFC 9525 §6.3: *.exemplo.com.br cobre mail.exemplo.com.br, mas não exemplo.com.br nem a.b.exemplo.com.br.

P: Quanto custa um certificado VMC, e por quanto tempo ele vale?

R: Da ordem de 1.000 a 1.500 dólares por ano na DigiCert, na Entrust ou na GlobalSign, preço que cobre a verificação da marca registrada em um órgão reconhecido. A validade usual é de um ano. Programe a renovação com antecedência: o analisador sinaliza os 30 últimos dias como aviso e os 60 últimos como informação, e um certificado expirado faz o logo desaparecer sem outro pré-aviso.

Ferramentas complementares

Recursos úteis

• RFC 3709 - extensão logotype dos certificados (estrutura logotypeHash, impressão digital declarada do logo)
• RFC 6170 - imagem em um certificado X.509 (SVG Tiny compactado, transportado em URI data:)
• RFC 5280 - perfil dos certificados X.509 (validade, basicConstraints, keyUsage, SAN)
• RFC 9525 - verificação de identidade de serviço (alcance do wildcard em um SAN)
• BIMI Group - certificados de marca verificada (perfil VMC, autoridades credenciadas)
• Especificação BIMI (tags a= e l=, pré-requisito DMARC)