Public trust SSL/TLS certificates assert an association between a domain name and a public key. The domain name may be a DNS name or an IP address. In this blog we will discuss how DNS names or domain names are validated for trust.
The CA/Browser Forum Baseline Requirements (BR) specify a number of approved domain name validation methods in section 184.108.40.206. In the recent years these methods have been updated, changed and deleted. There is currently some work to add in new domain validation methods. As each method is a subsection (i.e., 220.127.116.11.1), they are sometimes referred to as Method 1, Method 2, etc.
Let’s discuss the allowed method. Please note that as of August 1, 2018, Methods 1 and 5 are no longer valid. Also note Method 11, called ‘Any Other Method’, is also not permitted.
Method 2 – Email to Domain Contact
I have called this Email to Domain Contact; however, the method also allows the domain contact to be reached by fax, SMS or postal mail. Although these are permitted, they are not used for many certificate applicants in production.
Method 2 allows the certification authority (CA) to find an email address in the WHOIS information for the domain name. The CA can also use the SOA record email address. An email is sent with a random value to the domain contact and the domain contact must provide a confirming response which includes the random value. Method 2 can be used for multiple domain names if the domain contact has the same email address. Note that the random values for all methods must have 112 bits of entropy and a 30 day expiry period; after 30 days, the random value can no longer be used.
This method will have issues if the email address is not available in WHOIS. This may be due to registrar privacy offerings or restrictions due to GDPR.
Method 3 – Phone Domain Contact
The phone call method allows the CA to call the domain contact using the phone number found in WHOIS for the domain name. This method seems quite simple, but does have some issues such as 1) the phone number is a general number for the company, 2) there is no answer, 3) a voicemail is left, 4) the phone call is transferred, 5) the person that answers the call is not the correct person, etc.
Method 4 – Constructed Email to Domain Contact
Method 4 is similar to Method 2, but in this case the CA can construct an email address using five defined local parts: admin, administrator, webmaster, hostmaster and postmaster. The email address can be created using the full domain name requested or the domain name can be pruned. In other words, if a certificate was requested for server.example.com, then the CA could create email addresses such as email@example.com or firstname.lastname@example.org.
Once the email address or addresses have been selected, the email is sent with a random value and there must also be a response with the random value.
In the past, there have been issues with this method if the domain name owner does not treat the five specified local parts as reserved. That is, the domain owner should be specific as to who they would allow to use an email starting with “admin”, “webmaster”, etc. There have been cases where an attacker has received a certificate where they had just registered an “admin” email address.
Method 6 – Agree-Upon Change to Website
Website change method allows the applicant to show control of a domain name by putting a random value on a website. The random value must be found on under the “/.well-known/pki-validation” directory over an authorized port number (i.e., 22, 25, 80 or 443). Validation on this website can be extended to allow certificates to be issued to wildcards or all subdomains of the domain name validated.
Method 7 – DNS Change
The DNS change method allows the applicant to show control of a domain name by putting a random value in the DNS text record or the DNS CAA record. This method is very popular as the applicants can prepare scripts to push the random values to DNS TXT.
Method 8 – IP Address
In this method, the applicant must first show control of an IP address. If the IP address is associated with the domain name being validated, then the domain name can be approved. BR section 18.104.22.168 defines how IP addresses can be validated. Method 8 is not that popular as IP addresses are generally not controlled by certificate applicants. In many cases the IP address is controlled by the ISP and assigned to the server operators.
The CA/Browser Forum is currently planning to update the requirements to validate an IP address. More will follow when this is complete.
Method 9 – Test Certificate
An applicant can show control of a domain name if they can first put a non-expired test certificate on the web page. The test certificate must be accessible via TLS over an authorized port. This method will also allow certificates for subdomains or wildcard of the domain name.
Although Method 9 was not attacked, it has been shown to be vulnerable if the web server uses server name indication (SNI). As such, this method is not popular and will probably be removed from the BRs.
Method 10 – TLS Using a Random Number
This method supports the ACME protocol and allows an applicant to show control of a domain name by confirming a random value within a certificate on an authorization domain name which is accessible via TLS over an authorized port. Method 10 is very popular for CAs that allow automated verification using the ACME protocol.
Unfortunately, this method is also vulnerable to attack when SNI is used. The solution to this problem will be to deploy the proposed ALPN challenge extension. When the RFC for this method is finalized, we can expect the CA/Browser Forum to either update Method 10 or replace it with a new method requiring the APLN fix.
Method 12 – Validating Applicant as a Domain Contact
This method is less about domain control and more about domain ownership. In this case, the CA must validate a domain name by confirming that the applicant is the domain contact. This method is restricted as it can only be used if the CA is the domain name registrar or an affiliate of the registrar.
Entrust Datacard and Domain Name Validation
Entrust Datacard has been validating domain names for nearly 20 years. We quite successfully migrated our customers away from Method 1 after issues were discovered with the way Method 1 could have been implemented, which led to its removal from the BRs. Although it was a preferred verification method for us given that our services are highly used by governments and enterprises, we are happy to now use a method that has no known vulnerabilities.
In addition, Entrust Datacard has not implemented Methods 9 and 10, which have also shown to be vulnerable. We will consider Method 10 if it gets updated.
More information about the Entrust Datacard automated methods for domain validation can be found here >>.