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

Help
21

I am not using the default client. I am using a bash client. But have tried others all with the same effect. The error is exactly what is returned from the server. The certificate that is served if I just use:

openssl s_client -connect my.domain.name:443

Yields a response with:

subject=/CN=my.domain.name
issuer=/CN=my.domain.name

Is there something else I can check? Asserting that my server is serving the wrong certificate and not indicating how one can learn that does not help solve this problem for all only those willing to publish the domain name.

22

The TLS-SNI-01 challenge works by putting a self-signed certificate with a part of the challenge as its CN in it and places this temporary cert in the place of the virtualhost for the requested domain. So the client should have the option to ā€˜swap outā€™ your own self signed certificate with its own temporary oneā€¦ Why this doesnā€™t work is something in the client I thinkā€¦ Perhaps you can contact the developper for that bash client?

1 Like
23

As far as Iā€™m aware none of the bash clients generate / use a self signed cert. They all just use whatever webserver you have running, and make no changes to it during the challenge. Checking through your account and SSL at the moment I canā€™t see any reason for the error. Can you run the script with debug turned on, and paste the latter part of the debug ? ( excluding all the private key and domain key information which would have been earlier ) .

24

Please have a look at the spec how the TLS challenge works and contact the developer of your client directly. You might want to put a link to the opened issue here if your client is hosted on something like GitHub.

25

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.

26

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.

27

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.

28

The "Editorā€™s Copy of the draft is a more readable versionā€¦

29

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

1 Like
30

so, did we come up with a solution?

31

+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.

32

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

33

Successā€¦!!! Iā€™ve just tried again & a new revision of letsencrypt downloaded, ran & generated cert & key ok.

A big thank you to the developersā€¦!!!

34

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.

35

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.

36

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!

37

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.

38

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.

39

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:

40

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.