Why analyze a brand certificate
A brand certificate costs 1000 to 1500 dollars a year. Receiving one proves nothing about how it behaves.
Between the file your authority issues and the logo that shows up in an inbox sit a DNS record, an https address, a DMARC policy and a sending domain that has to appear inside the certificate. When the logo stays missing, the cause hides somewhere along that chain, and ordinary decoders settle for printing a subject and two dates.
This analyzer decodes the certificate, then tests every measured fact against the VMC profile, against RFC 3709 for the logotype and against RFC 5280 for the rest. It returns a four-state verdict and the findings behind it, each with its source. The catalog holds 44 codes; how many findings come back depends on the certificate submitted.
When it earns its place:
- When the certificate arrives, before publishing anything in DNS.
- When the logo stays invisible despite a setup that looks correct.
- Before a renewal, to compare the old and the new file on covered domains.
What the analyzer checks
Seven families of checks, 44 codes, three severities. The table lists the question each family settles.
| Family | What it settles |
|---|---|
| Certificate nature | Brand certificate, certificate authority, or something else entirely |
| Logotype extension | Is there a mark, and is the embedded image the one that was verified |
| Validity window | Expired, not yet valid, deadline approaching, lifetime outside the profile |
| Chain and issuer | Self-signed, incomplete chain, anchoring to an authority the system knows |
| Key, usages, signature | Key size, curve, signature algorithm, key usage bits |
| Subject and identity | Organization, jurisdiction, registration number, certified domains |
| Input | Number of blocks supplied, truncation beyond the service limit |
VMC or CMC, the report names the profile. The BIMI program issues two kinds of brand certificate: the VMC, backed by a registered trademark, and the CMC, issued on evidence of prior use of the logo. No policy identifier separates them, and that is measured on 37 real certificates: two certificates of different profiles, issued by the same authority, declare exactly the same policies. The analyzer therefore reads the markType subject attribute, the one the program defines for this purpose, and the report tells you which of the two you are holding. A CMC remains a legitimate profile: the finding is reported as information, it does not degrade the verdict, and it only serves as a reminder that mailbox provider support is narrower.
Severity calibration follows one rule: mark a finding as blocking only when the certificate is demonstrably at fault. A badly encoded extension our decoder failed to read remains a warning, because the doubt is on our side. That discipline has a cost, and it buys something too: when the verdict comes back non-compliant, it carries weight and the reader can believe it.
The embedded logo check
This is the check that separates the tool from a decoder. It answers a question no other page asks: is the image this certificate carries the one the authority approved?
The mechanism comes from RFC 3709 §4.1. The logotype extension 1.3.6.1.5.5.7.1.12 carries, for each image, a pair of hash algorithm and digest. RFC 6170 fills in the rest: the image is an SVG Tiny, gzip-compressed, encoded in a data: URI. The analyzer extracts that image, decompresses it, rehashes it under the algorithm the certificate itself names, and compares.
Three outcomes, three messages. Digests match, the nominal case, reported as information because it is the proof you came for. Digests differ, a blocking finding: the file changed after the authority verified it, and this certificate must not be published. No embedded image at all, a warning: the logo is referenced by URI only, integrity can no longer be checked offline, and display depends on a third-party server.
Decoding now avoids several traps that used to produce false mismatches. Only subjectLogo, the direct branch, is read: the authority logo and any community logos carry other digests and have no business in the comparison. Only the first image in the sequence is kept, otherwise the digest of the second one would end up matched against the first.
On a confirmed mismatch, the action is not up for debate: go back to the SVG you supplied to the authority when ordering, or ask for a reissuance. Republishing a retouched image after issuance breaks the link, and our BIMI logo guide sets out the format constraints you have to meet.
Two false defects, measured on real certificates
An analyzer that asks you to fix what DigiCert and GlobalSign issue has stopped analyzing anything. Two findings were recalibrated after measurement on six real certificates, at the three authorities in the program.
The logo digest in SHA-1 only. Four certificates out of six declare that algorithm alone, all issued by DigiCert. The job of that digest is to pair an image with a certificate; the verifier already holds the image and recomputes the value itself, which gives an adversary nothing to work with. Classifying this case as a warning would produce a mass false positive on the main authority of the program. The analyzer reports it as information.
The missing keyUsage extension. Five certificates out of six carry none, at two authorities out of three, and they show their logo in production. RFC 5280 §4.2.1.3 requires keyUsage only on certificates whose key validates signatures on other certificates, meaning authorities. On a leaf it is optional. The finding still appears, as information, because it explains why key usage checks were not evaluated.
Those two lines matter above all as a reading guide for the report. A finding reported as information calls for no action: it simply documents. Do not order a 1200-dollar reissuance over a reported fact.
The four verdicts, and what they call for
Four possible verdicts, one returned per analysis, each with the action it calls for.
| Verdict | What it means | What you do |
|---|---|---|
| Compliant | No blocking finding, no warning | Publish, then check the BIMI record and DMARC |
| Warning | Nothing blocks the logo, some points deserve a look | Read the warnings, decide, publish |
| Non-compliant | At least one blocking defect | Fix or request a reissuance before publishing |
| Not a brand certificate | The analyzed object falls outside the VMC profile | Go back to the right file, or the right block of the file |
The fourth state exists because the case is common, and writing "your brand certificate is non-compliant" about an object that is not one would be false. Two cases lead there. No brand policy and no logotype extension: this is the TLS certificate of the website, pasted by mistake, and the presence of the serverAuth usage confirms it. Or basicConstraints declares cA=TRUE, and the object is a certificate authority, almost always the intermediate included in the same PEM file as the leaf.
That second case used to produce a report that was wrong from end to end. The intermediate collected complaints written for a leaf, notably a keyCertSign usage judged excessive when an authority is meant to carry it, and a line asserting it was a Verified Mark Certificate. It is now recognized and named, with no further judgment.
The expected domain, an optional field
This field drives exactly two of the 44 findings. Left empty, it costs you those two, and nothing else.
Enter the domain that publishes your BIMI record. The analyzer then looks for a dNSName entry in the certificate that covers it, and returns either covered or a blocking mismatch. The usual trap is the wildcard: under RFC 9525 §6.3 it descends one level only. *.captaindns.com covers mail.captaindns.com, but neither captaindns.com nor a.b.captaindns.com.
A mismatch here is not fixed by a DNS change. The certificate does not cover that domain, so it has to be reissued. Better to think it through at order time, transactional subdomains included.
What this analyzer does not say
Three limits, stated because a tool that hides them lets people believe in guarantees it never provides.
Revocation is not checked. No OCSP query, no revocation list. A certificate revoked by its authority will come back compliant if its content is.
The issuing organization is not judged. No list of approved authorities is hardcoded, and that is deliberate: such a list would become wrong the day the BIMI Group accredits a new issuer, and it would become wrong silently. Judgment rests on the declared certificate policy and on chain anchoring, not on a name.
The chain is not traced back to a brand root. The program roots, measured over the corpus, are absent from both locally verifiable stores: the Apple system store, 127 roots, and the Mozilla bundle shipped with curl, 190 roots. They form a store specific to the program, carried by no operating system and no container image. Consequence applied in the tool: a verification failure never becomes a blocking finding, since it proves nothing. A chain that verifies remains good news; a chain that does not verify says nothing about the certificate.
Publishing the certificate once validated
The verdict does not make the logo appear. Four things have to hold together.
DMARC first: the sending domain has to sit at p=quarantine or p=reject, otherwise no mailbox provider will look at the rest. Then the PEM file, served over https at a stable address, the one carried by the a= tag of your _bimi record. Then the SVG logo, served the same way, referenced by the l= tag. And finally the sending domain, present among the certified domains.
Always serve the complete file, leaf followed by intermediates, exactly as the authority issued it. A certificate served alone triggers an incomplete chain warning, and some verifiers stop right there.
On the calendar front, a brand certificate lasts one year. The analyzer switches to a warning over the last 30 days and flags the deadline from the last 60, but a one-off report is no substitute for monitoring. Note the date, and read our guide on VMC and CMC certificates to choose between the two profiles at renewal time. If the logo stays missing after publication, five common causes cover most cases.
Privacy
Two paths, two behaviors, and the tool tells you which one applies before you click.
A certificate pasted in PEM form is analyzed offline: decoding in memory, no outbound connection, no file kept. An https address, on the other hand, is fetched by our servers in a single bounded request, as the note under the button states in real time. A certificate is not a secret anyway: it carries a public key and identifiers meant to be published.
The expected domain field is used for the coverage check and nothing else. Beyond ten CERTIFICATE blocks in one submission, the surplus is ignored and the report says so.
FAQ - Frequently asked questions
Q: What is a VMC certificate?
A: A Verified Mark Certificate is an X.509 certificate that ties a logo to an organization whose trademark rights have been verified. It embeds the image in a logotype extension (RFC 3709) and declares a certificate policy specific to the program. Gmail, Yahoo Mail and Apple Mail rely on it to show your logo, provided DMARC sits at p=quarantine or p=reject. DigiCert, Entrust and GlobalSign issue them, among other authorities accredited by the BIMI Group.
Q: Why is my logo missing even though the certificate is valid?
A: The certificate is only one link. Check in order: DMARC at p=quarantine or p=reject on the sending domain, the _bimi record published, the a= tag pointing to an https address that serves the PEM, and the sending domain present among the certified domains. That last point is what the expected domain field settles here. Mailbox provider caches then add a delay of several hours.
Q: Does the analyzer verify that the embedded logo is the one the authority approved?
A: Yes, and that is the check that sets this tool apart. The SVG image is extracted from the logotype extension, decompressed, then rehashed under the algorithm the certificate itself names. If the recomputed digest differs from the declared one, the finding is blocking: the file moved after the authority verified it. Before the tool was rebuilt, that comparison worked on no real certificate.
Q: My certificate declares the logo digest in SHA-1, is that a defect?
A: No. Across six real certificates measured at three authorities, four declare their logo digest in SHA-1 only: that is what DigiCert issues. The job of that digest is to pair an image with a certificate, not to stand as a collision barrier, since the verifier already holds the image and recomputes the value. The analyzer reports it as a fact, without downgrading the verdict.
Q: The keyUsage extension is missing from my VMC, should I ask for a reissuance?
A: No. The extension is missing on five of the six certificates measured, at two of the three authorities in the program, and those certificates show their logo in production. RFC 5280 §4.2.1.3 requires keyUsage only on certificate authorities; on a leaf it remains optional. The finding is reported as information, to explain why key usage checks were not evaluated.
Q: What does the verdict not a brand certificate mean?
A: That the object you pasted falls outside the VMC profile, and there are two ways to get there. First: no brand policy and no logotype extension, in other words the TLS certificate of the website, pasted instead of the VMC. Second: basicConstraints declares cA=TRUE, so this is a certificate authority, often the intermediate included in the same PEM file. In that case the leaf is the first block of the file.
Q: What is the expected domain field for?
A: It confirms that the domain publishing your BIMI record sits among the certified domains of the certificate. The field is optional and drives exactly two of the 44 findings: covered, or mismatched. Watch out for the wildcard, which descends one level only under RFC 9525 §6.3: *.captaindns.com covers mail.captaindns.com, but neither captaindns.com nor a.b.captaindns.com.
Q: How much does a VMC certificate cost, and for how long?
A: Around 1000 to 1500 dollars a year from DigiCert, Entrust or GlobalSign, a price that covers verification of the registered trademark with a recognized trademark office. The usual validity is one year. Plan the renewal early: the analyzer raises a warning over the last 30 days and reports the deadline from the last 60, and an expired certificate makes the logo vanish with no further notice.
Complementary tools
| Tool | Purpose |
|---|---|
| BIMI Checker | Check the published record, a= and l= tags included |
| BIMI Generator | Compose the record once the certificate is validated |
| DMARC Inspector | Confirm the p=quarantine or p=reject prerequisite |
| BIMI Hosting | Serve the logo and the certificate at a stable https address |
| BIMI SVG Converter | Produce an SVG Tiny that matches the expected profile |
| SSL Certificate Checker | Judge the TLS certificate of the site, the other profile in the family |
| CSR Parser | Check a certificate request before submitting it |
Useful resources
- RFC 3709 - certificate logotype extension (
logotypeHashstructure, declared logo digest) - RFC 6170 - image in an X.509 certificate (compressed SVG Tiny, carried in a
data:URI) - RFC 5280 - X.509 certificate profile (validity,
basicConstraints,keyUsage, SAN) - RFC 9525 - service identity verification (scope of the wildcard in a SAN)
- BIMI Group - verified mark certificates (VMC profile, accredited authorities)
- BIMI specification (
a=andl=tags, DMARC prerequisites)