Some certificates cannot be authenticated after upgrade from TLS-SNI-01

#1

Because I need to upgrade from TLS-SNI-01 (like a lot of other people), it upgraded certbot on my Debian Stretch from 0.10 to 0.28 (from stretch-backports).

After running sudo certbot renew --dry-run I get the following errors:

Domain: www.poiu.de
Type: unauthorized
Detail: Invalid response from
http://www.poiu.de/.well-known/acme-challenge/r-25Q90ylClYf_aFHdvB-9seR3FRn1k6-1K3YM83QMQ:
“\n\n404 Not
Found\n\n

Not Found

\n<p”

Domain: poiu.de
Type: unauthorized
Detail: Invalid response from
http://poiu.de/.well-known/acme-challenge/H2EInaa1bgpazWEH3lQkhbrIJzALkoTIiKnoZ8SspOs:
“\n\n404 Not
Found\n\n

Not Found

\n<p”

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.

The interesting thing is that only those 2 domains fail. I have other domains on the same server that an correctly be authenticated. Even other subdomains of the same domain!. I didn’t find any .well-known somewhere (and also rannot remember having created one anywhere).

Can someone help me here, what can be wrong with these 2 domains?

#2

First we’ll need to identify what authenticator Certbot is trying to use for those domains.

What is the contents of this file:

/etc/letsencrypt/renewal/poiu.de.conf

(might be www.poiu.de.conf).

#3

It is

renew_before_expiry = 30 days
version = 0.10.2
archive_dir = /etc/letsencrypt/archive/poiu.de
cert = /etc/letsencrypt/live/poiu.de/cert.pem
privkey = /etc/letsencrypt/live/poiu.de/privkey.pem
chain = /etc/letsencrypt/live/poiu.de/chain.pem
fullchain = /etc/letsencrypt/live/poiu.de/fullchain.pem

Options used in the renewal process

[renewalparams]
authenticator = apache
installer = apache
rsa_key_size = 4096
account = fce8269d8ffdaa664501adaa95c9a4c9

All domains seem to use http:

http-01 challenge for poiu.de
http-01 challenge for www.poiu.de

#4

Thanks. There is most likely some problem with the virtualhosting of that domain (e.g. duplicate ServerName/ServerAliases or too-specific binds, e.g. only for IPv4).

What is the full output of:

apachectl -t -D DUMP_VHOSTS
#5

grepped to only contain entries relevant to poiu

     port 80 namevhost mantis.poiu.de (/etc/apache2/sites-enabled/mantis.poiu.de.conf:1)
     port 80 namevhost poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:1)
             alias www.poiu.de
     port 80 namevhost mad.poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:29)
     port 80 namevhost blog.poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:71)
     port 80 namevhost kilt.poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:112)
     port 80 namevhost apron.poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:127)
     port 80 namevhost fez.poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:142)
     port 443 namevhost mantis.poiu.de (/etc/apache2/sites-enabled/mantis.poiu.de.conf:8)
     port 443 namevhost poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:1)
             alias www.poiu.de
     port 443 namevhost mad.poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:36)
     port 443 namevhost blog.poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:77)
     port 443 namevhost kilt.poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:118)
     port 443 namevhost apron.poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:133)
     port 443 namevhost fez.poiu.de (/etc/apache2/sites-enabled/poiu.de.conf:148)
#6

Well, based on this selective output, it looks fine. Certbot should not be tripping up on that.

Unfortunately it doesn’t include some of the stuff I wanted to see.

If you are able to upload the full output to e.g. https://dpaste.de , you would be able to get a delete link to remove it later.

Otherwise, somebody else might have some bright ideas.

#7

OK. Here is the full output: https://dpaste.de/038L

#8

Thanks. That also looks totally fine :frowning:, so it looks like my suspicion was wrong.

I guess it’s possible that the temporary changes made by Certbot’s Apache authenticator to the VirtualHost (the first one in poiu.de.conf at line 1) don’t work properly.

It seems unlikely for a simple VirtualHost (e.g. no reverse proxying or mod_access or anything like that) - but it would be helpful to see how it is configured.

Something that may help you is the --debug-challenges flag. What it does is pause Certbot’s execution AFTER it modifies your VirtualHost, but before it submits the order to Let’s Encrypt. This way, you will be able to open up poiu.de.conf and see what changes were made, and whether they actually work.

certbot renew --cert-name poiu.de --apache --dry-run --debug-challenges
#9

Interesting. Your suggestion for using --debug-challenges was the right one. It actually did not stop the process, but I had enough time hitting Ctrl-Z to stop execution and investigate the temporary changes.

And I found that the non-working subdomains were the only ones that had HTTP and HTTPS in the same VirtualHost directive:

<VirtualHost *:80 *:443>
  ServerName poiu.de
  ServerAlias www.poiu.de
 …
</VirtualHost>

All other subdomains had them separated and forward all HTTP connections to HTTPS.
I changed it for the failing ones now:

<VirtualHost *:80>
  ServerName poiu.de
  ServerAlias www.poiu.de

  Redirect / https://poiu.de/
</VirtualHost>

<VirtualHost *:443>
  ServerName poiu.de
  ServerAlias www.poiu.de
 …
</VirtualHost>

and now it is working!

Is that a bug in certbot?

Many thanks for your help, _az!

#10

I wouldn’t call it a bug per se, but it’s a weird situation that it should probably detect and explicitly report on. But having the same VirtualHost try to respond on both ports 80 and 443 is almost never a good idea, since Apache doesn’t allow you to selectively enable HTTPS on one port and disable it on the other - you have to have them in separate VirtualHosts for that. (Sometimes it works anyway because another VirtualHost’s configuration takes precedence, and sometimes it doesn’t).

#11

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