4 ms·
The same company also cheats on issuance date to support SHA1 signatures. I heard it on HN on another topic. Edit: source https://groups.google.com/forum/#!top
by buraktamturk 10y ago
The same company also cheats on issuance date to support SHA1 signatures. I heard it on HN on another topic.
Edit: source https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/k9PBmyLCi8I https://groups.google.com/forum/#!topic/mozilla.dev.security...
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.
- tobias3 10y agoThis is also not very encouraging: > R: Sorry, I don't say it clear, please forgive my bad English since my native language is Chinese. As I said this is my fault that we don't understand the Mozilla policy clearly that we don't think we need to report. But now we are clear that all mis-issued certificate case and any reported bug related system change also need to report. I and every related employee all clear now, then we can guarantee we will do it well in the future. Why we log all SSL certificate from July 5th is for full transparency to let all related parties can report to us in the first time after the certificate is issued. Maybe employ someone with enough English knowledge to read and understand https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ https://www.mozilla.org/en-US/about/governance/policies/secu... ?
- 0x0 10y agoAmateur hour. You'd think understanding the rules of the game would be a prerequisite to be a warden of the entire TLS ecosystem, as any unrestricted CA is. It's not comforting that the entire security of https globally is now in the hands of someone unable to read the CA requirements, and doesn't even seem to worry about that fact.