Analisador de certificado VMC

Porque analisar um certificado de marca

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

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

Este analisador descodifica o certificado e depois confronta cada facto medido com o perfil VMC, com o RFC 3709 para o logotype e com o RFC 5280 para o resto. Devolve 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 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 ficheiro antigo e o novo nos domínios cobertos.

O que o analisador verifica

Sete famílias de controlos, 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 numa marca registada, 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 tem em mãos. Um CMC continua a ser um perfil legítimo: a constatação é reportada como informação, não rebaixa o veredicto e apenas lembra que o suporte dos fornecedores 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 descodificador não conseguiu ler continua a ser 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 controlo que separa esta ferramenta de um descodificador. 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 numa 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 veio buscar. Impressões digitais divergentes, constatação bloqueante: o ficheiro 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 descodificaçã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 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 já não analisa 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 relata-o como informação.

A extensão keyUsage em falta. Cinco certificados em seis não a trazem, em duas autoridades de três, e 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. Numa folha, ela é opcional. A constatação continua a aparecer, como informação, porque explica porque os controlos 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 1200 dólares por causa de um facto 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 ficheiro 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 é reconhecido e nomeado, sem outro julgamento.

O domínio esperado, campo opcional

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

Informe nele o domínio que publica o seu registo BIMI. O analisador procura então uma entrada dNSName do certificado que o cubra, e devolve 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.pt cobre mail.exemplo.pt, mas nem exemplo.pt, nem a.b.exemplo.pt.

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 em falta nos 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 operativo nem uma imagem de contentor carregam. Consequência aplicada na ferramenta: uma falha de verificação nunca se torna uma constatação bloqueante, já que ela não prova nada. Uma cadeia que verifica continua a ser 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 de se sustentar juntas.

DMARC primeiro: o domínio de envio tem de estar em p=quarantine ou p=reject; caso contrário, nenhum fornecedor de e-mail olhará o resto. O ficheiro PEM depois, servido em https num endereço estável, aquele que a tag a= do seu registo _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 ficheiro 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 uma monitorização. 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 em falta 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 clicar.

Um certificado colado no formato PEM é analisado offline: descodificação em memória, nenhuma ligação de saída, nenhum ficheiro guardado. Já um endereço https será descarregado pelos nossos servidores numa ú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 controlo de cobertura. Acima de dez blocos CERTIFICATE num 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 numa 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. Emitem-no a DigiCert, a Entrust e a GlobalSign, entre outras autoridades credenciadas pelo BIMI Group.

P: Porque é 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 registo _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 fornecedores 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 controlo que distingue esta ferramenta. A imagem SVG é extraída da extensão logotype, descompactada, e a 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 ficheiro 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 facto sem rebaixar o veredicto.

P: A extensão keyUsage está em falta no 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; numa folha, ela continua opcional. A constatação é relatada como informação, para explicar porque os controlos 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 em vez 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 ficheiro PEM. Nesse caso, o certificado folha é o primeiro bloco do ficheiro.

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

R: Para conferir se o domínio que publica o seu registo 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.pt cobre mail.exemplo.pt, mas não exemplo.pt nem a.b.exemplo.pt.

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

R: Da ordem de 1000 a 1500 dólares por ano na DigiCert, na Entrust ou na GlobalSign, preço que cobre a verificação da marca registada num ó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 num 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 num SAN)
• BIMI Group - certificados de marca verificada (perfil VMC, autoridades credenciadas)
• Especificação BIMI (tags a= e l=, pré-requisito DMARC)