May 2015 CA Communication

Question: ACTION #4: Workarounds were implemented to allow mozilla::pkix to handle the things listed here https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix. We plan to remove these workarounds soon, so that new certificates with these problems will fail. Please check your certificate issuance to ensure you are no longer issuing certificates with these problems. The purpose of this question is to identify interoperability problems that may arise when we make the planned code changes, so we will appreciate your diligence in investigating your certificate issuance practices and previously issued certificates before you respond to this question. Please select all of the issues in the list below that exist in currently-valid certificates that chain to your root certificates in Mozilla's program.

Owner/Response 1. Intermediate certificate has an EKU and will be used for SSL, but does not have the id-kp-serverAuth EKU. 2. Default values in a SEQUENCE explicitly encoded; e.g. end-entity certificates with basicConstraints extension explicitly encoded to the default value cA:false. 3. The pathLenConstraint field is included when the cA boolean is false. 4. OCSP responders include a responseExtensions consisting of an empty SEQUENCE. 5. OCSP responses for subscriber certificates have an expiration time greater than ten days. 6. Timezones in certificates not specified as "Z" (Zulu/GMT). 7. Delegated OCSP response signing certificate expires before the OCSP response expires. 8. RSA SSL/TLS end-entity certificates that have a KeyUsage extension does not include keyEncipherment in the KeyUsage extension. 9. dNSName/iPAddress is only in the subject CN, and not in the subjectAltName. 10. String types other than PrintableString and UTF8String in DirectoryString components of names. 11. Encoding used for name constraints is not the same as the encoding used for alternative names. 12. None of the above. ACTION #4 Text Input
Grand Total 4 12 4 2 3 1 1 3 9 11 1 39
A-Trust
AC Camerfirma, S.A. 5.- We not used nextupdate because we get certificate revokation information from a data base. Nevertheless we will change this parameter. 9.- At the moment we do not issue certificate with this problem, but we have issued 748 certificates with no SAN information. The last certificate issued expire in 4th/May/2018
Actalis None, as far as we know.
Amazon Trust Services We may issue certificates with RSA subject public keys without keyEncipherment in cases where the server is required to use Diffie-Hellman key exchange.
Asseco Data Systems S.A. (previously Unizeto Certum)
Atos
Autoridad de Certificacion Firmaprofesional 3. The pathLenConstraint field is included when the cA boolean is false: 186 certs. 9. dNSName/iPAddress is only in the subject CN, and not in the subjectAltName 156 certs.
Buypass
Certicámara There is no action required, because we don't issue SSL/TLS certificates that chain up to our root certificates in Mozilla's program. Also the certificates issued for digital signature does not have any of the mentioned workarounds because it not need it.
Certinomis / Docapost none
certSIGN We have issued 208 SSL certificates which have the selected issues, the last certificate will expire on 3rd June 2016. We plan to have fixed this issues by the end of June 2015.
China Financial Certification Authority (CFCA)
China Internet Network Information Center (CNNIC) We never issued cert in 1,8,9,10,11. Regarding 2 and 3, the cert CNNIC issued for End-endity, we have basicConstrains with Subject Type=End Entity Path Length Constraint=None. Regarding 4,5,6,7, we need confirm from our RD team and update to you later.
Chunghwa Telecom
ComSign - We issued 30 certificate with those two problems. - The last issuance date was November 3rd, 2014. - The last certificate to expire will be on November 3rd, 2017.
Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert) All of our certificates containing non printablestring characters is issued with teletextstring. The last one of them will be issued by 31/12/2015 due to technology change. The last one will expire by 31/12/2019.
Cybertrust Japan / JCSI nothing
D-TRUST
Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe) We do not issue any SSL-certificates.
Dhimyotis / Certigna
DigiCert
Disig, a.s.
DocuSign (OpenTrust/Keynectis) For #8, this was associated to national requirements: 11 valid certificates are concerned. This topic should terminate by May 2016 with the expiration of the last certificate with this behavior.
E-Tugra
EDICOM
Entrust
GlobalSign 10. This questionnaire does not specifically refer to SSL/TLS, so we are going to have to say yes, as IA5String is used in all cases where E=email within the DirectoryString. This does not happen for SSL/TLS certificates. See page 24 of RFC5280 that allows this. So if the intention is to focus on SSL then indeed we don't use IA5 but if the intention is to ask if IA5 is used then yes we do and yes lots of other CA's do too.
GoDaddy We have 569,000 valid, unrevoked certificates containg this flaw. The last of these expires on May 9, 2021; however, the last signed with SHA-2 expires on May 1, 2019.
Government of France (ANSSI, DCSSI) number of existing certificates : 580 last of those certificates expire in the middle of 2017
Government of Hong Kong (SAR), Hongkong Post, Certizen
Government of Japan, Ministry of Internal Affairs and Communications We have OCSP for Root and Sub. And OCSP server for RootCA get RootCA's crl, and OCSP server for RootCA set next update of RootCA's crl to nextupdate on OCSP Responses. It is conformed with RFC2560. RootCA's crl is within 90 days. apply to #5? Well, I have a question. When connecting to an https server at www2.gpki.go.jp by Firefox 37.0.1 on Windows7 SP1 32bit, as far as seeing outgoing packets captured locally at the client, Firefox seems to have sent OCSP request of the SSL certificate to the responder at http://ocsp-sub.gpki.go.jp. While it does not seem to send any requests for validating ApplicationCA2 Sub's certificate, which is an issuer of the SSL certificate. Could you teach me if the behavior above on OCSP validation is a design of Firefox?
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV) we had issued the certificates with basic_constraint extension explicitly encoded to the default value end_entity. When we read the policy and realized the error, we stop issuing it but we have still active certificates issued to this value. We have about 300 active certificates with this problem. The last expire in mid-2017.
Government of Taiwan, Government Root Certification Authority (GRCA) We don't issue any certificate with these problems.
Government of The Netherlands, PKIoverheid (Logius) 1. Our G1, G2, have no EKU in intermediate CAs. Our G3 and EV root do have EKUs in the issuing CAs with id-kp-serverAuth.
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) We have ~300 end-user certificates with the problems above but, they all expires before Jan.1.2017. We have established a new root and chain however the new root is not in your trusted list yet. When you accepted this new root, there won't be these problems.
HARICA
IdenTrust Services, LLC Action 4.1: Identrust has only one intermediate CA under this condition, which expires on June 5, 2016. This CA does not have any active end-entity certificate at this point and is used to issue CRLs only. Action 4.2: IdenTrust issues SMIME certificates to a legacy customer that contain the value CA=false in the basicConstraints extension. IdenTrust is in the process of migrating this customer to a newer implementation by the December 31, 2015. Currently there are 3,100 certificates active. Based on current migration plan, the last certificate will expire on December 31, 2017. Action 4.5: For majority of certificates issued, IdenTrust offers real time validation and accomplishes this by not populating the "expiration date" in the OCSP responses. This configuration is consistent with RFC 6960 in Section 4.2.2.1 “If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time." Action 4.8: For a VPN use case, IdenTrust has issued certificates that do not contain the KeyEncipherment though they have the Extended Key Usage server authentication use. Three certificates have been issued and the latest will expire on December 18, 2016 Action 4.10: IdenTrust issues SMIME certificates to legacy customers that include the EmailAddress field in the Subject Distinguished Name. The EmailAddress is encoded as IA5String. IdenTrust is in the process of migrating these customers to a newer implementation by December 31, 2015. Currently there are ~4,500 certificates active. Based on current migration plan, the last certificate will expire on December 31, 2017.
Izenpe S.A.
Microsec Ltd. Item 2 Presently we have 227 pcs SHA1 based certificates and 222 pcs SHA256 based certificates with this problem. The last certificate was issued at 2015-05-29 15:54:35 The last certificate will expire at 2017-05-‎28 15:54:35 We will not issue more certificates with this problem.
NetLock Ltd.
Nets DanID
PROCERT
QuoVadis
RSA the Security Division of EMC These issues do not apply to the "RSA Security 2048 V3". It is not beleived these issues apply to certificates issued by intermediates RSA/EMC CAs. Further investigation is required to validate this. To follow.
SECOM Trust Systems CO., LTD. #2 343 certs. #5 1 cert. #9 2756 certs.
Sectigo #1 Number of currently-valid certificates: 12 Latest notBefore: January 1, 2007 Latest notAfter: May 30, 2020 https://bugzilla.mozilla.org/show_bug.cgi?id=737802 explains the situation. As comment 9 says "COMODO need this behaviour until June 2020". #9 Number of currently-valid certificates: 139 Latest notBefore: June 19, 2008 Latest notAfter: July 29, 2018 #10 Number of currently-valid certificates: 304291 Latest notBefore: June 6, 2015 Latest notAfter: March 19, 2022 For historical reasons we have always used TeletexString for common names that contain the wildcard (*) character and for some other subject attributes under certain conditions. Starting from June 7, 2015, we will use UTF8String instead for such certificates.
SecureTrust Trustwave stopped this practice on 10/26/2012. We have 1239 remaining still valid with the last still one expiring on 1/18/2016.
SG Trust Services We don't have any currently-valid certificate yet. SG TRUST stop the issuing of SSL certificate.
SK ID Solutions AS #1 No, intermediate CA does not have EKU extension. #2 No, Basic Constraints is non-CRITICAL in end entity certificates, no explicit values set. #3 No. #4 This is true when OCSP request doesn't contain nonce extension. When OCSP nonce extension is used in request, then responseExtensions is also containing the nonce extension. #5 We don't use nextUpdate field, because our OCSP is a real time OCSP responder. #6 No. All active certs like this: 145:d=3 hl=2 l= 13 prim: UTCTIME :120510140425Z #7 No. In OCSP responses we don't use nextUpdate field and therefore OCSP response signing certificates does not expire before OCSP responses expires. #8 No, all active EKU "TLS Web Server Authentication" certs have a KU "Key Encipherment". #9 Yes. Most older certificates, not new ones. #10 Yes, majority have IA5STRING emailAddress in Subject set. New certificates do not have emailAddress anymore. All other Subject fields are PrintableString or UTF8String. #11 No, name constraints extension not used.
Start Commercial (StartCom) Ltd. All - if we stop including it that would be in exactly three years. Though I'm not sure what harm can cause by including a default value, I assume that a browser should be lenient with that.
Swisscom (Switzerland) Ltd There are several hundreds of certificates with this problem. We are still issuing such kind of certificates and the last one: Valid From 01. June 2015, 11:22:23 UTC (GMT) Valid Until 31. May 2018, 11:22:23 UTC (GMT)
SwissSign AG
Symantec / GeoTrust We issue many certs having T61STRING encoding in Subject DN.
Symantec / TC TrustCenter We issue many certs having T61STRING encoding in Subject DN.
Symantec / Thawte We issue many certs having T61STRING encoding in Subject DN.
Symantec / VeriSign We issue many certs having T61STRING encoding in Subject DN.
T-Systems International GmbH (Deutsche Telekom)
Taiwan-CA Inc. (TWCA) 3 CN = TWCA Secure SSL Certification Authority OU = Secure SSL Sub-CA O = TAIWAN-CA C = TW 2014/10/28 15:27:56 ~ 2024/10/28 23:59:59 CN = TWCA Global EVSSL Certification Authority OU = Global EVSSL Sub-CA O = TAIWAN-CA C = TW 2012/8/23 09:53:30 GMT ~ 2030/8/23 15:59:59 GMT CN = TWCA InfoSec User CA OU = User CA O = TAIWAN-CA Inc. C = TW 2012/6/8 09:51:19 ~ 2022/6/8 23:59:59
Telia Company (formerly TeliaSonera) This answer is a strong assumption based on known CA configurations. No full certificate scan was done.
Trend Micro
Trustis
TurkTrust
Verizon Business
Visa
Web.com #10 Number of currently-valid certificates: 14175 Latest notBefore: June 6, 2015 Latest notAfter: February 18, 2020 For historical reasons we have always used TeletexString for common names that contain the wildcard (*) character and for some other subject attributes under certain conditions. Starting from June 7, 2015, we will use UTF8String instead for such certificates.
Wells Fargo Bank N.A.
WISeKey 2. All of our end entity certificates have this issue. They all have cA:false explicity enceded 3. All of our end entity certificates have this issue. e.g. 2.5.29.19: Flags = 1(Critical), Length = 2 Basic Constraints Subject Type=End Entity Path Length Constraint=None
WoSign CA Limited
Grand Total 4 12 4 2 3 1 1 3 9 11 1 39