Analyseur de certificat VMC

Pourquoi analyser un certificat de marque

Un certificat de marque coûte de 1000 à 1500 dollars par an. Le recevoir ne prouve rien sur son fonctionnement.

Entre le fichier livré par l'autorité et le logo qui s'affiche dans une boîte de réception, il y a un enregistrement DNS, une adresse https, une politique DMARC et un domaine d'envoi qui doit figurer dans le certificat. Quand le logo n'apparaît pas, la cause se cache dans cette chaîne, et les décodeurs classiques se contentent d'afficher un sujet et deux dates.

Cet analyseur décode le certificat, puis confronte chaque fait mesuré au profil VMC, à la RFC 3709 pour le logotype et à la RFC 5280 pour le reste. Il rend un verdict à quatre états et la liste des constats qui le fondent, avec leur source. Le catalogue compte 44 codes ; le nombre de constats rendus dépend du certificat analysé.

Les moments où il sert :

• À la réception du certificat, avant de publier quoi que ce soit dans le DNS.
• Quand le logo reste invisible malgré une configuration qui semble correcte.
• Avant un renouvellement, pour comparer l'ancien et le nouveau fichier sur les domaines couverts.

Ce que l'analyseur contrôle

Sept familles de contrôles, 44 codes, trois sévérités. Le tableau donne la question que chaque famille tranche.

VMC ou CMC, le rapport nomme le profil. Le programme BIMI délivre deux types de certificats de marque : le VMC, adossé à une marque déposée, et le CMC, délivré sur preuve d'un usage antérieur du logo. Aucun identifiant de politique ne les sépare, et c'est mesuré sur 37 certificats réels : deux certificats de profils différents, émis par la même autorité, déclarent exactement les mêmes politiques. L'analyseur lit donc l'attribut de sujet markType, celui que le programme définit pour cet usage, et le rapport vous dit lequel des deux vous avez en main. Un CMC reste un profil légitime : le constat est rapporté en information, il ne dégrade pas le verdict, et il rappelle seulement que la prise en charge par les fournisseurs de messagerie y est plus étroite.

Le calibrage des sévérités suit une règle unique : ne classer en bloquant que ce dont on est sûr que c'est le certificat qui a tort. Une extension mal encodée que notre décodeur n'a pas su lire reste un avertissement, parce que le doute est de notre côté. Cette discipline a un coût, elle a aussi un avantage : quand le verdict tombe en non conforme, la phrase est forte et le lecteur peut la croire.

La vérification du logo embarqué

C'est le contrôle qui sépare cet outil d'un décodeur. Il répond à une question qu'aucune autre page ne pose : l'image que porte ce certificat est-elle celle que l'autorité a validée ?

Le mécanisme vient de la RFC 3709 §4.1. L'extension logotype 1.3.6.1.5.5.7.1.12 transporte, pour chaque image, un couple algorithme et empreinte. La RFC 6170 précise le reste : l'image est un SVG Tiny, compressé en gzip, encodé dans une URI data:. L'analyseur extrait cette image, la décompresse, la rehache sous l'algorithme que le certificat déclare, et compare.

Trois issues, trois messages. Empreintes égales, le nominal, rapporté en information parce que c'est la preuve que vous êtes venu chercher. Empreintes en écart, constat bloquant : le fichier a été modifié après la vérification de l'autorité, et ce certificat ne doit pas être publié. Aucune image embarquée, avertissement : le logo n'est référencé que par URI, l'intégrité ne se vérifie plus hors ligne et l'affichage dépend d'un serveur tiers.

Le décodage évite plusieurs pièges qui produisaient jusqu'ici de faux écarts. Seul le subjectLogo, branche directe, est lu : le logo de l'autorité et ceux d'une communauté portent d'autres empreintes et n'ont rien à faire dans la comparaison. Seule la première image de la séquence est retenue, sinon l'empreinte de la deuxième se retrouverait opposée à la première.

Sur écart avéré, l'action ne se discute pas : reprenez le SVG que vous aviez fourni à l'autorité lors de la commande, ou demandez une réémission. Republier une image retouchée après émission casse le lien, et le générateur de logo BIMI rappelle les contraintes de format à respecter.

Deux faux défauts, mesurés sur des certificats réels

Un analyseur qui demande de corriger ce que DigiCert et GlobalSign émettent n'analyse plus rien. Deux constats ont été recalibrés après mesure sur six certificats réels, chez les trois autorités du programme.

L'empreinte du logo en SHA-1 seul. Quatre certificats sur six ne déclarent que cet algorithme, tous émis par DigiCert. Le rôle de cette empreinte est d'apparier une image et un certificat ; le vérificateur possède déjà l'image et recalcule la valeur lui-même, sans second choix laissé à un adversaire. Classer ce cas en avertissement produirait un faux positif de masse sur la principale autorité du programme. L'analyseur le rapporte en information.

