Closed Bug 1369359 Opened 2 years ago Closed 2 years ago
Com: mis-issuance of certs with unvalidated domain names and bogus field values
Patryk Szczygłowski writes: I just noticed StartCom have issued today couple obviously fake certificates: https://crt.sh/?id=146437565 Subject: commonName = ov organizationName = test localityName = Beijing stateOrProvinceName = Beijing countryName = Beijing serialNumber = 123456 X509v3 Subject Alternative Name: DNS:www.test.cn https://crt.sh/?id=146484676 Subject: commonName = iv givenName = Jeremy surname = Liao localityName = Beijing stateOrProvinceName = Beijing countryName = CN X509v3 Subject Alternative Name: DNS:www.test.cn https://crt.sh/?id=146517428 Subject: commonName = ov organizationName = test localityName = Beijing stateOrProvinceName = Beijing countryName = Beijing serialNumber = 123456 X509v3 Subject Alternative Name: DNS:www.test.cn I am well aware these certificates will not be accepted in Firefox/NSS, but because of the fact their root certificate is still in NSS trust store, there might be some interest in the community regarding obvious policy violation. userwithuid adds: For completeness, same for EV: https://crt.sh/?cn=ev&icaid=46855
Hi all, Firstly I´d like to apologize for not having answering before and for posting an initial response that was not correct not accurate and not related what it´s being discussed right now. It was my fault for not having checked before with my team, which is in China and they are 6 hours ahead, but was my first reaction when saw test in the SAN. So, sorry for this. In fact, the "issue" was due for implementing the CT log. Recently one customer asked why we weren´t logging our certificates in the CT logs, which we were doing it but with some problems because of the great firewall. So, we were talking with Primekey and provided a solution to implement in our system. We did it yesterday and for checking it, we created those "fake" certificates for testing, which were revoked inmediately. Attached there´s a report in which we explain all that has happened. And also some screenshots. In this report also indicate what remeditation steps we´ve already done to avoid these issues happen again in the future. We´ve also realized that the CRL generation didn´t work as supposed because didn´t generate a new CRL when those certificates were revoked but in the next update. We are dealing with Primekey to know what has happened. The OCSP response instead was correct and showed the certificates as revoked. For some other comments/suggestions posted in this thread I´d like to say that: - this incident is not related to the "real" issuance system through our CMS system in which all domains are verified - these certs were issued and revoked inmediately as they were only for testing. I know it wasn´t a good decission - regarding my initial response for test URLs, those are going to be generated under our own website, like valid.startcomca.com, revoked.startcomca.com - and for those other certs in crt.sh, those are revoked but there are four that were not issued because the connection with the CT failed and for some reason are showed in the crt.sh. We´re contacting Primekey to know what has happened but it seems to be related with the Startcom log, which didn´t logged it because it failed and google logs, which did it, so maybe is a configuration issue. Best regards
Gerv: I believe that this may overlap with Bug 1386894 . If the StartCom/Certinomis certificates are added to OneCRL (and I believe that's appropriate based on the discussions), then this can be closed out. If you don't want to close this out, I defer to you as to what information should be collected.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.