Is HTTP/HTTPS domain control validation your go-to method for validating wildcard domains? Starting in November, you’ll need to use DNS or email validation for wildcard SSL certificates
If you follow the CA/Browser Forum (CA/B Forum), it’s likely that you’ve at least heard about some of the changes that are occurring this year. (And if you haven’t, it’s probably because you have more of a life than we do. But don’t worry, we’re about to give you the lowdown regarding what you need to know about one of the biggest changes.)
Ballot SC 45, also known as the Wildcard Domain Validation ballot, is the latest domain control validation (DCV) change to come out of the CA/B Forum. It changes the requirements relating to how CAs can validate your wildcard domains and subdomains when issuing wildcard SSL certificates for your sites. Starting in November, you won’t be able to use file-based authentication for wildcard certificates. Instead, you’ll need to use DNS or email-based authentication.
The change was created in response to the concern that host-based control validation isn’t a strong enough way to demonstrate that someone has control over a domain’s entire namespace. It received unanimous support by CA/B Forum members because it improves security for subdomains.
But what exactly does this change entail for wildcard and multi-domain wildcard certificate users? And what does all of this mean for validating domains without the use of what’s considered a go-to method?
Let’s hash it out.
First, A Quick Refresher on Domain Control Validation Methods
Whenever you request a digital certificate to secure a specific website domain, you need to prove that you actually control that domain. Domain control validation (DCV) is an important part of the certificate request and issuance process. Traditionally, there have been three methods you could choose from to accomplish this task. Here’s a quick overview of the three types (listed in no particular order):
- Email-based validation — This domain validation method is the easiest. It involves you receiving and acting upon an email sent to the account listed on your domain’s WHOIS record (such as firstname.lastname@example.org).
- File-based validation (HTTP/HTTPS validation) — This method of domain validation requires you to upload a text file to a specific directory of your domain’s web server. The file must contain specific information that the CA tells you to include to prove you control the domains that you want the wildcard or non-wildcard SSL certificate to cover.
- DNS-based validation (CNAME validation) — This method involves the applicant creating a unique CNAME record in their domain name system (DNS) to prove domain control. For example, Sectigo likes to require their certificate requestors to make their CNAME records point back to Sectigo site.
CA/B Forum Ballot SC 45 Changes the Rules for Wildcard Validation
CA/B Forum ballot SC45, which goes into effect on Dec 1, 2021, specifies that file-based domain validation for certificates will no longer be allowed for wildcard domains — period. The concern here is that it’s not considered a comprehensive enough method because this validation method only provides control over a host and service, not the domain namespace as a whole. The ballot had broad support and passed unanimously with 22 certificate issuers and five certificate consumer groups voting for it.
Say, you control the individual FQDN trekkie4evah.com. It doesn’t automatically prove that you also control other areas of your domain namespace (such as the subdomains email.trekkie4evah.com or login.email.trekkie4evah.com). Someone malicious could validate domains that they use for phishing campaigns and other cyber attacks.
So, what does this mean if you use file-based validation for non-wildcard domains? You’ll need to validate each FQDN or subject alternative name (SAN) domain that you want to cover individually. In other words, using the file-based method to validate domain.com will no longer validate subdomains on the same root (*.domain.com, sub.domain.com, etc.).
Ballot SC45 applies to the domain control validation sections of the CA/B Forum’s Baseline Requirements listed in the table below:
|Baseline Requirement Section||Summary Description of What This Section Entails||Changes Based on Ballot SC 45|
|126.96.36.199.6 — Agreed-Upon Change to Website||This section of the baseline requirements discusses re-using information from past validations from the HTTP/HTTPS method to confirm domain control.||Because SC 42 passed, no changes were made to this section because it already prevents the re-use of past validations or new certificates after June 30, 2021.|
|188.8.131.52.18 — Agreed-Upon Change to Website v2||This section refers to the HTTTP status code responses a CA must receive through file-based domain validation that involves verifying request tokens or random values within a specified file.||Starting Dec. 1, 2021, CAs are required to separately validate “other FQDNs that end with all the labels of the validated FQDN” using a separate DCV method prior to issuing certificates for them. Wildcard domain names can’t be validated using this method on or after the effective date.|
|184.108.40.206.19 — Agreed-Upon Change to Website – ACME||This section of the baseline requirements outlines domain control validations that use the ACME HTTP Challenge method outlined in RFC 8555, section 8.3.||The same changes we outlined above for Baseline Requirement 220.127.116.11.18 apply here for BR 18.104.22.168.19.|
Why Eliminating HTTP Validation for Wildcard Domains Is Necessary
All of this may leave you wondering whether getting rid of this domain validation method is necessary. According to the CA/B Forum’s GitHub discussion on Ballot SC45, the goal here is to make it clear that using the HTTP/HTTPS method to validate a single domain demonstrates control of a single FQDN. This method of validation doesn’t prove control of the FQDN’s entire namespace as a whole (i.e., all of the domains and subdomains that exist within that namespace).
It’s possible someone could have control where domain.com is hosted but not be an authorized admin of the server where any of the subdomains are hosted. However, it seems like it’s more of a theoretical concern than a widespread, real-world issue.
DigiCert, Sectigo Will Roll Out Their DCV Changes Ahead of Schedule on Nov. 15, 2021
Although the ballot isn’t supposed to take effect until Dec. 1, 2021, two leading certification authorities (DigiCert and Sectigo) separately announced that they’re individually implementing the validation changes a couple of weeks early. Why? To make sure that everything is working the way it should and that there aren’t any unforeseen issues that pop up at the last minute.
DCV changes for both DigiCert and Sectigo are effective Monday, Nov. 15, 2021. This means that any certificates issued before Nov. 14 will still work as they always have in terms of DCV methods. However, starting Nov. 15:
- file-based validation will no longer be an option for wildcard certificates, and
- non-wildcard certificates will require separate validation for each FQSN/SAN when using the file-based validation method.
So, what does this mean for businesses whose certificate issuers decide to roll out these changes ahead of the Dec. 1 deadline? Let’s illustrate how these changes will affect DCV for various SAN/FQDNs based on the CAs’ Nov. 15 rollout date:
|Certificate & Domain Coverage||Validation Before Nov. 15||Validation After Nov. 15|
|Certificate for the wildcard *.trekkie4evah.com||Allows for the use of any of the three validation methods, including file-based validation||Requires the use of either the DNS- or email-based domain validation method|
|Certificate with SANs for trekkie4evah.com and email.trekkie4evah.com||Allows for the use of any of the three validation methods, including file-based validation||Requires the use of either the DNS- or email-based validation, OR complete file-based validation for each SAN domain individually|
What Should We Do if We’re Currently Using File-Based Validation?
So, what’s the big takeaway from all of this? File-based domain control validation method is going away for wildcard certificates. So, you need to be prepared to use either the DNS- or email-based domain validation method instead. Specifically:
- HTTP validation will no longer apply to wildcard domains and SAN subdomains.
- You (or your customers if you’re an SSL/TLS reseller) will need to choose one of the other two domain control validation methods we mentioned earlier when validating:
- Wildcard domains for single-domain wildcard certificates, and
- Wildcard SAN domains in multi-domain wildcard certificates.
What Does This Mean for Certificate Automation in AutoInstall SSL?
What if you use automation tools? How will this CA/B Forum change affect things? If you’re use the AutoInstall SSL plugin with cPanel, don’t worry — we’ll be releasing an update so that the plugin uses DNS validation by default on wildcard certificates. Stay tuned for more details!
If you have another specific use case that relies on file-based validation for wildcard certificates, reach out to us and we’ll work with you find a solution that meets your needs.
Have questions or concerns about this process? Reach out to your account manager for assistance.