CT Sanctions Watch

[Wayne]

Given the issues CAs have had on checking sanctioned entities against domains I've put together an automatically updating list of unrevoked, unexpired certificates.

Site: https://sec-wayne.github.io/ct-sanctions-watch/
CSV: https://sec-wayne.github.io/ct-sanctions-watch/sanctions.csv
JSON: https://sec-wayne.github.io/ct-sanctions-watch/sanctions.json
Commit history: https://github.com/Sec-Wayne/ct-sanctions-watch/commits/main/

I've already been in contact with most of the CAs mentioned to give them a more up to date blocklist. The sources are cited on the page, and certificates are only included if it's under that CA's legal jurisdiction. This will be an undercount, but will be replacing the regular emails CAs have received before.

I'll try to keep this up to date going forward. Ideally the CAs will update their blocklists overall and make this a moot project.

Revocations are checked regularly, and expired certificates are also removed. There'll be a small lag on inclusion as revocation checks are performed first. This is to cover the case of a post-issuance checks on the CA's side finding the side and immediately revoking.

This will be covering any CA chaining to Mozilla, Chrome, Apple, or Microsoft via CCADB checks.

Any questions you know how to contact me.

- Wayne

[Max]

Wayne - can you tell us why you think this is needed?

It seems as though you think 'domain appears on a list' is a same as 'cannot issue a certificate' - can you provide you legal background and explain?

Some of us rely on these free CAs, and are not ""violating"" sanctions.

You are not helping, though you think you are.

Please stop.

[Wayne]

If you believe an entity, domain, or certificate is mislabeled then I'm happy to investigate. Otherwise these are all tools that every CA has in their usage, I'm just making sure we're all using up to date lists and applying them equally.

Every source has been provided, it should help you if you disagree with my assessment.

[Arabella Barks]

I also strongly oppose the define of "sanction".

Every region, political regime or coalition defines what is "legal" differently.



For example, someone undemocratic government designate human rights organizations as illegal. Should we consider banning all CAs worldwide from issuing SSL certificates for these organizations to comply with the wishes of such government?

[K. York]

The website is quite clear that only sanctions regimes covering the CA's legal entity are being checked for -- US CAs use the US list, EU CAs use the EU list, etc.

~Kane

Sent with Shortwave

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/69ad6b3e-4dab-466a-987c-f277b59fa475n%40mozilla.org.

[Mike Shaver]

Yes, this is about policy violations that happen to be sanction-related: the CAs say they don’t issue to sanctioned-by-whoever entities, and these are cases where a CA has—perhaps inadvertently—issued to a sanctioned entity.

You can think of it the same way as if this were “vowel watch” for CAs that said “we will never issue to entities with names that contain vowels” but have nonetheless done so. The tool is a way to help the relevant CAs in avoiding or revoking issuance that is counter to their published policies.

Mike

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b77de32f-041f-4243-a324-c5729500c855%40mail.shortwave.com.

[Watson Ladd]

On Tue, Oct 6, 2026 at 12:33 PM Mike Shaver <mike....@gmail.com> wrote:
>
> Yes, this is about policy violations that happen to be sanction-related: the CAs say they don’t issue to sanctioned-by-whoever entities, and these are cases where a CA has—perhaps inadvertently—issued to a sanctioned entity.
>
> You can think of it the same way as if this were “vowel watch” for CAs that said “we will never issue to entities with names that contain vowels” but have nonetheless done so. The tool is a way to help the relevant CAs in avoiding or revoking issuance that is counter to their published policies.

Does that include maters lectionis? Unicode/linguistics jokes/special
cases aside, issuance to an entity whose SAN contains a vowel when
they say they won't is a fairly easily determinable fact. Issuance to
a "sanctioned" entity is a much more complicated issue, with potential
licenses, disputes over the scope of sanctions, similarly named
entities, etc. I think avoiding putting these these statements in CPS
etc. is the way to go.

Sincerely,
Watson

> To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqtqh7Lot_RGLWvxk-GWp5jR16uJdhE7UATKV76c4GUn4A%40mail.gmail.com.



--
Astra mortemque praestare gradatim

[Jeffrey Walton]

Hi Wayne,

This is not directed at you. Rather, you happened to make the post.

I would advise caution here. Sanctions are a blunt instrument, and
they rarely have an effect on the intended targets. Consider, the US
has had an economic embargo and sanctions against Cuba for 64 years.
Yet it has had little effect on the country's leadership. Instead, it
punishes peasants who have no control over matters.

A working man or woman in Russia does not eat at Putin's table.
There's no sense in trying to punish the masses. The same holds for
other regimes, like Cuba, Iran, North Korea and Syria. The working
men and women have suffered enough. Leave them alone.

Now if the US sanctions and CA's chose to target certain individuals
and institutions in government, that would be a different story. But
that's not happening here.

Another argument is that politics have no place in science and
technology. I don't think that needs to be argued here.

Jeff

[Mike Shaver]

On Wed, Oct 7, 2026 at 9:16 PM Watson Ladd <watso...@gmail.com> wrote:

Issuance to
a "sanctioned" entity is a much more complicated issue, with potential
licenses, disputes over the scope of sanctions, similarly named
entities, etc. I think avoiding putting these these statements in CPS
etc. is the way to go.

Yeah, I would agree. I think it was a mistake to put sanctions-related statements in CPS and friends without anticipating those challenges, tbqh, and would recommend removing them or at least wording them more carefully to clarify such elements. Wayne's tool can assist CAs who have chosen to put that language in their policies in conforming to them, until such changes are made.

Mike

[Wayne]

I agree this is a weedy and complex situation. Part of the reason for this existing is the lack of due diligence on CAs in cleaning up how they approach this.

As Kane noted this is only strictly applied where the legal jurisdiction of the CA overlaps. That's an intentional undercount, and even ignores certain CAs who include other legal jurisdictions explicitly in their CPS - for sanctions at that. What is also an undercount is how far back the data goes - this is primarily forward-facing. I tried to design this to be as strict as possible on obligations, and not have any per-CA overrides or extra entities added.

As far as exposure goes, the headache I see isn't for the entities such as Let's Encrypt who publish free certificates. It's the CAs who have directly or indirectly taken money for these services, which is a legal nightmare to be in. So much of this is self-inflicted, and why I have been very precise in where the data all comes from, how it is sourced and collated. There are some upstream issues of bad punycode, typos, etc. Those entries aren't included or corrected, and no reports are sent upstream either.

I don't expect any quick changes here, but this lets everyone see the current situation. The one thing I definitely have not done is any type of automated Certificate Problem Report on any of this - now that would be a terrible idea.The CSV, JSON and Github commit history should be enough for a CA to get an idea of what other people can see.

- Wayne