Managing SSL certificates may be getting that much more difficult

Remember when you used to be able to get an SSL certificate that lasted 3-5 years? Now you can only get one that lasts 2 years, and a change proposed by Google would reduce the maximum validity period to just 13 months beginning March 2020. This would be a global change to the industry, impacting all certificate authorities.

Read this important update from Digicert:

IMPORTANT UPDATE

Dear Security Professional, We are reaching out to you regarding an important proposal raised recently at the CA/Browser Forum that could impact the products you are using. What’s happening? Google proposed a change that, if the ballot passes, will reduce the validity period of certificates from the current maximum of two years to 13 months. The proposed ballot was endorsed by Apple and another CA, making the ballot eligible for voting. If the ballot passes at the CA/Browser Forum, the change in requirements will go into effect in March 2020. Any certificates issued after the effective date would need to comply with the shortened validity period requirements. Even if the ballot fails, the browsers sponsoring the ballot could unilaterally implement this requirement in their root program and make compliance required for certificates issued by trusted CAs in their root stores. This change is a follow up on Google’s previous initiative to reduce lifetimes from three to two years https://www.digicert.com/blog/3-year-certificates-eliminated-industry-wide-change/) in 2018. Who is impacted? The changes proposed by Google would impact all publicly trusted TLS certificate users, regardless of which certificate authority issues the certificate. If the ballot passes, all publicly trusted certificates issued or re-issued after March 2020 would have a maximum validity of 13 months. Customers using certificates with validity periods longer than 13 months are encouraged to review their systems and evaluate how the proposed changes might impact their deployment and use of certificates. Please note that all TLS certificates issued prior to March 2020 with a validity period longer than 13 months will remain functional. This ballot does not affect non-TLS certificates, including code signing, private TLS, client certificates, etc. There will be no need to revoke any certificates as a result of this ballot. This would be a global change to the industry, impacting all certificate authorities. DigiCert’s position DigiCert believes industry-wide changes should be made only after measuring whether the changes in security are sufficiently balanced with the impact on end users. In this case, we feel that further shortening certificate lifetimes, especially absent reasonable timelines for companies to prepare, would have the opposite effect in causing significant pain to customers and possibly leading to some human-caused errors as they scramble to adjust. We believe the goal of improving certificate security is better served by allowing more time for companies to continue their growing use of automation and to prepare for these changes. DigiCert would like to continue the conversation and gather customer input before this issue is brought to a ballot. We think this discussion should include a timeline that allows for companies to properly plan for shorter lifetimes. Regardless of the outcome of this ballot, we stand ready to help our customers. DigiCert’s focus and deployment of discovery and automation tools make sure our systems are fully capable of helping our customers meet changes that may arise in industry standards, including shortening lifecycles. In fact, DigiCert currently offers certificate lifetimes as short as eight hours for customers who want that option. Having said that, our ability to help our customers with these changes doesn’t mitigate all the potential impact that a rushed implementation would have on the industry. What to do The CA/Browser Forum makes changes to standards as security issues evolve. To remain compliant with these changes, organizations with large amounts of certificates should consider sophisticated automation tools to help manage certificate inventories and ease certificate deployment. At DigiCert, we are focused on simplifying the certificate management process and developing new tools for automating certificate use. Customers worldwide use DigiCert to automate their process using our Lemur plug-ins, REST APIs, SCEP and EST services, and ACME service. Combining ACME with the automated scanning service in CertCentral allows TLS customers to easily scan their entire environment, find certificates that require replacement, and deploy up-to-date technology. DigiCert will continue to keep you apprised of CA/B Forum activities. Please read our position to the industry in this new blog: https://www.digicert.com/blog/how-reduced-tls-ssl-certificate-lifetimes-to-one-year-would-affect-you/ Be heard The CA/Browser Forum accepts comments from outside participants; however, all discussions are public. You have two choices: you can submit your comments to DigiCert through this survey, which we plan to summarize and provide to the CA/B Forum or you can join the CA/B Forum as an Interested Party, which will allow posting of your comments directly to the Forum mailing list. See https://cabforum.org/working-groups/ (bottom of page). We are eager to share information with the browsers about the impact these changes may have on customers. We look forward to providing this information and representing your interests in the Forum and security world.

Read more ...

Fix for Certificate Error in Chrome - NET::ERR_CERT_COMMON_NAME_INVALID

It amuses me when Google dictates security policy.

Beginning with Chrome 58, the Chrome browser no longer uses the Common Name (CN) field to validate an SSL certificate. Instead, it only uses the Subject Alternative Name field.

This is in violation of RFC 2828 which states,

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

So someone in Google security said, "Hey! If RFC 2828 says the Common Name is deprecated, we should start making Chrome ONLY use the Subject Alternative Name! Existing practice, be damned." Never mind the fact that the RFC was written May 2000, and every other browser and app on the planet uses the Common Name field for single-name certificates.

Therein lies the problem. Most single name certificates and some wildcard certificates only have a Common Name and don't have use Subject Alternative Names. This causes Chrome 58 and later to display the following (incorrect) error. It even goes so far as to blame it on a server misconfiguration.

NET::ERR_CERT_COMMON_NAME_INVALID [missing_subjectAltName]

This same website (in this case, OWA) displays properly in all other browsers. If we look at the certificate, we see this is a wildcard cert for *.contoso.com issued by an internal certification authority (CA). The Details tab shows there is no Subject Alternative Name field for this cert.

Wildcard certificate details with only a Common Name (CN) field

To fix the error for your Chrome users, you'll need to regenerate the certificate to include a Subject Alternative Name. Here's how to do that using the Certificates MMC when you have an internal Certification Authority (CA).

From the web server, open MMC and add the Certificates snap-in, managing the Computer account. Then expand Certificates (Local Computer) > Personal > Certificates.

Right-click Certificates > All Tasks > Request New Certificate.

Choose Active Directory Enrollment Policy to use your existing internal CA.

Select the Web Server certificate template and click the link below it to enter more information.

Add the Common Name for the Subject Name, and the DNS name for the Alternative Name. They can be the same value. Chrome 58 and later only uses the DNS alternative name.

Enter a Friendly Name on the General tab.

Optionally, make the private key exportable on the Private Key tab and click OK.

Click Enroll to generate the new cert from the CA and install it on the web server.

The certificate will be installed. Click Details to view the new certificate.

On the Details tab we see the Subject Alternative Name is on the new cert.

Now you'll either need to configure IIS to use the new certificate (Web Site - Bindings) or reconfigure Exchange web services using the Enable-ExchangeCertificate cmdlet.

Read more ...