I need some clarification on something here

1) Why are legacy certs not being allowed to expire, and instead we are being 
forced to replace in a very short window? We stopped issuing certs with 
underscores as soon as our CA told us to (probably mid-September) but that 
still puts me at having hundreds of certs needing remediation in a period where 
retail production systems are not allowed to be touched.

2) If a certificate is not used to host a URL (say for server to server 
communication or 2way SSL... what does it matter, and can we allow those to 
remain till natural expiration? 

3) Is there any exception process available that will allow us to keep our 
existing certs through their validity?

Thank you

On Monday, November 12, 2018 at 4:19:17 PM UTC-7, Wayne Thayer wrote:
> As you may be aware, the CA/Browser Forum recently passed ballot SC12 [1]
> creating a sunset period for TLS certificates containing an underscore
> ("_") character in the SAN. This practice was widespread until a year ago
> when it was pointed out that underscore characters are not permitted in
> dNSName name forms, and ballot 202 was proposed to create an exception to
> RFC 5280 that would allow the practice to continue. When that ballot
> failed, some CAs stopped allowing underscore characters in SANs and others
> continued. Ballot SC12 is intended to resolve this inconsistency and
> provide clear guidance to auditors.
> 
> The sunset period defined by ballot SC12 is very short. Today Mozilla sent
> an email to all CAs in our program informing them of this change and asking
> them to take any steps necessary to comply [2].
> 
> - Wayne
> 
> [1]
> https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
> [2]
> https://wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to