How to resolve the "Correct zName not found for TLS SNI challenge" error when i try renew certificate

The TLS challenge isn’t failing it is on the Let’s Encrypt side. The cert works fine and behaves as expected for other services it is only failing in the sense that Let’s Encrypt doesn’t accept the cert which is odd because the only (all be it very out dated) documentation indicates that a self signed certificate should work.

Do you have current documentation on how the TLS-SNI-01 challenge works? It isn’t part of the “ACME Documentation” at all at this point and there are comments in this forum to the effect that there won’t be till the standard is out of draft making it rather difficult to implement.

I managed to find some documentation on what exactly needs to be added for tls-sni-01. The client does not generate the self signed certificate so it fails to add the necessary validation to the header. The error returned by Let’s Encrypt is very confusing and should be updated.

The documentation on the acme protocol as it stands can be found here:

To my knowledge there is no “no sudo” style client that can use tls-sni-01 since they would need to install a certificate on the fly requiring sudo.

The "Editor’s Copy of the draft is a more readable version…

I opened an issue, you may want to comment and add further details there: https://github.com/letsencrypt/boulder/issues/1464

1 Like

so, did we come up with a solution?

+1

I’ve researched this error message extensively & I’ve tried probably everything that’s been recommended
without success. Mind you, I’m no guru when it comes to this stuff.

As far as I’m concerned, my CName is correct & my DNS A record is correct. From my reading
of the problem these two are “critical”.

I will keep on searching for an answer.

In my case, you can not find a solution.
Unfortunately I had to stop using letsencrypt

Success…!!! I’ve just tried again & a new revision of letsencrypt downloaded, ran & generated cert & key ok.

A big thank you to the developers…!!!

I’ve got the same error message and couldn’t solve it yesterday. But finally I’ve renewed my certificate:)

Error message:

$ docker run -it --rm -p 1086:80 -p 1087:443 --name letsencrypt -v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" quay.io/letsencrypt/letsencrypt:latest renew
Processing /etc/letsencrypt/renewal/drem.jp.conf
2016-03-15 02:57:20,087:WARNING:letsencrypt.cli:Attempting to renew cert from /etc/letsencrypt/renewal/drem.jp.conf produced an unexpected error: Failed authorization procedure. drem.jp (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization
 :: Correct zName not found for TLS SNI challenge. Found 'drem.jp'. Skipping.

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

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

   Domain: drem.jp
   Type:   unauthorized
   Detail: Correct zName not found for TLS SNI challenge. Found
   'drem.jp'

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

I think that this message was a misleading in my case.

Solution: Using webroot

nginx.conf:

  server {
    listen 80;
    server_name drem.jp;

    # letsencrypt
    location /.well-known/acme-challenge {
      root /tmp/letsencrypt;
    }

    location / {
      return 301 https://$server_name$request_uri;
    }
  }

I didn’t change DNS and other network settings. Then I executed the following command on the same host.

$ docker run -it --rm --name letsencrypt -v "/etc/letsencrypt:/etc/letsencrypt" -v "/var/lib/letsencrypt:/var/lib/letsencrypt" -v "/tmp/letsencrypt:/tmp/letsencrypt" quay.io/letsencrypt/letsencrypt:latest certonly
 -a webroot --webroot-path=/tmp/letsencrypt -d drem.jp

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/drem.jp/fullchain.pem. Your cert will expire
   on 2016-06-14. To obtain a new version of the certificate in the
   future, simply run Let's Encrypt again.
 - If you like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

I didn’t know the cause, but I’ve solve it by using webroot. I hope my case will help others.

It’s not really “solved”. The webroot uses the http-01 challenge, while your previous error was caused by the tlssni-01 challenge. So in the end it might be solved for you, but the error for the tlssni-01 challenge probably would still cause problems, when used.

This is justa quick note without proper analysis.
We recived:
Detail: Correct zName not found for TLS SNI challenge. Found ''
for all domains in /etc/apache2/sites-available/reverseproxy-ssl.conf except the last one…

By moving a domain to the end of /etc/apache2/sites-available/reverseproxy-ssl.conf we could generate certificates.

After generating a certs for a domain the reverseproxy-ssl.conf file got updated with one minor error:
The first virtual host declaration recieved a ServerAlias pointing out the last virtual host declaration.
After removing theese ServerAlias declaration our sites are working as expected with letsencrypt certs.

Hope this helps some of you guys!

The client currently doesn’t properly support apache configurations with multiple VirtualHosts per file. What @hans.hook is describing is probably a side effect of that.

That seems unrelated, since I have split up my domain into four .conf files and still run into pain.

I have read all of the stuff here and I have only understood half of it or what I understood proved to be no sulution. I am wondering why

./letsencrypt-auto certonly --webroot -w /.../mw -d example.org -d www.example.org

creates the certs without isssues and

./letsencrypt-auto certonly --apache --renew-by-default -d example.org -d www.example.org --dry-run

cheerfully fails. There is something in the water or I am being silly again.

I thought the certonly flag would conflict with the apache flag? It’s not “only” a cert if you’re also getting it to alter your Apache config, surely.

I just checked, and according to the documentation, “certonly” works with the standalone and webroot plugins. If you want to use the apache plugin, leave out the “certonly” :wink:

Indeed certonly and apache conflict but instead of informing about this I get “Correct zName not found for TLS SNI challenge” + two other error messages I forgot in the meantime.

I suppose all of you already checked this. The same error raised to me during the renewal process. I redirected the traffic from 443 to 8443 (with iptables). The solution was to remove the entry from iptables and stop the tomcat, then executing the renewal process worked like a charm. The script looks like this.

/etc/init.d/tomcat7 stop
iptables -t nat -D PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443

$letsencryptdir/letsencrypt-auto renew --standalone --standalone-supported-challenges tls-sni-01 --renew-by-default --email <my_email> --verbose --text --agree-tos

iptables -t nat -I PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443
/etc/init.d/tomcat7 start

I’m getting this exact same error, when trying to renew my standalone cert. The DNS A record is correct…

To fix these errors, please make sure that your domain name was entered correctly and the DNS A record(s) for that domain contain(s) the right IP address.
2016-05-12 14:34:20,851:INFO:letsencrypt.auth_handler:Cleaning up challenges
Failed authorization procedure. referendum.ml (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found 'www.referendum.ml, referendum.ml', www.referendum.ml (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found 'www.referendum.ml, referendum.ml'

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

   Domain: referendum.ml
   Type:   unauthorized
   Detail: Correct zName not found for TLS SNI challenge. Found
   'www.referendum.ml, referendum.ml'

   Domain: www.referendum.ml
   Type:   unauthorized
   Detail: Correct zName not found for TLS SNI challenge. Found
   'www.referendum.ml, referendum.ml'

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

Hi

I resolved this issue by disabling IPv6 on my Ubuntu 14.04 machine for Apache 2.4 as my server does not have a real IPv6 address.

To accomplish this, I explicitly set the IP address in /etc/apache2/ports.conf
Listen <IP>:80 Listen <IP>:443

and in all vhosts:
<VirtualHost <IP>:80>

instead of
<VirtualHost *:80>

After these changes, netstat -lnp | egrep ":443|:80" shows tcp in the first column instead of tcp6.

Then, the cerbot renew worked like a charm.

Best regards
Frederick Thomssen

1 Like

Fathomssen solution is what solved the issue for me using Apache2 with Debian. I didn’t have IPv6 enabled, but still ran into the issue when trying to renew my cert because my IP were not defined properly. One was using the loopback and the other *.

Switched the config to use the actual IP and everything worked perfectly

Thank you!

1 Like