Editor's Note: This blog was originally published in April of 2021 and has been updated as deadlines and details have changed. The most recent update in November 2021 includes additional information about the prohibition of HTTP domain validation for issuance of subdomains and wildcards. If you are a GlobalSign customer and you have questions about these changes, please visit our Support site for more Help articles and ways to get in touch.
The CA/Browser Forum and Root programs specify requirements that CAs must comply with and be audited against to provide uniform requirements across all CAs and to protect web site visitors by setting important compliance and security requirements. You are all aware that the maximum validity for TLS certificates was reduced from 5 years to 3 years to 825 days and just last September, down to 398 days (about 13 months). In this post, we’d like to inform you of some of the upcoming changes that have been mandated by the Root programs and/or the CAB Forum.
Prohibit the HTTP domain validation method for issuance of subdomains and wildcards
Industry Deadline: December 1, 2021
GlobalSign Effective Dates:
GCC Customers: November 28, 2021
Atlas Customers: November 30, 2021
The HTTP domain validation method (officially known as method 6, Agreed-Upon Change to Website) is commonly used to verify domain control. If you can place a file at a specific directory of the web site it “demonstrates” control over that domain. Unlike DNS, websites don’t have the same controls where there is a formal delegation of permissions from the domain to subdomains. So, if example.com got hacked, or its owner had certain malicious tendencies, they can approve example.com and then issue certs to subdomains. But those subdomains might be different entities, and again, since there is not the same level of formal delegation of control, Mozilla is mandating that issuance of certificates containing domains validated with the HTTP method be limited to issuance of exactly the validated domain. In other words, Wildcards and subdomain SANs will be prohibited for domains validated with the HTTP method.
This will impact customers since it’s a common method for performing domain validation and if you want to continue using this method, then you must validate each SAN:DNSName individually.
More Important Details
To ensure compliance, effective November 28th (GCC Customers) & November 30th (Atlas customers), GlobalSign will prohibit issuing wildcard or subdomain SAN certificates when the domain is validated via the HTTP Domain validation method. This policy applies to all publicly trusted TLS/SSL Certificates as well as GlobalSign's Intranet SSL product.
Examples:
- Prohibits issuance of *.example.com when example.com is validated via the HTTP Domain validation method.
- Prohibits issuance of www.example.com when example.com is validated via the HTTP Domain validation method.
The HTTP Domain validation method may be used to validate the exact SAN.
Examples:
- If you validate www.example.com with the HTTP domain validation method, then you can include www.example.com that in the SAN of the certificate.
- If you validate example.com with HTTP domain validation method, then you can include example.com in the SAN of the certificate.
For more guidance and recommendations, please view our Support Article on this topic: HTTP Domain Validation Method Policy Changes.
CA SHALL verify Domain Names and IP Addresses no more than 398 days prior to Certificate issuance
Effective date: October 1, 2021
Last September, Apple mandated a 398-day max validity period, but the domain and organizational validation reuse period remained at 825 days. This is the second shoe dropping on that change. This reduction in the domain re-use period has been expected and is unlikely to be the last. This stems from several studies that found in certain cases, during domain ownership changes, the existing certificates can continue to be replaced/re-issued from the prior CA. One way to remedy that is to reduce the domain validation re-use period.
Take a step back and think about the situation this way:
- Up until the Apple mandated reduction in maximum validity, the time between domain validation and certificate expiration was 825 + 825 days, or about 4 1/2 years. That’s a long time!
- With Apple’s reduction in max validity, the difference is 825+398 days which is still more than 3 years.
- With this latest change, the max difference is 398+398, or just a bit over 2 years.
- For comparison purposes, the CA that issues the most certificates per year, Let’s Encrypt, issues certificates with a max validity of 90 days and they re-use domain validation for a max of 30 days, or a max of 4 months between validation and certificate expiration.
We can expect the industry to drive towards the Let’s Encrypt baseline and eventually even shorter than that.
Prohibit the HTTP domain validation method for issuance of subdomains and wildcards
Effective Date: December 1, 2021
The HTTP domain validation method (officially known as method 6, Agreed-Upon Change to Website) is commonly used to verify domain control. If you can place a file at a specific directory of the web site it “demonstrates” control over that domain. Unlike DNS, websites don’t have the same controls where there is a formal delegation of permissions from the domain to subdomains. So, if example.com got hacked, or its owner had certain malicious tendencies, they can approve example.com and then issue certs to subdomains. But those subdomains might be different entities, and again, since there is not the same level of formal delegation of control, Mozilla is mandating that issuance of certificates containing domains validated with the HTTP method be limited to issuance of exactly the validated domain. In other words, Wildcards and subdomain SANs will be prohibited for domains validated with the HTTP method.
This will impact customers since it’s a common method for performing domain validation and if you want to continue using this method, then you must validate each SAN:DNSName individually.
Rotating ICAs at Shorter Intervals
Timeline: August 24, 2021 and then quarterly in 2022
GlobalSign will start rotating our Atlas TLS CAs on a scheduled basis to promote good ecosystem security and agility. Historically, we have set up CAs and used them for many years, but there are many reasons to reduce this time interval. By reducing the length of time CAs are used, we achieve the following benefits:
- This limits the number of certificates issued by a single CA and its corresponding private key, which improves our own crypto-agility.
- This limits the impact if there is an integrity, compliance or security issue with the CA.
- This reduces the size of CRLs which increases validation performance.
- This trains our customer base to expect and plan for immediate CA replacements which increases their crypto-agility.
- Our final plan will have all GlobalSign Atlas TLS CAs rotated every quarter and all Customer dedicated Atlas TLS CAs rotated yearly.
- The first GlobalSign Atlas TLS CA rotation for 2021 will take place on August 24, 2021.
- Starting in 2022 we will update GlobalSign Atlas TLS CAs every quarter, on the second Monday of the quarter and we will update Customer dedicated Atlas TLS CAs yearly each January.
Impact and recommendations:
- Customers should always be prepared to accept new CAs when installing new TLS certificates. The issuing CA is available in the API and should be used when downloading the certificate so that the current CA is always provisioned with the issued certificate.
- Customers MUST not do public key pinning to CA certificates, and we highly discourage public key pinning at all, as that defeats the purpose of crypto agility.
- We encourage customers to follow agile practices for Issuing CAs and always download and install the provided ICA when obtaining new certificates.
- Please subscribe to GlobalSign's Status page for important updates here - https://status.globalsign.com/
More information can be found on our Support website.
Changes to ECC Key Usage
Effective Date: July 26, 2021
We will be changing the key usages in our ECC TLS certificates to align with industry best practices and in-process changes to the CA/B Forum Baseline Requirements. Currently we include both digital signature and key agreement, but as of this date we will be changing this to include just digital signature.
Our public trust TLS is used by browsers and web servers to support TLS sessions for end user protection. We will always keep the security of the users of these certificates at the forefront in our considerations when creating new profiles or issuing CAs. It was decided that the need for Key Agreement in ECC certificate usage was no longer required within a TLS certificate, while also introducing potential security issues for end users because the signing key and encryption key should be separate keys within a TLS session. Due to these reasons, the extension was dropped from our general TLS offerings. Customers requiring custom profiles for tools and systems outside the confines of traditional browser-to-server TLS sessions should strongly consider private trust offerings.
Prohibiting Use of the OU Field
Timeline: Aug 31, 2022
Google has long been concerned with how the OU field in TLS certificates is being validated. The Baseline Requirements have clear requirements on all subject fields (C, S, L, Org, etc.) that require the data be obtained from a business repository; however, the OU field requirement remains as:
The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information.
This permits customers to supply unvalidated, and possibly misleading information which may be (inadvertently) relied upon. As such, Google is strongly advocating the removal of the field.
This field is often used by organizations to help them manage the certificates by specifying the department to which the certificate belongs. Certificate reporting helps the organization allocate renewals and replacements based on this field; however, the purpose of the data in certificates is for relying parties, those that visit the site and want to make a decision as to whether or not they should trust the site and not for organizational certificate management.
Customers need to be aware of this upcoming change and to start planning on the deprecation of the OU field. Once again, this change will occur on August 31, 2022.
Have questions? Visit our Support website for more information and ways to get in touch.
