After May 1, 2019, any public certificates with underscore characters will be revoked. Will your certificates comply?
On November 10, 2018, the Certification Authority Browser Forum (CA/B) passed Ballot SC12 which will end the use of underscores (“_”) in the dNSName entry of the Subject Alternative Name Extension (SAN) of publicly rooted certificates.
This change will take full effect on May 1, 2019, when no publicly rooted certificates may have underscore characters in the SAN.
Prior to January 15, 2019, all publicly rooted certificates that have an underscore and have a validity period of more than 30 days will be revoked. However, prior to April 1, 2019, certificates containing underscore characters in the dNSName entry in the SAN may be issued with the following conditions:
- dNSName entries may include underscore characters such that replacing all underscore characters with hyphen characters would result in a valid domain label.
- Underscore characters must not be placed in the left most domain label.
- Certificates must not be valid for longer than 30 days.
Why Revoke Certificates with Underscore Characters in the SAN?
CA/B voted in favor of the change to comply with RFC 5280, Appendix B. ASN.1 Notes, which states:
“Implementers should note that the “@” sign and the “_” characters are not supported by the ASN.1 type PrintableString…Conforming implementations MUST NOT encode strings that include either the “@” or “_” character as PrintableString.”
Previously, third party CAs had been non-compliant with RFC 5280 and previous measures to force compliance had failed to pass with a majority vote. With third party CAs now compliant, public certificate SAN information will now follow a more consistent and predictable format.
What this Means for Publicly Rooted Certificates
If a company currently has publicly rooted certificates that have an underscore character in the dNSName SAN, that certificate must be replaced.
This change only applies to publicly rooted certificates. It will not affect internal PKI certificates that are issued from Microsoft CAs.
Each trusted third party CA (Entrust, Comodo, DigiCert, etc.) is responsible for communicating the changes, and facilitating replacements with their customers. Entrust has stated that they will revoke all certificates that have an underscore and have a validity period greater than 30 days as of January 14, 2019.
How to Ensure Your Public Certificate Complies
The best method to find and update non-compliant public certificates is to use a certificate management software solution like Keyfactor Command.
Keyfactor Command will scan an enterprise environment and import every third party certificate into a centralized management console where every non-compliant certificate can be organized into a collection. Using that collection, Keyfactor Command will automatically replace each non-compliant certificate with a compliant certificate from the third party CA vendor with third party CA Gateways.
For internal certificates, a Microsoft CA will not prevent the use of non-compliant characters and has no mechanism to prevent their use. Keyfactor Command will prevent certificate requests that contain non-compliant characters as well as enforce other industry standards such as RFC 2818.
This change was made to stay compliant with RFC 5280 and has already started to be enforced. Full enforcement will go into effect May 1, 2019, and the third party issuers will communicate next steps to their customers.
However, even with the notices from the third party vendors, finding and replacing the non-compliant certificates by hand is a difficult task without software like Keyfactor Command.
Any non-compliant public certificate will be revoked before January 15th and if a single certificate is not replaced, outages could occur.
It’s also important to note that underscore characters will still be allowed by Internal Microsoft CAs and third party certificate management software, such as Keyfactor Command, is necessary to prevent the use of non RFC 5280 compliant characters.