Can't create Certificate, DNS Error?

My domain is:

I ran this command: sudo certbot --apache

It produced this output:
root@pi:/# sudo certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?


Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. (http-01): urn:ietf:params:acme:erro r:unauthorized :: The client lacks sufficient authorization :: Invalid response from uaiRpHMCRLBkKg [2a01:aee0:0:4::11]: "\n<html xmlns:og="http://og">\n<head profile="Index of /documents/dcq-html">\n mrcrie94"


My web server is Apache2

The operating system my web server runs on is (include version):
Debian Stretch with Arbian Linux 5.1.12 on an Banana PI m2 Berry

Certbot version 0.28.0

apachectl -S shows following:
root@pi:/var/www/html# apachectl -S
VirtualHost configuration:
*:80 (/etc/apache2/sites-enabled/000-default.conf:1)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
PidFile: "/var/run/apache2/"
User: name="www-data" id=33
Group: name="www-data" id=33

I tried and tried and now im blocked from Letsencypt for some time .___.

FYI: It's an private Webserver, which will be used for a WoL-php-script and a table of content of my servers for my friends (which shows the accessadress for certain games). The Website will only be accessable if logged in my Firewall, but for the ssl config i use portforwarding until its created, after that, the webserver won't be accessable from outside. But the Certificate will be used on several Hardware to delete the "untrusty website" popup...

Hope somebody can help me...


Your website is behind some kind of " redirect service". The Let's Encrypt validation server needs to be able to connect to your webserver directly or redirects using HTTP headers. And not this kind of JavaScript based redirects.

Also note that Let's Encrypt certificates are only valid for 90 days and need to be renewed frequently. For those renewals, it again requires access to your webserver. Why do you even require a certificate if it's for a local server only?


Any idea on how i do that?
My website is registred at, and i "secretly forward" to my private IPv4 on my FW wich use NAT-translation to link it to my bananaPI.

Yeah, I know about the 90 day renewal, but its better than paying more.
I wan't the warning to be removed, so my services need a valid certificate.
(Firewall, PDU, Website, Jitsi-Server...)
The websiteregistration cost me 9€ a year, and that worth for me to let my friends/family have easy access to my Network. Those aren't really into IT, and I want it to be as easy as possible for them.

I save there documents, backups and so on, also if i gather some people to play like Stronghold Crusader or so, they just have to enter instead of my IP adress with a Portnumber to connect to my server.

Your site is totally different in IPv4 and IPv6—you probably realize this already. It seems that the IPv4 version of your site goes directly to your server, while the IPv6 version has easyname wrapping everything with an HTML frame, and then actually loading everything from your IPv4 server. (This is the " redirect service" that @Osiris mentioned which is breaking the validation.)

There is no benefit to this IPv6 frame-wrapping technique, because the end user still connects to your IPv4 server in order to load the content. Since all the site content ends up going over IPv4 anyway, it doesn't make the site more accessible to IPv6 users or less dependent on IPv6 or anything.

However, the frame-wrapping technique does break Let's Encrypt's challenge verification of your site, because Let's Encrypt requires that the content posted in response to the challenges be exactly (and only) a certain token, not some HTML that wraps a link to that token. And Let's Encrypt's validation prefers IPv6 over IPv4, so it always tries the IPv6 version, and then sees the HTML page with the frame loading the IPv4 version, which is not considered a valid response to the challenge.

I believe that you would be better off, in general and also with regard to getting your certificate, if you simply disabled the IPv6 AAAA record for your domain and only used the IPv4 A record. There certainly are ways of doing an IPv6-to-IPv4 forwarding, such as a reverse proxy, which is often done by Content Delivery Networks (CDNs). That may be compatible with Let's Encrypt. But your current service is using a much lower-tech and less-appropriate way of doing this, and that is ending up being actively counterproductive in situations like this.

(The way that they're doing it will also not be compatible with HTTPS at all ... that is, even if you already had your certificate, visitors to your site over IPv6 would always still encounter a certificate error.)

So I would say, get rid of the IPv6 forwarding method you have now, and either operate your site IPv4-only, or get your ISP to offer IPv6 support natively on your connection, or use a tunnel like a Miredo tunnel to get IPv6 support for your server, or use a CDN with a full IPv6-to-IPv4 reverse proxy functionality. Any of these options will probably work to enable you to get your certificate!


It works now!! :slight_smile:

A big Thank you to Osiris and schoen!!!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.