Lets Encrypt certbot failed to authenticate domain with mixed DNS records (AKA do not forget IPv6 records)

Written by - 0 comments

Published on - Listed in Internet TLS SSL Security Linux


Lets Encrypt logo

When using certbot to automatically create certificates from Let's Encrypt, this usually works very well. However the following error can lead to some hair-tearing:

root@debian:~# certbot -n certonly --webroot -w /var/www/letsencrypt -d example.com -d www.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for example.com and www.example.com

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: example.com
  Type:   unauthorized
  Detail: The key authorization file from the server did not match this challenge. Expected "Aq9xXQ2tIjoT3tMr7oE9Yxu4njyxFHMfREqcSmW1EhA.vVjrAf3C5tIJv1Q91oTwu4uKjgxdZwm2lY9YhIOvq2Y" (got "")

  Domain: www.example.com
  Type:   unauthorized
  Detail: The key authorization file from the server did not match this challenge. Expected "1wh7AbwSkEOusY6X9aTHUENQkZs8vgCEAHO69u0yyU8.vVjrAf3C5tIJv1Q91oTwu4uKjgxdZwm2lY9YhIOvq2Y" (got "")

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

According to the output, it looks as if the webroot-path was wrong or that certbot did not create the authorization file in the correct path.

But in this situation it was a completely different reason: A mix of IPv4 and IPv6 DNS records.

This particular domain had both IPv4 and IPv6 addresses. Yet only the IPv4 addresses were changed to point to this new Debian server.

Let's Encrypt uses IPv6 by default (at least from what I've seen in the past years). The old IPv6 entries still pointed to the old environment. Hence the traffic actually never landed on our Debian server to retrieve the authorization file via HTTP.


More recent articles:

RSS feed

Blog Tags:

  AWS   Android   Ansible   Apache   Apple   Atlassian   BSD   Backup   Bash   Bluecoat   CMS   Chef   Cloud   Coding   Consul   Containers   CouchDB   DB   DNS   Database   Databases   Docker   ELK   Elasticsearch   Filebeat   FreeBSD   Galera   Git   GlusterFS   Grafana   Graphics   HAProxy   HTML   Hacks   Hardware   Icinga   Influx   Internet   Java   KVM   Kibana   Kodi   Kubernetes   LVM   LXC   Linux   Logstash   Mac   Macintosh   Mail   MariaDB   Minio   MongoDB   Monitoring   Multimedia   MySQL   NFS   Nagios   Network   Nginx   OSSEC   OTRS   Observability   Office   OpenSearch   PGSQL   PHP   Perl   Personal   PostgreSQL   Postgres   PowerDNS   Proxmox   Proxy   Python   Rancher   Rant   Redis   Roundcube   SSL   Samba   Seafile   Security   Shell   SmartOS   Solaris   Surveillance   Systemd   TLS   Tomcat   Ubuntu   Unix   VMWare   VMware   Varnish   Virtualization   Windows   Wireless   Wordpress   Wyse   ZFS   Zoneminder