L'extension keyUsage absente. Cinq certificats sur six n'en portent pas, chez deux autorités sur trois, et ils affichent leur logo en production. La RFC 5280 §4.2.1.3 impose keyUsage aux seuls certificats dont la clé valide des signatures d'autres certificats, c'est-à-dire aux autorités. Sur une feuille, elle est facultative. Le constat reste affiché, en information, parce qu'il explique pourquoi les contrôles d'usage de clé n'ont pas été évalués.

Ces deux lignes valent surtout comme mode d'emploi du rapport. Un constat en information n'appelle aucune action : il documente. Ne demandez pas une réémission à 1200 dollars pour un fait rapporté.

Les quatre verdicts, et ce qu'ils appellent

Quatre verdicts possibles, un seul rendu par analyse, chacun avec l'action qu'il appelle.

Le quatrième état existe parce que le cas est fréquent, et écrire « votre certificat de marque n'est pas conforme » à propos d'un objet qui n'en est pas un serait faux. Deux chemins y mènent. Ni politique de marque ni extension logotype : c'est le certificat TLS du site web, collé par erreur, et la présence de l'usage serverAuth le confirme. Ou bien basicConstraints déclare cA=TRUE, et l'objet est une autorité de certification, presque toujours l'intermédiaire livré dans le même fichier PEM que la feuille.

Ce second cas produisait auparavant un rapport intégralement faux. L'intermédiaire recevait des reproches écrits pour une feuille, notamment un usage keyCertSign jugé excessif alors qu'une autorité doit le porter, et une ligne affirmant qu'il s'agissait d'un Verified Mark Certificate. Il est désormais reconnu et nommé, sans autre jugement.

Le domaine attendu, champ facultatif

Ce champ pilote exactement deux des 44 constats. Laissé vide, il vous prive de ces deux-là, et de rien d'autre.

Indiquez-y le domaine qui publie votre enregistrement BIMI. L'analyseur cherche alors une entrée dNSName du certificat qui le couvre, et rend soit un constat de couverture, soit un écart bloquant. Le piège habituel est le wildcard : au sens de la RFC 9525 §6.3, il ne descend que d'un seul niveau. *.exemple.fr couvre mail.exemple.fr, mais ni exemple.fr, ni a.b.exemple.fr.

Un écart ici ne se répare pas par une modification DNS. Le certificat ne couvre pas ce domaine, il faut le faire réémettre. Autant y penser à la commande, sous-domaines transactionnels compris.

Ce que cet analyseur ne dit pas

Trois limites, énoncées parce qu'un outil qui les tait laisse croire à des garanties qu'il n'apporte pas.

La révocation n'est pas vérifiée. Aucune interrogation OCSP, aucune liste de révocation. Un certificat révoqué par son autorité sortira conforme si son contenu l'est.

L'organisation émettrice n'est pas jugée. Aucune liste d'autorités agréées n'est codée en dur, et c'est délibéré : une telle liste deviendrait fausse le jour où le BIMI Group accrédite un nouvel émetteur, et elle le deviendrait en silence. Le jugement passe par la politique de certification déclarée et par le rattachement de la chaîne, pas par un nom.

La chaîne ne remonte pas jusqu'à une racine de marque. Les racines du programme, mesurées sur le corpus, sont absentes des deux magasins vérifiables localement : le magasin système d'Apple, 127 racines, et le paquet Mozilla que distribue curl, 190 racines. Elles forment un magasin propre au programme, que ni un système d'exploitation ni une image de conteneur ne portent. Conséquence appliquée dans l'outil : un échec de vérification ne devient jamais un constat bloquant, puisqu'il ne prouve rien. Une chaîne qui vérifie reste une bonne nouvelle ; une chaîne qui ne vérifie pas ne dit rien du certificat.

Publier le certificat, une fois validé

Le verdict ne fait pas apparaître le logo. Quatre choses doivent tenir ensemble.

DMARC d'abord : le domaine d'envoi doit être en p=quarantine ou p=reject, sans quoi aucun fournisseur de messagerie ne regardera le reste. Le fichier PEM ensuite, servi en https à une adresse stable, celle que porte le tag a= de votre enregistrement _bimi. Le logo SVG, servi de la même façon, référencé par le tag l=. Le domaine d'envoi, enfin, présent parmi les domaines certifiés.

Servez toujours le fichier complet, feuille suivie des intermédiaires, tel que l'autorité l'a livré. Un certificat servi seul déclenche un avertissement de chaîne incomplète, et certains vérificateurs s'arrêtent là.

Côté calendrier, un certificat de marque vit un an. L'analyseur passe en avertissement dans les 30 derniers jours et signale l'échéance dès les 60 derniers, mais un rapport ponctuel ne remplace pas une surveillance. Notez la date, et lisez notre guide sur les certificats VMC et CMC pour arbitrer entre les deux profils au moment du renouvellement. Si le logo reste absent après publication, cinq causes courantes couvrent la plupart des cas.

Confidentialité

Deux chemins, deux comportements, et l'outil vous dit lequel s'applique avant que vous cliquiez.

Un certificat collé au format PEM est analysé hors ligne : décodage en mémoire, aucune connexion sortante, aucun fichier conservé. Une adresse https, elle, sera téléchargée par nos serveurs en une seule requête bornée, ce que la note sous le bouton indique en temps réel. Un certificat n'est de toute façon pas un secret : il porte une clé publique et des identifiants destinés à être publiés.

