Failed authorization procedure - (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found

1

Hi

Just want to test creating a cert for my apache configuration :

./letsencrypt-auto certonly --standalone --email maintenance@365it.fr -d www.365it.fr --debug
[EDIT : Same probleme with apache plugin]

But i have this problem :

FailedChallenges: Failed authorization procedure. www.365it.fr (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found

Problem with webroot method :

FailedChallenges: Failed authorization procedure. www.365it.fr (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.365it.fr/.well-known/acme-challenge/1He082lDGs_2IVSC4qxOotttm5RJdm-X2q6SaHoaDSI [46.29.127.137]: 404

How to correct this ?
(For information, i have a reverse proxy in front of the apache that deserve my website)

2

The webroot-problem I can’t answer, because you haven’t specified the command line for the client.

But for your zName-problem: the TLS server behind www.365it.fr is serving a certificate with a CommonName of “Tomcat Demo Root CA.local”, not www.365it.fr. Also, there are no subjectAltNames in the certificate. As those two don’t match, the ACME server will refuse your request.
You should generate a self-signed certificate with either www.365it.fr as the Common Name (CN) or add it to the subjectAltName list.
You are aware you can also add 365it.fr to the list of domains? Just add another -d 365it.fr to the options of the client. If you’d want this, you’d also have to add that hostname to your self-signed certificate (in the subjectAltName list) for the authentication to work ofcourse.

3

ok thanks, so the reverse front proxy is the source of my problem.

I will do this… Thanks.

I was not aware that there’s must be a self signed certificate to create a certificate with letsencrypt.

4

I found HAProxy to be perfect as an SSL frontend, because you can let it handle SSL termination for certain SNI hostnames and forward other SNI names to backends that handle it themselves. This allows you to forward *.acme.invalid to the LE client without disruption to your main SSL sites, which HAProxy terminates for you.