1319609 - Let's Encrypt: certs issued contrary to CPS due to incomplete blocklist

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

Posted in the mozilla.dev.security.policy forum today:

Between 11:30am and 4pm Pacific on November 21, 2016, a problem with the Let’s Encrypt issuance blocklist was identified, confirmed, and fixed.

The issue was initially identified by a Let’s Encrypt operations engineer during routine maintenance. A script is used to assemble a final blocklist configuration from a set of input files. The engineer was adding a suffix to the blocklist and noticed that it wasn’t being propagated to the final blocklist configuration. Further investigation confirmed a bug in the script - it incorrectly and silently failed to process a small number of blocklist entries based on a formatting characteristic. The bug has been fixed and we are reviewing policy around the code in question. Testing for the code will be improved.

While a fix was being developed, Let’s Encrypt staff worked to identify all blocks that had failed to propagate as well as any certificates that were issued for those domains. The following certificates were found to have been mis-issued by policy, though there is no sign that they were used maliciously and domain control was properly demonstrated via DV validation.

gov.ir
https://crt.sh/?id=49145557 (Revoked)
https://crt.sh/?id=17321835 (Expired)
https://crt.sh/?id=17320010 (Expired)

gov.sy
https://crt.sh/?id=24753847 (Expired)

mil
https://crt.sh/?id=31920262 (Revoked)
https://crt.sh/?id=29886368 (Revoked)
https://crt.sh/?id=52210328 (Revoked)
https://crt.sh/?id=51226007 (Revoked)
https://crt.sh/?id=48632604 (Revoked)
https://crt.sh/?id=47382849 (Revoked)
https://crt.sh/?id=47464047 (Revoked)
https://crt.sh/?id=43269410 (Revoked)
https://crt.sh/?id=43268871 (Revoked)
https://crt.sh/?id=40478677 (Revoked)
https://crt.sh/?id=36321880 (Revoked)
https://crt.sh/?id=30291839 (Revoked)
https://crt.sh/?id=25207594 (Expired)

Issuance to gov.ir and gov.sy is not allowed as these entities are sanctioned by the U.S. government and we are a U.S.-based organization. Issuance to .mil is not allowed due to contractual obligations that are reflected in our Certification Practice Statement.

All unexpired certificates have been revoked. Account contacts were notified.

Comment 1

[Gervase Markham [:gerv]]

(In reply to Kathleen Wilson from comment #0)
> Issuance to gov.ir and gov.sy is not allowed as these entities are
> sanctioned by the U.S. government and we are a U.S.-based organization.

Is your unwillingness to issue to such domains reflected in your CP/CPS, or not?

If it is not, then I think this particular part of the incident is not a concern to Mozilla.

> Issuance to .mil is not allowed due to contractual obligations that are
> reflected in our Certification Practice Statement.

This is, as you note, a misissuance by policy and not a misissuance due to lack of authorization by the domain owner. The concern for Mozilla is lack of compliance with CP and CPS. 

At one time, AIUI, your unwillingness to issue for .mil was encoded as name constraints in your intermediate certificates, but this was removed due to incompatibility issues. I think that the existence of previous attempts to use additional technical controls for this ban count in LE's favour.

Mozilla policy requires that certificates issued in contravention of a CA's CP/CPS should be revoked, which you have done. Other than that, Mozilla policy does not directly require (somewhat to my surprise) that a CA operate in accordance with its CP and CPS. We require this indirectly because the audits that we require, require it.

I will start a discussion in m.d.s.policy as to whether this should be remedied. But in the mean time, my current view is that no further action from Mozilla is necessary.

Gerv

Comment 2

[Josh Aas]

(In reply to Gervase Markham [:gerv] from comment #1)
> (In reply to Kathleen Wilson from comment #0)
> > Issuance to gov.ir and gov.sy is not allowed as these entities are
> > sanctioned by the U.S. government and we are a U.S.-based organization.
> 
> Is your unwillingness to issue to such domains reflected in your CP/CPS, or
> not?

Possibly indirectly in Section 9.15, which states "This CPS is subject to all applicable laws and regulations, including United States restrictions on the export of software and cryptography products."

We call out .mil directly in the CPS as something we're not supposed to issue for, but we do not call out the other domains directly. Some of the other things we block are blocked based on internal risk assessments, others are blocked based on internal legal assessments.

Comment 3

[Josh Aas]

The code/script which contained the bug that caused this issue has been entirely deleted and is not use by Let's Encrypt any more (this was done months ago). The blacklist is now a static text document with no processing.

Any update on progress towards closing this issue?

Comment 4

[Gervase Markham [:gerv]]

I think this issue has been dealt with to our satisfaction. :-)

Gerv