My client answers:

root@XXX/letsencrypt ./letsencrypt-auto run -d domain.de
Updating letsencrypt and virtual environment dependencies…
Running with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt run -d domain.de
Failed authorization procedure. domain.de (tls-sni-01):
-urn:acme:error:unauthorized :: The client lacks sufficient authorization ::
-Correct zName not found for TLS SNI challenge. Found


  • The following ‘urn:acme:error:unauthorized’ errors were reported by the server:
    Domains: domain.de
    Error: The client lacks sufficient authorization

I don’t understand my client’s message and appreciate any help :smile:

The ACME server tries to make a HTTPS connection to your server. You’ve probably got a (self signed) certificate which has another CommonName in it without your domain in the subjectAltNames. The current certificate probably has another domain name, which the ACME server doesn’t accept.

Hello @Osiris,

Keep in mind that the other day I tested this situation ;), a redirect from http to https with a self-signed certificate that was not valid for the domain and the letsencrypt client gave an Error but created the certificate:


I don’t know how and why, but the error “Correct zName not found” suggests something is wrong with the certificate. And I’ve seen other users who could fix this with the correct self signed certificate. But as always: YMMV :stuck_out_tongue:

Maybe this issue is not happening in staging but it does in normal boulder… who knows :wink:

Staging and live Boulder versions are different (staging = more recent code), so that’s a good possibility.

I had this issue. I realized that my domain (example.com) was pointing to the right IP (xxx.xxx,xxx,xxx) but port forwarding (443) was setup to point to a different client than the one I was running Let’s Encrypt. Once I fixed this issue, I was able to generate the certificate.

Also, I would strongly recommend you run your command with --test-cert on to avoid running into limits while you figure it out.