Your Certificate's Country and State Fields Might Not Agree. CAs Have Revoked Certs For This.
A certificate's subject can carry a country code and a state/province that don't actually agree - a real subdivision, just of the wrong country, or a country code that isn't valid ISO 3166-1 at all. GlobalSign and Sectigo have both been forced into corrective action over exactly this. TLS Radar's scanner now checks for it automatically, on the free scan and the full scan, and explains this page's full FAQ, key facts, and how to check your own certificate.
A certificate's subject carries a country code and, often, a state or province. Nobody double-checks that these two fields actually agree with each other - not the person who filled out the CSR, not the CA's automated issuance pipeline in most cases, and not the browser, which doesn't look at these fields at all once the cert chains to a trusted root. The result: certificates go out into the world with a state that belongs to a different country than the one printed right next to it, or a country code that isn't a real country code at all.
This isn't hypothetical. CAs have revoked certificates for exactly this. TLS Radar's scanner now checks for it automatically, on every scan - free or full.
Two real incidents, not a theoretical risk
In 2021, Mozilla's CA compliance process caught GlobalSign issuing certificates with an invalid countryName - not a real ISO 3166-1 code. GlobalSign had to stop issuance for the affected certificate types and fix the validation gap (Bugzilla 1707073).
Separately, Sectigo spent months working through a backlog of certificates with unvalidated stateOrProvinceName values - nearly 15,000 distinct strings reviewed, EV certificates corrected first, then OV. The root cause: the state field was never checked against the actual ISO 3166-2 subdivision list for the certificate's own country (Bugzilla 1645686). Sectigo's fix afterward was to build a lookup table - which is, functionally, the same check we just shipped.
Two different CAs, two different years, the same underlying gap: nothing in the issuance pipeline validated that the subject's geographic fields were internally consistent. If it happened to GlobalSign and Sectigo, both large, well-audited CAs, it can happen to whoever issued your certificate too.
What the check actually does
Three specific things, run against both the certificate's normal subject fields and, for EV certificates, the separate jurisdiction fields:
- Invalid country code. The certificate's
countryNameisn't a real ISO 3166-1 alpha-2 code. This is a direct CA/Browser Forum Baseline Requirements 7.1.4.2 violation - the exact category GlobalSign got caught on. - State in the wrong country. The
stateOrProvinceNameis a real subdivision - just not of the country printed in the same certificate. The classic case: a state name that belongs to Canada, on a certificate whose country code says GB. This is the exact failure mode behind the Sectigo incident. - Unrecognized state. The state value doesn't match any known subdivision anywhere. Lower confidence than the first two - it might be a misspelling, an informal name, or a gap in reference data rather than a genuine mismatch - so this one is flagged as informational rather than a warning.
The first two are treated as warnings and can move your certificate's grade. Both have a documented history of CAs revoking certificates over them - we're not guessing at severity, we're following the actual enforcement record.
What it deliberately doesn't check
We don't validate localityName (city) against a gazetteer. Turns out this is a much harder problem to do without generating false positives than it looks: Florence exists in Italy and in South Carolina. Paris exists in France and in Texas. Matching city names against a reference list produces a stream of "mismatches" that aren't actually mismatches, which teaches everyone to ignore the warning. Country and state/province are the levels where ISO 3166 gives us an authoritative, unambiguous answer. City doesn't, so we leave it alone rather than ship a check that's wrong more often than it's right.
We also don't flag every country as invalid just because our reference data has a gap. Two placeholder/edge cases are explicitly tolerated: XX (the Baseline Requirements' own placeholder for a country with no assigned code) and XK (Kosovo - not in ISO 3166-1, but common enough in real certificates from EU institutions that flagging it would just be noise). And if the reference dataset itself is ever missing or corrupted, the check disables itself rather than flagging every certificate as broken - fail safe, not fail loud.
Check your own certificate
This runs automatically on every scan, including the free one - no account required. If your certificate's subject has a geographic inconsistency, it'll show up in the results with a plain-language explanation of exactly what doesn't match and why.
Check your certificate's subject fields
See whether your certificate's country and state/province fields are internally consistent - along with everything else our scanner checks: EKU compliance, chain validity, cipher strength, and revocation status. Free, no account required.
Catch this before your CA does
TLS Radar checks every certificate in your inventory for subject geo-consistency, EKU policy compliance, chain health, and revocation status, continuously - not just at issuance time. If a renewal ever introduces a mismatch, you'll know before it becomes a CA compliance incident with your name on it.
Related reading
Frequently asked questions
- What is a certificate subject geo-consistency check?
- It verifies that a certificate's geographic subject fields agree with each other: that the countryName is a valid ISO 3166-1 code, and that the stateOrProvinceName (if present) is an actual subdivision of that same country - not a real place name that happens to belong to a different country.
- Has this actually caused certificates to be revoked?
- Yes. GlobalSign had to halt issuance and fix its validation pipeline after issuing certificates with an invalid countryName (Mozilla Bugzilla 1707073). Sectigo reviewed roughly 15,000 stateOrProvinceName values and revoked certificates found to be inconsistent, after discovering the field had never been validated against ISO 3166-2 (Mozilla Bugzilla 1645686).
- Does this check also cover EV certificates?
- Yes - EV certificates carry a separate pair of jurisdiction fields (jurisdictionCountryName and jurisdictionStateOrProvinceName), and the same consistency check runs against those in addition to the normal subject fields.
- Why doesn't the check validate the city (localityName) field?
- City names are not unique to one country - Florence exists in Italy and in South Carolina, Paris exists in France and in Texas - so matching against a reference list would flag many correct certificates as inconsistent. Country and state/province are the levels where ISO 3166 gives an unambiguous answer; city does not, so it's left out rather than shipping a check that's wrong more often than it's right.
- Is this check available on the free scanner?
- Yes. It runs automatically on every scan - the free, no-account-required scan and the full scan - with no separate setup required.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.