For the thread's reference, here's the link for the misissued GitHub

Valid for 3 years, for It's not in OneCRL, CRLset, or
Microsoft's disallowedcert.stl.

On Wed, Aug 24, 2016 at 9:08 AM, Gervase Markham <> wrote:

> Dear m.d.s.policy,
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these
> incidents. This email sets out our understanding of the situation.
> Before we begin, we note that Section 1 of the Mozilla CA Certificate
> Enforcement Policy[0] says: "When a serious security concern is noticed,
> such as a major root compromise, it should be treated as a
> security-sensitive bug, and the Mozilla Policy for Handling Security
> Bugs should be followed." It is clear to us, and appears to be clear to
> other CAs based on their actions, that misissuances where domain control
> checks have failed fall into the category of "serious security concern".
> Incident 0
> ----------
> On or around April 23rd, 2015, WoSign's certificate issuance system for
> their free certificates allowed the applicant to choose any port for
> validation. Once validation had been completed, WoSign would
> issue certificates for that domain. A researcher was able to obtain a
> certificate for a university by opening a high-numbered port (>50,000)
> and getting WoSign to use that port for validation of control.
> This problem was reported to Google, and thence to WoSign and resolved.
> Mozilla only became aware of it recently.
> * Before the recent passage of Ballot 169 in the CAB Forum, which limits
> the ports and paths which can be used, the Baseline Requirements said
> that one acceptable method of domain validation was "Having the
> Applicant demonstrate practical control over the FQDN by making an
> agreed‐upon change to information found on an online Web page identified
> by a uniform resource identifier containing the FQDN". This method
> therefore did not violate the letter of the BRs. However, Mozilla
> considers the basic security knowledge that ports over 1024 are
> unprivileged should have led all CAs not to accept validations of domain
> control on such ports, even when not documented in the BRs.
> * The misissuance incident was not reported to Mozilla by WoSign as it
> should have been (see above).
> * This misissuance incident did not turn up on WoSign's subsequent BR
> audit[1].
> Incident 1
> ----------
> In June 2015, an applicant found a problem with WoSign's free
> certificate service, which allowed them to get a certificate for the
> base domain if they were able to prove control of a subdomain.
> The reporter proved the problem in two ways. They accidentally
> discovered it when trying to get a certificate for and
> mistakenly also applied for, which was approved. They then
> confirmed the problem by using their control of
> to get a cert for
>,, and
> They reported this to WoSign, giving only the Github certificate as an
> example. That cert was revoked and the vulnerability was fixed. However
> recently, they got in touch with Google to note that the cert
> still had not been revoked almost a year later.
> * The lack of revocation of the certificate (still unrevoked at
> time of writing, although it may have been by time of posting) strongly
> suggests that WoSign either did not or could not search their issuance
> databases for other occurrences of the same problem. Mozilla considers
> such a search a basic part of the response to disclosure of a
> vulnerability which causes misissuance, and expects CAs to keep records
> detailed enough to make it possible.
> * This misissuance incident was not reported to Mozilla by WoSign as it
> should have been (see above).
> * This misissuance incident did not turn up on WoSign's subsequent BR
> audit[1].
> Incident 2
> ----------
> In July 2016, it became clear that there was some problems with the
> StartEncrypt automatic issuance service recently deployed by the CA
> StartCom. As well as other problems it had, which are outside the scope
> of this discussion, changing a simple API parameter in the POST request
> on the submission page changed the root certificate to which the
> resulting certificate chained up. The value "2" made a certificate
> signed by "StartCom Class 1 DV Server CA", "1" selected "WoSign CA Free
> SSL Certificate G2" and "0" selected "CA 沃通根证书", another root
> certificate owned by WoSign and trusted by Firefox.
> Using the value "1" led to a certificate which had a notBefore date
> (usage start date) of 20th December 2015, and which was signed using the
> SHA-1 checksum algorithm.
> * The issuance of certificates using SHA-1 has been banned by the
> Baseline Requirements since January 1st, 2016. Browsers, including
> Firefox, planned to enforce this[2] by not trusting certs with a
> notBefore date after that date, but in the case of Firefox the fix had
> to be backed out due to web compatibility issues. However, we are
> considering how/when to reintroduce it, and CAs presumably know this.
> * The issuance of backdated certificates is not forbidden, but is listed
> in Mozilla's list of Problematic Practices[3]. It says "Minor tweaking
> for technical compatibility reasons is accepted, but backdating
> certificates in order to avoid some deadline or code-enforced
> restriction is not."
> * WoSign deny that their code backdated the certificates in order to
> avoid browser-based restrictions - they say "this date is the day we
> stop to use this code"[4]. If that is true, it is not clear to us how
> StartCom came to deploy WoSign code that WoSign itself had abandoned.
> * It seems clear from publicly available information that StartCom's
> issuance systems are linked to WoSign's issuance systems in some way.
> Nevertheless, it should not have been possible for an application for a
> cert from StartCom to produce a cert signed by WoSign.
> * This misissuance incident was not reported to Mozilla by WoSign as it
> should have been.
> Taking into account all these incidents and the actions of this CA,
> Mozilla is considering what action to take. Your input is welcomed.
> Gerv, Kathleen and Richard
> [0]
> security-group/certs/policy/enforcement/
> [1]
> [2]
> [3]
> Backdating_the_notBefore_date
> [4]
> _______________________________________________
> dev-security-policy mailing list

-- | @konklone <>
dev-security-policy mailing list

Reply via email to