Validating challenges from multiple network vantage points


Later today (August 25th, 2017) Let’s Encrypt’s staging environment validation authority (VA) will begin making multiple challenge verification requests from several internet vantage points. A quorum of these requests must succeed for the overall validation to succeed. We intend to bring this “multi-VA” approach to the production environment in the coming weeks. This should not require any changes on the part of ACME clients or end users.


Recently there has been renewed discussion about the feasibility of attacking the Border Gateway Protocol (BGP) that underpins internet routing in order to acquire bogus TLS certificates from Certificate Authorities that issue domain validated (DV) certificates. Researchers presenting at the HotPETS 2017 conference showed one such attack using Let’s Encrypt as an example CA (though the attack is not specific to Let’s Encrypt).

We responded briefly at the time of their presentation to share our perspective and some in-progress work related to validating domains from multiple vantage points as a countermeasure to make these attacks more difficult. We are now at the stage where we are beginning to deploy these countermeasures.

Effective today (Aug 25, 2017) we have enabled the multi-VA countermeasure in our staging environment. All challenges created in the staging environment will receive multiple validation requests. There are three remote VAs and two of the three remote VAs must succeed for the validation to succeed.

Our initial deployment has a lower number of remote VA instances and diverse source networks to allow us to gain experience at a smaller scale before we move to production. We expect to increase the number of remote instances and network perspectives before enabling this countermeasure in production. Per our FAQ we continue to encourage server operators to not attempt to whitelist source addresses since we intend to change these without advance notice.

I will update this API announcement with more details before we enable this feature in production.


Using BGP to Acquire Bogus TLS Certificates
Certificate can not be issued in staging boulder
Certbot webroot timeout issue when request new certificate
Add validation endpoint to json metadata on failed validation
Increasing tls-sni-01 server timeout
The following errors were reported by the server: Timeout but in apache log there is a request standalone fails multiple validation requests (staging multi-va)
FAQ on forum is a bit outdated
"./certbot-auto renew --dry-run" fails with Timeout (but urls are perfectly accessible)
How many http-01 validation calls
Can't test renew certificat