Le champ domaine attendu n'est utilisé que pour le contrôle de couverture. Au-delà de dix blocs CERTIFICATE dans un même envoi, le surplus est ignoré et le rapport le signale.

FAQ - Questions fréquentes

Q : Qu'est-ce qu'un certificat VMC ?

R : Un Verified Mark Certificate est un certificat X.509 qui rattache un logo à une organisation dont les droits de marque ont été vérifiés. Il embarque l'image dans une extension logotype (RFC 3709) et déclare une politique de certification propre au programme. Gmail, Yahoo Mail et Apple Mail s'en servent pour afficher votre logo, à condition que DMARC soit en p=quarantine ou p=reject. DigiCert, Entrust et GlobalSign en émettent, parmi d'autres autorités accréditées par le BIMI Group.

Q : Pourquoi mon logo n'apparaît-il pas alors que le certificat est valide ?

R : Le certificat n'est qu'un des maillons. Vérifiez dans l'ordre : DMARC en p=quarantine ou p=reject sur le domaine d'envoi, l'enregistrement _bimi publié, le tag a= qui pointe vers une adresse https servant le PEM, et le domaine d'envoi présent parmi les domaines certifiés. C'est ce dernier point que le champ domaine attendu tranche ici. Les caches des fournisseurs de messagerie ajoutent ensuite un délai de plusieurs heures.

Q : L'analyseur vérifie-t-il que le logo embarqué est celui que l'autorité a validé ?

R : Oui, et c'est le contrôle qui distingue cet outil. L'image SVG est extraite de l'extension logotype, décompressée, puis rehachée sous l'algorithme que le certificat déclare lui-même. Si l'empreinte recalculée diffère de l'empreinte déclarée, le constat est bloquant : le fichier a bougé après vérification par l'autorité. Cette comparaison ne fonctionnait sur aucun certificat réel avant la refonte de l'outil.

Q : Mon certificat déclare l'empreinte du logo en SHA-1, est-ce un défaut ?

R : Non. Sur six certificats réels mesurés chez trois autorités, quatre ne déclarent leur empreinte de logo qu'en SHA-1 : c'est ce que DigiCert émet. Le rôle de cette empreinte est d'apparier une image et un certificat, pas d'opposer une barrière anti-collision, puisque le vérificateur détient déjà l'image et recalcule la valeur. L'analyseur le signale comme un fait, sans dégrader le verdict.

Q : L'extension keyUsage est absente de mon VMC, faut-il demander une réémission ?

R : Non. L'extension manque sur cinq des six certificats mesurés, chez deux des trois autorités du programme, et ces certificats affichent leur logo en production. La RFC 5280 §4.2.1.3 n'impose keyUsage qu'aux certificats d'autorité ; sur une feuille, elle reste facultative. Le constat est rapporté en information, pour expliquer pourquoi les contrôles d'usage de clé n'ont pas été évalués.

Q : Que signifie le verdict « pas un certificat de marque » ?

R : Que l'objet collé n'appartient pas au profil VMC, et il y a deux chemins pour y arriver. Le premier : ni politique de marque ni extension logotype, autrement dit le certificat TLS du site web, collé à la place du VMC. Le second : basicConstraints déclare cA=TRUE, c'est donc une autorité de certification, souvent l'intermédiaire livré dans le même fichier PEM. Dans ce cas, la feuille est le premier bloc du fichier.

Q : À quoi sert le champ domaine attendu ?

R : À vérifier que le domaine qui publie votre enregistrement BIMI figure parmi les domaines certifiés du certificat. Le champ est facultatif et pilote exactement deux des 44 constats : couvert, ou en écart. Attention au wildcard, qui ne descend que d'un seul niveau au sens de la RFC 9525 §6.3 : *.exemple.fr couvre mail.exemple.fr, mais ni exemple.fr, ni a.b.exemple.fr.

Q : Combien coûte un certificat VMC, et pour quelle durée ?

R : De l'ordre de 1000 à 1500 dollars par an chez DigiCert, Entrust ou GlobalSign, prix qui couvre la vérification de la marque déposée auprès d'un office reconnu. La validité usuelle est d'un an. Prévoyez le renouvellement en avance : l'analyseur signale les 30 derniers jours en avertissement et les 60 derniers en information, et un certificat expiré fait disparaître le logo sans autre préavis.

Outils complémentaires

Ressources utiles

• RFC 3709 - extension logotype des certificats (structure logotypeHash, empreinte déclarée du logo)
• RFC 6170 - image dans un certificat X.509 (SVG Tiny compressé, transporté en URI data:)
• RFC 5280 - profil des certificats X.509 (validité, basicConstraints, keyUsage, SAN)
• RFC 9525 - vérification d'identité de service (portée du wildcard dans un SAN)
• BIMI Group - certificats de marque vérifiée (profil VMC, autorités accréditées)
• Spécification BIMI (tags a= et l=, prérequis DMARC)