As of August 1, 2018, all Certification Authorities (CA) can no longer validate domains by matching WHOIS domain registrant search results with certificate requester.
Purpose of Ballot: Section 3.2.2.4 says that it “defines the permitted processes and procedures for validating the Applicant’s ownership or control of the domain.” Most of the validation methods actually do validate ownership and control, but two do not, and can be completed solely based on an applicant’s own assertions.
Since these two validation methods do not meet the objectives of section 3.2.2.4, and are actively being used to avoid validating domain control or ownership, they should be removed, and the other methods that do validate domain control or ownership should be used.
WHAT ARE THE ACCEPTED VERIFICATION METHODS POST ?
- Email Authentication: A confirmation email will be sent to the contacts listed on the WHOIS record who can authorize you to continue issuing certificates for the domain.
This method is best used when you or someone you know within your organization has access to the email addresses provided on your WHOIS record and when the record is publicly available. - DNS Verification: Certificate Authorities will provide clients with a random value that they can then post to their domain DNS record. Once detected, their domain will be re-validated among the validating CA.
This method is best used when you or someone you know within your organization has access to the domain DNS record - Web Server Authentication: Certificate Authorities will provide a random value that the must upload on a server that hosts web content for the domain in question. Once detected, their domain is re-validated among the validating CA.
This method is best used when you or someone you know within your organization has access to a Web Server that hosts public web content for the domain in question.
Why is this happening?
Google has been reviewing some of the manual Domain Validation methods and providing their recommendations to remove them to the community. Their belief is that these manual methods, as they existed, were weak and prone to failure, and who is anyone to question the all mighty Google..?
So ballot 218 was introduced into the CA/B Forum for removal of validation methods 1 and 5 with an effective date of August 2018, which provided CAs sufficient time to remove these methods from their validation practices and re-validate all domains using another method. There was great debate at the Validation Summit on March 6th, the first day of the CA/Browser Forum face –to-face meeting in Reston, VA, on how to define manual domain validation methods with sufficient security.
What were validation procedures 1 and 5?
- 3.2.2.4.1 Validating the Applicant as a Domain Contact:
This method allows a CA to validate the certificate requester control over a domain on an SSL/TLS certificate order by verifying that the requester is the Domain Contact directly with the Domain Name Registrar. - 3.2.2.4.5 Domain Authorization Document:
This method allows a CA to validate the certificate requester control over a domain on an SSL/TLS certificate order using the confirmation to the authority of the requester to order a certificate for said domain as contained in a Domain Authorization Document.
Hindsight – Issues?
In hindsight more than one validation method should be used and the human element should not be the one that gets cut out. Some CAs tend to use a mixture of Email Verification and both Validation procedure 1 and 5 above especially for Extended Validation (EV) certificates. This manual process allows for a more human interaction. Where CA representatives are allowed to play detective checking multiple sources in order to verify that the requester of the certificate is authorized to get a certificate issued. This also allows human interaction to double check and ensure that there is no odd occurrences such as hacking within the automatic validation process. So instead of removing 1 and 5 why not improve on it? We will see what the future brings.
Validation methods such as Web Server Authentication opens back doors to Domain Spoofing as admins tend to become placid in the management of there server system especially when paired with auto install. Some CAs such as Let’s Encrypt use these validation procedures which can lead to become potential hazards. In order to stay ahead of hackers a human element will always be necessary to enforce up to date security trends and standards.
Earlier this year Let’s Encrypt published a report on a discovered vulnerability with the ACME TLS-SNI-01 validation method that could allow users on shared hosting or CDNs to obtain certificates for domains they don’t control when the domain resolves to the same IP address as a domain the attacker controls.
Let’s Encrypt quickly disabled the function, initially as a temporary measure, but after learning that many other hosting software might be affected, they decided to permanently disable it for most new issuance. More on this here.
Other Great Articles to Read:
Go Daddy & Let’s Encrypt Cause Security Concerns and Leaks
http://www.acmetek.com/godaddy-lets-encrypt-automated-dv-issue/
Posted by:
Dominic Rafael
Senior Lead IT Engineer
Be sure to Subscribe!!