Incorrect validation certificate for tls-sni-01 challenge again and again

Help
1

I have multiple domains in the same cert, tried to renew and got errors on two of them. Followed many threads (like this one: Incorrect validation certificate for challenge) to no avail.

Tried both ./letsencrypt-auto --apache -d my.domain.com as well as certbot, both with and without domain flags (so it ran interactive and found my certs itself)

It produced this output (for two of the 5 domains):
Domain: my.domain.com
Type: unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge.
Requested
23245c1bedde5835280ea61d9a2b4885.e683349e13c12b9069096d14b5fa1a3f.acme.invalid
from 159.203.209.199:443. Received 2 certificate(s), first
certificate had names …(my 5 names here)

My web server is (include version): Server version: Apache/2.4.7 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 16.04

I can login to a root shell on my machine.

2

Can you post your apache configs? Seems like something in there is confusing certbot so that it’s not able to apply the temporary certificates for TLS-SNI-01 to work.

3

I have several virtual hosts, all configured quite similarly (except for the hostnames themselves) and all the other ones re-certified without issue. Also, my apache configs have not changed in months. So it seems unlikely to be apache, is there anything in particular I should be looking for? I can also paste the letsencrypt.log file, which is probably really useful to someone in the know (but I worry about how safe it is to post all that info publicly).

4

And it doesn’t matter if I try to renew individually or all of them at once, I get the same “Failed authorization procedure” error:

Failed authorization procedure. my.domain.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested f2be1bcae8479142dc3c6536dcb64543.88f0f23843e90b9c87b8d686ad766050.acme.invalid from 159.203.209.199:443. Received 2 certificate(s), first certificate had names "my.otherdomain.com"

5

It could also be that some virtual hosts don’t work in IPv6 (and that you’re publishing an IPv6 DNS record).

6

I already checked that one off the list, it is IPv4. But thanks.

7

Well, the Apache configuration and the log from /var/log/letsencrypt would be great for debugging. It can potentially be a Certbot bug which can be revealed by looking at this, because sometimes Certbot doesn’t understand how to parse a particular Apache configuration which is nonetheless treated as valid by Apache.

8

Ok, is there a safe way to share this log with you? Thanks

9

The log doesn’t really contain any sensitive information. To be honest, if your security is reliant on your domain remaining secret, you already have some serious issues. Your domain is publicly listed on the certificate transparency logs every time you have one issued anyway.

10

Ok, here is the latest error log then, thanks.letsencrypt.log.txt (23.7 KB)

11

One other thing I notice on my server are these errors when doing sudo apt-get update:

Ignoring Provides line with DepCompareOp for package python-cffi-backend-api-max
Ignoring Provides line with DepCompareOp for package python-cffi-backend-api-min
Ignoring Provides line with DepCompareOp for package python3-cffi-backend-api-max
Ignoring Provides line with DepCompareOp for package python3-cffi-backend-api-min
Ignoring Provides line with DepCompareOp for package python-cffi-backend-api-max
Ignoring Provides line with DepCompareOp for package python-cffi-backend-api-min
Ignoring Provides line with DepCompareOp for package python3-cffi-backend-api-max
Ignoring Provides line with DepCompareOp for package python3-cffi-backend-api-min

Are they anything possibly that letsencrypt could need to rely on?

12

Well, I fixed this by:

  1. Deleting all certs in /etc/letsencrypt/live
  2. Removing all Apache virtual hosts that were running on port 443 (letsencrypt recreates these in step 3)
  3. Rerunning letsencrypt-auto --apache -d mysite1.mysite.com -d mysite2.mysite.com (etc)

Hope this helps someone else. This was a real nightmare, and I have no idea why it all of a sudden stopped working, but I am glad this fixed it.

13

hi @ssuess

This is not a good solution. Deleting everything and starting from scratch worked in your case but their have been people that have done this and have lost their websites for hours and tried to get help here (posting 6 or 7 “bumps” which everyone ignored)

If you are going to go down the path of starting from scratch then I always suggest you do backups first

Andrei

14

I agree that backups are always important, which is why I always have them. (Perhaps I should have added that as step one). However in my case, I already WAS down because of the failure of the auto renew, and I was not getting or finding a response to my particular problem. So my solution is unfortunately what was necessary for me. I added my steps above because in the other threads I examined that mentioned this exact problem, I did not find any solution that worked for me, and I wanted to provide this to others who might find themselves in a similar situation.

1 Like
15

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