Hongkong Post e-Cert CA 1 - 10 has been issuing certificates that do not have a subject alternative name extension: https://crt.sh/?id=11595941&opt=cablint https://crt.sh/?id=13739733&opt=cablint https://crt.sh/?id=15319991&opt=cablint (The most recently issued one is from December 2015, so they might have fixed this since then, but we should double-check.) (They also don't have an OCSP URI.)
Man, Please look into the issues listed in this bug, and add comments to this bug to keep us informed of status and progress.
Assignee: nobody → manho
"Hongkong Post e-Cert CA 1 - 10" is an old SHA-1 subCA which had been stopped issuing SSL certificates since 1 January 2016. We took two stages of transitioning to a new BR-compliant subCA "Hongkong Post e-Cert CA 1 - 15" for issuing BR-compliant SSL certificates: Stage 1: Start issuing SHA-256 SSL certificates from "Hongkong Post e-Cert CA 1 - 14" since 1 January 2015. This subCA has also fixed a couple of issues as reported in cablint (e.g. the SAN extension), except the OCSP URI and the organization name. At that moment, we had announced to stop issuing SHA-1 SSL certificates which are issued by "Hongkong Post e-Cert CA 1 - 10" from 1 January 2016 (http://www.hongkongpost.gov.hk/news/press/73.html). Stage 2: Start issuing SSL certificate supporting OCSP from "Hongkong Post e-Cert CA 1 - 15" from 1 September 2015. This subCA is used to issue BR-compliant SSL certificates. And we have also announced to stop issuing non-OCSP SSL certificates from "Hongkong Post e-Cert CA 1 - 14" from 1 September 2016 (http://www.hongkongpost.gov.hk/news/press/76.html). As a result, all our subscribers will eventually migrate to our BR-compliant SSL certificates.
This was issued from "Hongkong Post e-Cert CA 1 - 10" in July, so there still appears to be an issue here: https://crt.sh/?id=27249059&opt=cablint (note that it was signed with sha-1 and that the "Netscape Cert Type" extension is ignored, so this certificate could be used as a TLS web server certificate, although it isn't valid for any DNS names).
status-firefox48: affected → ---
Component: CA Certificates → CA Certificates
Product: NSS → mozilla.org
Version: trunk → other
This certificate is issued to a person, instead of a server, as you've seen that it does not contain any DNS name. "Hongkong Post e-Cert CA 1 - 10" will continue issue client certificates to individuals, although it has been stopped issuing SSL server certificates since 1 January 2016. By the way, I'm wondering how could you scan and log this certificate in your database? What is the mechanism and the scope of your scanning? I ask these questions because (1) this client certificate shouldn't be able to be installed or in use of any server; and (2) this client certificate contain personal information that I strongly believe shouldn't be publicized due to concern of privacy.
It would be best if these certificates used the standardized extended key usage extension to limit their uses rather than the non-standard netscape cert type extension. I found these certificates by looking through public certificate transparency logs (the certificate in question is in Google's pilot, aviator, and rocketeer logs). I'm not sure if there's a way to know who actually submitted the certificate to the logs. The publicly-known certificates issued by Hongkong Post e-Cert CA 1 - 10 can be found here: https://crt.sh/?Identity=%25&iCAID=230 The real problem here is that the issuing certificate is using sha-1 with predictable serial numbers. The most recently issued publicly known certificates from this CA are, in reverse-chronological order: 0x31a587 0x314e35 0x314941 0x314174 0x313d64 0x313472 0x312de8 These values appear to be either time-related or from some increasing counter value. If a chosen-prefix attack on sha-1 were discovered (which we can probably expect soon, given recent attacks against sha-1), an attacker could use this CA to obtain a certificate for a domain that isn't theirs.
Man Ho, This is in direct violation of the CA/Browser Forum's Baseline requirements, which say: "7.1.3. ... Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA‐1 hash algorithm..." I am thinking we should add this intermediate certificate to OneCRL. Are there SHA-1 certificates being issued from any of the other Hongkong Post's intermediate certificates?
Started discussion about this in mozilla.dev.security.policy: https://groups.google.com/d/msg/mozilla.dev.security.policy/Ng99HcqhZtI/vzmPoGX8BwAJ
I filed Bug #1299579 to add the "Hongkong Post e-Cert CA 1 - 10" intermediate cert to OneCRL.
Depends on: 1299579
(In reply to Man Ho from comment #2) > Stage 1: Start issuing SHA-256 SSL certificates from "Hongkong Post e-Cert > CA 1 - 14" since 1 January 2015. This subCA has also fixed a couple of > issues as reported in cablint (e.g. the SAN extension), FWIW, the most three recent certs issued off this intermediate I found on crt.sh were: https://crt.sh/?id=16024471&opt=cablint https://crt.sh/?id=12114285&opt=cablint https://crt.sh/?id=25504647&opt=cablint They all lack a SAN extension, and were issued in 2016, with the most recent being April 2016. But, maybe the issue really has been fixed since then.
SSL certs issued from SubCA of Stage 1 is not yet BR-compliant. Please refer to Appendix B(4) e-Cert (Server) Certificate Format in our CPS at URL http://www.hongkongpost.gov.hk/product/cps/ecert/img/cps_en40.pdf for the types of SSL certs that contains a SAN extension. Anyway, Stage 1 was finished on 31 August 2016. In fact, this SubCA had not issued any SSL certs for a few months. Since 1 September 2016, we ONLY issue SSL certs from the SubCA of Stage 2, which are BR-compliant.
Closing this bug as resolved/fixed, because the 'Hongkong Post e-Cert CA 1 - 10' certificates were added to OneCRL via Bug #1299579.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.