Red Hat & Mozilla’s plan to distrust Symantec CAs
Contents
Executive Summary
This article provides details about the imminent and future plans of browser vendors Mozilla and Google. The browsers Firefox and Chrome/Chromium will distrust widely deployed certificates that were issued by the Certificate Authority (CA) brands Symantec, Verisign, GeoTrust, Thawte and RapidSSL.
Red Hat customers are advised to proactively identify and migrate all affected certificates, in order to avoid disruption to the services these customers access or operate.
The expected timing of the certificate distrust, which depends on the type of client software and type of service, is outlined. Web services and browsers that access web services will be affected in two phases in April/May 2018, and in September/October 2018. A broader distrust affecting additional software is expected to follow at a later time.
Introduction
Symantec is a company that operated the CAs of the brands named Thawte, RapidSSL, GeoTrust, Verisign, and Symantec. For the remainder of this document, the term Symantec is meant to include the CAs of all of these brands.
Because of irregularities related to the CAs of the Symantec, Verisign, GeoTrust, Thawte and RapidSSL brands, the browser developers Mozilla and Google have decided to phase out the trust for those CAs for SSL/TLS server authentication during the year 2018. If a Red Hat customer is using a certificate from one of the mentioned brands, and the customer hasn't yet migrated and replaced them to use certificates from DigiCert or other brands, the customer will be affected.
The separate CA company DigiCert has acquired the operations of the former Symantec CA group, and is working to migrate customers off of the legacy Symantec CAs to use certificates from DigiCert's own, separate infrastructure.
This document discusses Mozilla’s plan to distrust all CAs of the mentioned brands for the SSL/TLS server authentication use, and the consequences and recommended actions for Red Hat customers.
In addition to trust for SSL/TLS server authentication, Mozilla maintains an additional trust category for email protection, and several Symantec CAs are trusted by Mozilla for this purpose. Certificates issued by CAs for individual persons are commonly used for S/MIME digital signatures and encrypted messages, or for SSL/TLS client authentication. At the time of writing this document, Mozilla has not yet announced plans to distrust the Symantec CAs for email protection.
Consequently email and client authentication certificates are not yet affected by the current distrust plans and are outside the scope of the remainder of document. Nevertheless, it is possible that the Symantec CAs might get fully distrusted by Mozilla at a later time.
Background
A typical use of Red Hat software is to either operate SSL/TLS servers, or to use client software to access SSL/TLS servers. If a Red Hat customer is operating server software that requires a certificate for its configuration and operation, or accesses third party Internet systems, the customer might be affected.
SSL/TLS servers and clients usually depend on server authentication certificates that are issued as part of the Internet PKI, which is implemented using the services of Certificate Authorities (CA).
In this document, we discuss server authentication certificates that are issued for server names that use the Internet Domain Name system. This includes servers that are accessible on the public Internet (e.g. www.example.com, imap.example.com), but also servers operated on private Intranets, which use hostnames that belong to public Internet domains (e.g. intranet.example.com).
In order for a server authentication certificate to be automatically accepted by client software that connects to the server, the client software needs to trust the CA that issued the certificate.
The Mozilla organization runs a project to evaluate the operators of CAs. If Mozilla concludes that a CA complies with its requirements, then Mozilla includes the CA in the CA trust list that Mozilla maintains.
Although Mozilla primarily declares its CA trust list for use in the Mozilla Firefox software, the use of Mozilla’s trust list in Red Hat Enterprise Linux (RHEL) isn’t restricted to Firefox. The list is included with RHEL in the ca-certificates package. It is used by most client software that connects to Internet services, and allows such software to benefit from Mozilla’s CA trust decisions, and allow it to automatically verify the authenticity of servers, without requiring manual user verification. In other words, connections are allowed, if a server presents a valid certificate, that was issued (directly or indirectly) by a CA found in the trust list, and no other reasons (e.g. revocation or expiration) are identified that cause a certificate to be interpreted as not valid.
Intentions and Recommendations
Red Hat customers are advised to investigate, if they are operating servers that use affected certificates. Although the affected CA companies have intended to proactively contact their CA customers, such contact attempts may fail. It is advisable for Red Hat customers to double-check if they are affected. Any services that are operated by Red Hat customers, but which don't use certificates provided by any of the mentioned brands, are unaffected.
Symantec provides resources for their customers to identify affected certificates, please refer to the following Symantec blog post: https://www.symantec.com/connect/blogs/information-replacement-symantec-ssltls-certificates
Red Hat customers are advised to investigate, if they are accessing any servers for their business needs, which use affected certificates. If any such servers are found, Red Hat customers are advised to contact the operators of those servers, and ask them to perform a migration to unaffected certificates.
The following public resources, which aren’t operated by Red Hat, might be useful:
The following web site, which is operated by Symantec and DigiCert, can be used to check the status of a certificate used by a given hostname: https://www.websecurity.symantec.com/support/ssl-checker
The CLI tool “tlsobs”, which is developed by Mozilla, can be used to check the status of a certificate used by a given hostname, which is made available as part of Mozilla’s TLS observatory project. Information about the “tlsobs” tool can be found at https://github.com/mozilla/tls-observatory/blob/master/README.md
To ensure continued operation, each affected server must be upgraded to use a new certificate, which was issued by a CA that isn't affected by the planned distrust.
Because of the large number of servers that require an upgrade, Mozilla and Google have decided to use a distrust timing that is expected to avoid a major disruption to connectivity on the Internet.
The graduated distrust will occur in multiple phases. The time, by which a server will be required to be upgraded, depends on the date on which the current certificate had been issued, and it depends on the type of application protocol that is used by the SSL/TLS server.
The first phase will be implemented in April/May 2018 in the Firefox 60 and the Chrome/Chromium 66 browsers. SSL/TLS web servers, whose services target web browsers, and that are accessed using the https protocol, and that use a server certificate that was issued before 2016-06-01T00:00:00Z or after 2017-12-01T00:00:00Z, will no longer be trusted by the mentioned Firefox and Chromium/Chrome web browsers.
Since 2016-06-01 Symantec has been required to log all issued certificates to the public “Certificate Transparency” infrastructure. This increased transparency is the reason why a longer transition time has been allowed for certificates that were issued after that date. The old Symantec infrastructure was no longer allowed to be used after the 2017-12-01 date, which is the reason why certificates that were issued after that date are not accepted.
For additional details please see:
http://www.tomshardware.com/news/google-symantec-certificate-transparency-system,30443.html
and
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Oaeqtddo_Cw/Vl7bJvQKCQAJ
An analysis performed by Mozilla in March 2018 showed that about 1% of the top one million Internet sites still haven’t performed the upgrade that will be required to ensure connectivity after April/May 2018.
The second phase will be implemented in September/October 2018 in the Firefox 63 and the Chrome/Chromium 70 browsers. The date restriction of the first phase will be removed, and the distrust will cover all servers using an affected certificate, regardless of the time the certificate had been issued. Red Hat will not ship Firefox 63, but instead it will ship Firefox ESR 60.3. Although it is currently undecided, it seems likely that Firefox ESR 60.3 will implement this second phase, too.
Red Hat appreciates Mozilla's and Google's initiative to improve the security of the Internet PKI ecosystem. Pushing for migration of web servers that are accessed interactively using web browsers is a reasonable initial step to migrate the Internet off of the major Symantec CAs that have been shown to not fulfil the high expectations of the Internet PKI.
Red Hat intends to comply with the decisions made by Mozilla and Google for the Firefox and Chromium browsers, and will include these distrust actions in these web browsers. This is a global initiative that affects the worldwide use of those browsers, and it needs collaboration from everyone to reach the goal of phasing out the use of the Symantec CAs.
It is advisable that administrators of deployments perform an investigation of their environment, prior to upgrading their users to these newer browser versions. Administrators and users who experience connectivity issues should ask the operators of services to upgrade to unaffected certificates. A workaround for accessing critical systems, while waiting for the service to be upgraded, is to temporarily downgrade to a previous browser version.
These two phases that have been described above complete the distrust from the point of view of the Firefox and Chrome/Chromium web browsers. However, the certificates issued by the Symantec CAs aren't limited to SSL/TLS web servers that are accessed using the https protocol, they are also used by other servers, such as servers that combine the SSL/TLS security layer with LDAP, IMAP, SMTP, XMPP or other application protocols.
Because the security concerns related to CAs of the Symantec group aren't limited to certificates issued for the web server purpose, it seems appropriate to eventually extend the distrust to all affected SSL/TLS servers in a third phase.
However, because the browser products cannot push for the distrust of those non-https certificates, it is currently unclear at what time they should be distrusted. The decision, if and when a third phase of complete distrust should be implemented, must be made by vendors of other SSL/TLS client software, such as Red Hat, for the software they ship themselves.
Besides the major browsers Firefox and Chromium, RHEL ships additional SSL/TLS client software. A few examples are the cURL and wget tools, email clients like Gnome Evolution, LDAP client software, etc. which use https or non-https application protocols to access servers.
Because of technical limitations, this broad category of client software will not implement the first phase of distrust in April/May 2018. Most likely it will also not implement the second phase of distrust in September/October 2018.
The Thunderbird email client is a special case, because it is also produced by browser maker Mozilla, and shares a lot of the code of Firefox, including the code for certificate trust and distrust. Although a decision hasn't been announced by Mozilla yet, it is likely that Thunderbird will follow the distrust actions of Firefox. Red Hat will follow the decisions made by the Thunderbird developers.
Implementing a third phase for software other than Firefox/Chromium/Thunderbird, in which the distrust could be extended to all certificates issued by the legacy Symantec CAs, is difficult.
In general, DigiCert has stated that its migration initiative isn't limited to web server certificates, but generally covers all certificates with the server authentication key usage, which includes the servers that use non-https application protocols. (DigiCert's migration initiative doesn't cover special server to server communications.)
However, it is necessary to consider a set of exceptions, that were allowed as part of the graduated distrust plans.
The Symantec CA group had cooperated with a few organizations, and had allowed them to obtain subordinate CAs. Those were operated strictly separately from Symantec, and the keys used for those subordinate CAs were never controlled by the Symantec CA group. Those subordinate CAs had been signed by a Symantec CA, which enabled the certificates they issued to be trusted by SSL/TLS client software.
Because of this separate operation, and because no issues are currently known related to these subordinate CAs, and because of long term compatibility requirements with special purpose hardware and software operated by customers of those subCAs, they have been granted permission to be excluded from the distrust plan.
These subordinate CAs are controlled by Apple, Google/Alphabet and DigiCert. The DigiCert subCAs were used to issue certificates for a wide set of organizations. The subCAs and the issued certificates are required to remain trusted after the second phase of graduated distrust, in order to avoid disruption. It is unclear for how long it will be required to keep trusting these subordinate CAs.
It is a major technical challenge to implement these exceptions, because this kind of exception is undefined in the PKI standards, and most software that implements PKI/X.509 certificate validation doesn't contain code to support it. Although the browser makers Mozilla and Google have agreed to implement special modifications to their certificate validation software, these modifications cannot be fully implemented in all parts of the diverse software stack used across Red Hat's products.
Because RHEL uses a default CA trust list that is shared by many applications which cannot implement these exceptions, but which might need to connect to systems that rely on excluded certificates, changing the default CA trust list on RHEL to fully distrust the Symantec CAs could result in disruption of deployments.
Consequently, for existing and supported product releases, the third phase of distrust (for software other than Firefox/Chrome/Chromium/Thunderbird) will be postponed to a later time that hasn't been defined yet. It may be necessary to continue to fully trust some or all of the Symantec CAs for an unknown period of time in the default configuration, because of the inability to limit the Symantec CA trust to the mentioned exceptions.
For future major product versions, Red Hat may decide to fully implement the third phase by distrusting all Symantec CAs, without implementing the exceptions.
Red Hat will continue to monitor the events related to the Symantec distrust.
At a future time, Red Hat might offer a configuration mechanism for supported product versions, which allows a system administrator to override the default configuration and to fully distrust all Symantec CAs, if this configuration is deemed compatible with a deployment by the administrator.
At a future time, alternative trust configurations might become available, which may allow to limit the exceptions to the subordinate CAs, without requiring software modifications. The trivial approach to mark those subordinate CAs as fully trusted has been investigated and cannot be used, because of the complex cross signing configurations used by the CAs, and because of common limitations in trust chain implementations. (The exceptions aren't based on subject/issuer names, but on subject public key information, SPKI.) It has been suggested to potentially add trust for new DigiCert Root CAs, which could replace the legacy Symantec CAs and could be sufficient to implement the exceptions for the subordinate CAs. But this potential solution would need careful research before it can be considered.
At a future time, the requirement to support the exceptions might eventually cease to exist, and Red Hat might decide to fully distrust the Symantec CAs at that time in the default configuration.
Despite the current intention to postpone the implementation of a third phase of full distrust to an unknown future date, it is recommended that customers plan to migrate all environments to replace affected certificates as soon as possible. It is useful to migrate off of the use of certificates that had been issued by the Symantec CAs, to prepare for a scenario in which a more expedited full distrust of the Symantec CAs might become necessary.
