Validating Certificates with Whois is Going Away

The use of Whois to prove domain ownership or control is about to be phased out. There's two important dates that are coming up:

1. From 15th January 2025 onwards, Certificate issuers will no longer be able to use web based Whois services to identify contact information to which they can send proof of control challenges.

2. From 15th June 2025 onwards, Certificate issuers will no longer be able to use the Whois protocol (port 43) to identify contact information to which they can send proof of control challenges.

Domain Control Validation (DCV)

When a Certificate Authority (CA) issues you a certificate, they do so because they trust that you are either the domain owner or the domain controller. This trust is derived using one of several methods. You might hear the term "the 10 blessed methods". This refers to the fact that there used to be 10 methods CAs could use to test your ownership or control of the domain. The actual number of methods documented in the policy is 20, but many of these are listed for historical purposes only and can no longer be used. The number is likely to continually change as new methods are added and old ones are sunsetted.

As a matter of interest, assuming no further changes for the time being, after 15th June 2025 there will be 7 methods.

So if you see "the 10 blessed methods" or DCV mentioned, this refers to the list of acceptable methods (regardless of number) that CAs can use to validate a certificate request.

Owner or Controller?

The earliest methods for validating domain control or ownership tended to be skewed towards proof of ownership. These involved sending physical letters to your address or sending a fax. These were all listed in Whois. Who doesn't miss using faxes instead of emails because they were somehow more trustworthy and telecommunications networks were so secure. Ah, good times.

However in more recent times, validation options tend to prefer proving domain control. This involves proving you can edit the domain zone or web page contents. This is far easier to automate for both CAs and customers. So these days you'll more likely find that CAs will prefer methods that involve some kind of provable change to your domain or website. There are still methods that do allow for email based proof of ownership, but I'd recommend not relying on those being around in the future.

Should I Care?

I haven't seen usage statistics as a proportion of certificates issued, for the impacted methods. So I can't say if there's still a core group of diehard fax toting domain owners renewing certificates this way. I'd guess that these are amongst the least popular issuing/renewal methods today.

However there may be cases where the operational requirements of a domain preclude the ability to edit the zone contents or to update the well known web url path. In these instances, it's possible that a CA has provided certificate issuance or renewal via a method that proves ownership rather than control. In that case, one of these methods could have been used.

So I'd recommend that you review any domain that you don't easily have access to. Domains which you may have inherited as organisations or business names have changed, merged or been bought and sold. Certificates allocated using these methods will not be untrusted or impacted in any way. You'll just have to renew or issue new certificates using one of the acceptable methods in the future.

As mentioned in the previous section there are still methods which allow you to prove ownership via email or phone. However the trustworthiness of these methods is questionable and in my opinion they are also likely to be sunsetted. CAs are not obligated to support all these methods so regardless of policy changes, the likelihood that a method involving email or phone will be supported long term by any CA is surely very low.

Whois Protocol Shortcomings

Whois sucks. As someone who has designed and operated top level domain registries which must deploy Whois services, take it from me, the sooner it dies, the better. More specifically, the CAs and Browser builders are concerned that the vagaries of out of date, poorly understood and unloved systems can be used to issue fraudulent certificates. Go figure.

Whois does not have an inherent method of delegation. There's been attempts at shoehorning one into the ecosystem. But this relies on a mix of hard coding in client software, server software that returns results in an undocumented presentation format and good old fashioned luck. To even call Whois a protocol is laughable. Terse, doesn't begin to describe the limited information provided in RFC 3912. I can hardly criticise those authors, since in the intervening 20+ years, no RFC has replaced it. ICANN documented some details and put those into contracts around 2012, so gTLD Registries and Registrars should now at least return consistently formatted presentation data.

But it's the simplest of raw tcp protocols. While ICANN updated the presentation formats, no authorisation and no method of proving trust worthiness has been documented or deployed for Whois. So how can we trust our software client to fetch the correct information about a domain? There's no mystery answer here, we can't trust it.

Recently some security researchers found that quite a lot of Whois clients appear to query hard coded Whois servers. These configurations were years out of date, yet they saw significant amounts of traffic from current software clients. Bearing this in mind, if the protocol were magically improved tomorrow, the long tail of dodgy Whois clients out there would continue to present serious risks.

The abuse the researchers were able to prove involved taking over the domain of a previous Whois server that was long ago turned off and removed from IANA's Whois registry. They tried to use that control to issue themselves certificates for domains they didn't own. Because the CAs were relying on Whois software that included a hardcoded server address, they succeeded in the attempt.

There's dozens of Registries (mostly ccTLDs) and Registrars that don't update their Whois data. So it's not even necessary to host a Whois server if you can gain control of a defunct email address that hasn't been removed from Whois. This is very typical during re-branding or change of company ownership.

Whois Data Shortcomings

If the protocol wasn't bad enough, the data is junk. The data has always been junk. The Internet community (via ICANN) has tried various policies to try to improve it. This includes a yearly reminder that all Registrars have to send urging domain owners to update their contact data, which they dutifully send to the (out of date?) contact data. Some ccTLDs spend enormous amounts of labour ensuring Whois data is compliant with their policies. Of course doing so can effectively launder malicious registrations since the sanitisation efforts will get rid of common markers that security researchers could use to fingerprint such registrants across TLDs.

Even legitimate domain owners are heavily motivated not to provide accurate private information to Registrars and Registries. The reality that if you store it, then it can be stolen, is understood more by those at risk, the Registrants, than those asking for the data, the Registries.

Good Riddance

The sooner we stop using Whois services and data, the better. Considering the shortcomings I've listed, we have data that Registrants are reluctant to supply and ensure is accurate, delivered over a protocol that is unreliable and insecure. This is not a good basis for trust.

It's important to understand that whether we used Whois to issue or renew our own certificates is irrelevant. We are all at risk because someone else can use Whois to pretend they are the domain owner, thus fraudulently obtaining a cert. We will all be better off once CAs no longer use Whois or any other weak validation (emails to implied addresses is surely just as risky).

References

The CA/Browser forum govern the policies which dictate how CAs should validate certificate signing requests. Any CA that wants to remain trusted in browsers and operating systems will adhere to these policies. The URL for the ballot proposing the sunsetting of the methods using Whois data is below.

https://cabforum.org/2024/11/14/ballot-sc-80v3-sunset-the-use-of-whois-to-identify-domain-contacts-and-relying-dcv-methods/

The Baseline Requirements is the authoritative document which contains the policies developed within the CA/Browser forum. The link below will take you directly to the section which includes all the domain validation methods.

https://cabforum.org/working-groups/server/baseline-requirements/requirements/#3224-validation-of-domain-authorization-or-control

ICANN documented some Whois implementation details. This was intended to constrain contracted parties, with a focus on data formats and presentation requirements. This effort was not focused on broader interoperability or the trust worthiness of the protocol. The document is informational only and did not go through an IETF working group.

https://datatracker.ietf.org/doc/html/rfc7485

While writing this post, I wanted to find a source for the term "10 blessed methods". I have not been able to find any source that I'd consider authoritative that discusses the term 🤷. Nevertheless I have found it to be common amongst experts of a certain age (they know what a modem sounds like).