Error renewing over tls-sni-01, "Incorrect validation certificate for tls-sni-01 challenge"

Hey, I’m trying to renew a certificate that I installed on my HAProxy load balancer. I installed it no problem, issued a few forced renewals before going live and it worked, I issued multiple certificates initially no problem. My automatic renewal cron (runs script below) has been failing and I didn’t realise until just now

I had originally installed certbot using apt-get, but read that 0.22.2 had a renewal issue with tls. Installed certbot-auto which installed 0.25.1.

Nothing has changed in my HAProxy config since the initial renewal.

Here’s the renewal config:

$ cat /etc/letsencrypt/renewal/onlinedegrees.und.edu.conf

# renew_before_expiry = 30 days
version = 0.22.2
archive_dir = /etc/letsencrypt/archive/onlinedegrees.und.edu
cert = /etc/letsencrypt/live/onlinedegrees.und.edu/cert.pem
privkey = /etc/letsencrypt/live/onlinedegrees.und.edu/privkey.pem
chain = /etc/letsencrypt/live/onlinedegrees.und.edu/chain.pem
fullchain = /etc/letsencrypt/live/onlinedegrees.und.edu/fullchain.pem

# Options used in the renewal process
[renewalparams]
installer = None
http01_port = 8888
account = <snip>
authenticator = standalone
tls_sni_01_port = 8888

My domain is:
onlinedegrees.und.edu

I ran this command:

#!/usr/bin/env bash

# Renew the certificate
certbot-auto renew --force-renewal --tls-sni-01-port=8888

# Concatenate new cert files, with less output (avoiding the use tee and its output to stdout)
bash -c "cat /etc/letsencrypt/live/onlinedegrees.und.edu/fullchain.pem /etc/letsencrypt/live/onlinedegrees.und.edu/privkey.pem > /etc/ssl/onlinedegrees.und.edu/onlinedegrees.und.edu.pem"

# Reload  HAProxy
#service hapee-1.7-lb reload

It produced this output:

$ ./update-certs.sh
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/onlinedegrees.und.edu.conf
-------------------------------------------------------------------------------
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for onlinedegrees.und.edu
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (onlinedegrees.und.edu) from /etc/letsencrypt/renewal/onlinedegrees.und.edu.conf produced an unexpected error: Failed authorization procedure. onlinedegrees.und.edu (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 24055e95bf9e64eb66e74668d5323fd2.363bc3d71dbb723d983d0eaae84c71bb.acme.invalid from 34.231.55.226:443. Received 2 certificate(s), first certificate had names "onlinedegrees.und.edu". Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/onlinedegrees.und.edu/fullchain.pem (failure)

-------------------------------------------------------------------------------

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/onlinedegrees.und.edu/fullchain.pem (failure)
-------------------------------------------------------------------------------
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: onlinedegrees.und.edu
   Type:   unauthorized
   Detail: Incorrect validation certificate for tls-sni-01 challenge.
   Requested
   24055e95bf9e64eb66e74668d5323fd2.363bc3d71dbb723d983d0eaae84c71bb.acme.invalid
   from 34.231.55.226:443. Received 2 certificate(s), first
   certificate had names "onlinedegrees.und.edu"

   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.

My web server is (include version):

HaProxy / hapee-1.7-lb.service - HAPEE Load Balancer

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

Ubuntu 16.04.3 LTS

My hosting provider, if applicable, is:

EC2

I can login to a root shell on my machine (yes or no, or I don’t know):

Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

No

Hi @kingsloi,

You’ve installed the certificate on the load balancer, but the Certbot client that you’re running is on another machine which is not the load balancer? Was the load balancer not originally in place when you first obtained this certificate?

Hey @schoen, no, I had obtained the certificate on the same load balancer that I’m also trying to renew it on, below is my HAProxy config:

bind *:443 ssl crt /etc/ssl/onlinedegrees.und.edu/onlinedegrees.und.edu.pem
reqadd X-Forwarded-Proto:\ https

...

backend be-letsencrypt
    server letsencrypt 127.0.0.1:8888

...

# LetsEncrypt
acl letsencrypt-acl path_beg /.well-known/acme-challenge/
use_backend be-letsencrypt if letsencrypt-acl

Oh, I see, and you were using --standalone. So at that time the bind *:443 was probably not yet in place.

The --standalone method expects that there is nothing listening on port 443, so if you want to renew with this method, you would need to temporarily stop the HAProxy instance before initiating the renewal. You could automate this with --pre-hook and --post-hook options in Certbot.

If you have inbound port 80 available, it would also be possible to switch the authentication over to port 80 (most likely using the --preferred-challenges http option in Certbot). In this case you wouldn’t need to stop HAProxy (unless it’s also listening on port 80).

There are certainly also other methods too, but these options would entail the smallest change to your existing setup.

Ah, I see that now. Traffic wasn’t hitting that server at the time I was setting it up, so that explains that. However, what’s strange is that I followed instructions from here: https://serversforhackers.com/c/letsencrypt-with-haproxy and they’ve (apparently) set it up that way.

The only difference is that I’m forcing https with:
redirect scheme https code 301 if !{ ssl_fc }

Is it possible to still enforce https and use the --preferred-challenges http? I guess that’s a case of setting up a whitelist for http/80 for /.well-known

--standalone literally requires one or the other ports to be free, regardless of how the listeners would be configured. However --webroot can work if there's already a listener, as long as there's a place from which it can serve static files.

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