The client lacks sufficient authorization on subdomains

Help
1

I get the above error while trying to add my subdomains to the same certificate. This works fine when I uncheck the three subdomains however.

Domains: arimil.com, fgo.arimil.com, files.arimil.com, wsdb.arimil.com Error: The client lacks sufficient authorization 2016-01-06 18:16:32,302:INFO:letsencrypt.auth_handler:Cleaning up challenges 2016-01-06 18:16:32,578:DEBUG:letsencrypt.cli:Exiting abnormally: Traceback (most recent call last): File "/root/letsencrypt/venv/bin/letsencrypt", line 9, in <module> load_entry_point('letsencrypt', 'console_scripts', 'letsencrypt')() File "/root/letsencrypt/letsencrypt/cli.py", line 1398, in main return args.func(args, config, plugins) File "/root/letsencrypt/letsencrypt/cli.py", line 559, in run lineage = _auth_from_domains(le_client, config, domains) File "/root/letsencrypt/letsencrypt/cli.py", line 391, in _auth_from_domains new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains) File "/root/letsencrypt/letsencrypt/client.py", line 266, in obtain_certificate return self._obtain_certificate(domains, csr) + (key, csr) File "/root/letsencrypt/letsencrypt/client.py", line 224, in _obtain_certificate authzr = self.auth_handler.get_authorizations(domains) File "/root/letsencrypt/letsencrypt/auth_handler.py", line 84, in get_authorizations self._respond(cont_resp, dv_resp, best_effort) File "/root/letsencrypt/letsencrypt/auth_handler.py", line 142, in _respond self._poll_challenges(chall_update, best_effort) File "/root/letsencrypt/letsencrypt/auth_handler.py", line 204, in _poll_challenges raise errors.FailedChallenges(all_failed_achalls) FailedChallenges: Failed authorization procedure. wsdb.arimil.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found arimil.com, fgo.arimil.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found arimil.com, arimil.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found arimil.com, files.arimil.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found arimil.com

2

That's because currently the HTTPS virtualhost for the domain wsdb.arimil.com is configured with your Let's Encrypt certificate for only the domain arimil.com.

Try disabling the HTTPS host altogether (only serve HTTP) and try the Let's Encrypt client again.

3

OK, doing that has changed the error to the following:

Domains: arimil.com, fgo.arimil.com, files.arimil.com, wsdb.arimil.com Error: The server could not connect to the client to verify the domain 2016-01-06 19:00:43,134:INFO:letsencrypt.auth_handler:Cleaning up challenges 2016-01-06 19:00:43,427:DEBUG:letsencrypt.cli:Exiting abnormally: Traceback (most recent call last): File "/root/letsencrypt/venv/bin/letsencrypt", line 9, in <module> load_entry_point('letsencrypt', 'console_scripts', 'letsencrypt')() File "/root/letsencrypt/letsencrypt/cli.py", line 1398, in main return args.func(args, config, plugins) File "/root/letsencrypt/letsencrypt/cli.py", line 559, in run lineage = _auth_from_domains(le_client, config, domains) File "/root/letsencrypt/letsencrypt/cli.py", line 391, in _auth_from_domains new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains) File "/root/letsencrypt/letsencrypt/client.py", line 266, in obtain_certificate return self._obtain_certificate(domains, csr) + (key, csr) File "/root/letsencrypt/letsencrypt/client.py", line 224, in _obtain_certificate authzr = self.auth_handler.get_authorizations(domains) File "/root/letsencrypt/letsencrypt/auth_handler.py", line 84, in get_authorizations self._respond(cont_resp, dv_resp, best_effort) File "/root/letsencrypt/letsencrypt/auth_handler.py", line 142, in _respond self._poll_challenges(chall_update, best_effort) File "/root/letsencrypt/letsencrypt/auth_handler.py", line 204, in _poll_challenges raise errors.FailedChallenges(all_failed_achalls) FailedChallenges: Failed authorization procedure. arimil.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge, wsdb.arimil.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge, files.arimil.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge, fgo.arimil.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge

4

OK, I was hoping the client would use the http-01 challenge, but alas…

Then you’ll have to generate a self signed certificate for all your domains. Quite easy with OpenSSL (note: this will overwrite any cert.pem and privkey.pem in the current directory):

openssl req -new -sha256 \
    -newkey rsa -keyout privkey.pem \
    -days 365 -nodes -x509 \
    -subj "/CN=arimil.com" \
    -extensions SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "[SAN]\nsubjectAltName=DNS:arimil.com,DNS:fgo.arimil.com,DNS:files.arimil.com,DNS:wsdb.arimil.com")) \
    -out cert.pem

(Assuming your default openssl.cnf is located at /etc/ssl/)

Then you can use this self signed certificate (privkey.pem and cert.pem in the directory you ran the above command) temporary in Apache so the Let’s Encrypt client will accept all domain challenges. Ofcourse, in that (short) period, all normal clients will not accept the certificate, as it is self signed. But as soon as your Let’s Encrypt client has succesfully run and has generated the certificate, you can replace it.

5

In that case I’d rather just not use SSL than use a self-signed certificate that tells everyone my domain is trying to distribute malicious content and force them to add an exception. Thanks anyway.

6

You don’t understand. The self signed certificate is temporary (like it says in my post), only for the Let’s Encrypt challenge to succeed.

After that, you’ll get a working Let’s Encrypt certificate and you can replace the self signed certificate with the Let’s Encrypt certificate.

I’ve edited my post to make it more clear. Ofcourse the goal is to get a working Let’s Encrypt certificate. I assumed that was obvious…

7

I’ve generated a privkey.pem and cert.pem like advised above. I then replaced the keys that were previously generated in /etc/letsencrypt/archive/arimil.com with the self-signed cert. I reran the letsencrypt installer and was advised that a certificate with all listed domains already exists. I chose to reinstall the certificate (choosing the renew the certificate caused the process to fail). The process finished however going to https://www.ssllabs.com/ssltest/analyze.html?d=arimil.com it seems the certificate is still considered self-signed.

The same happens on all subdomains.

Here’s the log from trying to renew the cert:

Domains: arimil.com, fgo.arimil.com, files.arimil.com, wsdb.arimil.com Error: The client lacks sufficient authorization 2016-01-06 21:42:30,173:INFO:letsencrypt.auth_handler:Cleaning up challenges 2016-01-06 21:42:30,450:DEBUG:letsencrypt.cli:Exiting abnormally: Traceback (most recent call last): File "/root/letsencrypt/venv/bin/letsencrypt", line 9, in <module> load_entry_point('letsencrypt', 'console_scripts', 'letsencrypt')() File "/root/letsencrypt/letsencrypt/cli.py", line 1398, in main return args.func(args, config, plugins) File "/root/letsencrypt/letsencrypt/cli.py", line 559, in run lineage = _auth_from_domains(le_client, config, domains) File "/root/letsencrypt/letsencrypt/cli.py", line 391, in _auth_from_domains new_certr, new_chain, new_key, _ = le_client.obtain_certificate(domains) File "/root/letsencrypt/letsencrypt/client.py", line 266, in obtain_certificate return self._obtain_certificate(domains, csr) + (key, csr) File "/root/letsencrypt/letsencrypt/client.py", line 224, in _obtain_certificate authzr = self.auth_handler.get_authorizations(domains) File "/root/letsencrypt/letsencrypt/auth_handler.py", line 84, in get_authorizations self._respond(cont_resp, dv_resp, best_effort) File "/root/letsencrypt/letsencrypt/auth_handler.py", line 142, in _respond self._poll_challenges(chall_update, best_effort) File "/root/letsencrypt/letsencrypt/auth_handler.py", line 204, in _poll_challenges raise errors.FailedChallenges(all_failed_achalls) FailedChallenges: Failed authorization procedure. files.arimil.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found arimil.com, fgo.arimil.com, files.arimil.com, wsdb.arimil.com, fgo.arimil.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found arimil.com, fgo.arimil.com, files.arimil.com, wsdb.arimil.com, wsdb.arimil.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found arimil.com, fgo.arimil.com, files.arimil.com, wsdb.arimil.com, arimil.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Correct zName not found for TLS SNI challenge. Found arimil.com, fgo.arimil.com, files.arimil.com, wsdb.arimil.com

8

Successful without an error this time? Did you reload your Apache after Let's Encrypt finished? Does your Apache configuration file point to the right cert.pem, chain.pem and privkey.pem?

At the moment your server doesn't serve TLS content on port 443, but normal HTTP.. So that's kinda strange..

9

Yeah I disabled it when it was giving cert errors.

I've reenabled SSL without the redirect on the primary domain (I didn't add it for the add the vhosts for the subdomain but they are the same).

	SSLCertificateFile /etc/letsencrypt/live/arimil.com/cert.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/arimil.com/privkey.pem
	SSLCertificateChainFile /etc/letsencrypt/live/arimil.com/chain.pem

Is the cert that it links to which is a link to

/etc/letsencrypt/archive/arimil.com/cert1.pem

The other files here are the previous key that I made a backup of and privkey1.pem chain1.pem and fullchain1.pem. Which are the only keys.

If you go to https://arimil.com you can now see that it's still giving the self-signed key even after I asked it to reacquire.

10

Then you still didn’t get a successful letsencrypt client certificate? Only errors? Because it shouldn’t give a zName-error this time… Other errors, sure, could be… But no zName :stuck_out_tongue:

11

Let’s Encrypt adds a temporary vhost to your apache config in order to solve the tls-sni-01 challenge. For some reason, apache does not use this vhost when Let’s Encrypt is sending the request using the tls-sni-01 challenge host, but rather uses your other existing vhost(s).

I’m not really sure what could be interfering with the temporary vhost as I’m not familiar with how exactly apache picks them. One thing I would look at is whether any of your existing SSL vhosts are defined “too broad”. Look into removing wildcards and such and try again.

What is your OS and version?

12

A server restart still uses the self-signed certificate, there were no errors.

[code]2016-01-07 01:33:28,966:DEBUG:letsencrypt.cli:Root logging level set at 30
2016-01-07 01:33:28,967:INFO:letsencrypt.cli:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2016-01-07 01:33:28,967:DEBUG:letsencrypt.cli:letsencrypt version: 0.2.0.dev0
2016-01-07 01:33:28,967:DEBUG:letsencrypt.cli:Arguments:
2016-01-07 01:33:28,967:DEBUG:letsencrypt.cli:Discovered plugins: PluginsRegistry(PluginEntryPoint#nginx,PluginEntryPoint#standalone,PluginEntryPoint#manual,PluginEntryPoint#webroot,PluginEntryPoint#apache,PluginEntryPoint#null)
2016-01-07 01:33:28,973:DEBUG:letsencrypt.cli:Requested authenticator None and installer None
2016-01-07 01:33:29,394:DEBUG:letsencrypt.plugins.disco:No installation (PluginEntryPoint#nginx):
Traceback (most recent call last):
File "/root/letsencrypt/letsencrypt/plugins/disco.py", line 103, in prepare
self._initialized.prepare()
File "/root/letsencrypt/letsencrypt-nginx/letsencrypt_nginx/configurator.py", line 112, in prepare
raise errors.NoInstallationError
NoInstallationError
2016-01-07 01:33:29,395:DEBUG:letsencrypt.display.ops:Single candidate plugin: * apache
Description: Apache Web Server - Alpha
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: apache = letsencrypt_apache.configurator:ApacheConfigurator
Initialized: <letsencrypt_apache.configurator.ApacheConfigurator object at 0x38fe910>
Prep: True
2016-01-07 01:33:29,396:DEBUG:letsencrypt.cli:Selected authenticator <letsencrypt_apache.configurator.ApacheConfigurator object at 0x38fe910> and installer <letsencrypt_apache.configurator.ApacheConfigurator object at 0x38fe910>
2016-01-07 01:33:30,689:DEBUG:letsencrypt.cli:Picked account: <Account(45ece8812be80b94e6ec492e01ee8071)>
2016-01-07 01:33:30,690:DEBUG:root:Sending GET request to https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {}
2016-01-07 01:33:30,697:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-01-07 01:33:31,268:DEBUG:requests.packages.urllib3.connectionpool:"GET /directory HTTP/1.1" 200 263
2016-01-07 01:33:31,271:DEBUG:root:Received <Response [200]>. Headers: {'Content-Length': '263', 'Expires': 'Thu, 07 Jan 2016 01:33:31 GMT', 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Thu, 07 Jan 2016 01:33:31 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', 'Replay-Nonce': '_5CwYOYcPJkJABmObaMrao6XEh-Tv19PHphXOQP27Nc'}. Content: '{"new-authz":"https://acme-v01.api.letsencrypt.org/acme/new-authz","new-cert":"https://acme-v01.api.letsencrypt.org/acme/new-cert","new-reg":"https://acme-v01.api.letsencrypt.org/acme/new-reg","revoke-cert":"https://acme-v01.api.letsencrypt.org/acme/revoke-cert"}'
2016-01-07 01:33:31,273:DEBUG:acme.client:Received response <Response [200]> (headers: {'Content-Length': '263', 'Expires': 'Thu, 07 Jan 2016 01:33:31 GMT', 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Thu, 07 Jan 2016 01:33:31 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', 'Replay-Nonce': '_5CwYOYcPJkJABmObaMrao6XEh-Tv19PHphXOQP27Nc'}): '{"new-authz":"https://acme-v01.api.letsencrypt.org/acme/new-authz","new-cert":"https://acme-v01.api.letsencrypt.org/acme/new-cert","new-reg":"https://acme-v01.api.letsencrypt.org/acme/new-reg","revoke-cert":"https://acme-v01.api.letsencrypt.org/acme/revoke-cert"}'
2016-01-07 01:33:32,293:INFO:letsencrypt_apache.configurator:Deploying Certificate to VirtualHost /etc/apache2/sites-available/files-le-ssl.conf
2016-01-07 01:33:32,293:DEBUG:letsencrypt_apache.configurator:Apache version is 2.2.22
2016-01-07 01:33:32,413:INFO:letsencrypt_apache.configurator:Deploying Certificate to VirtualHost /etc/apache2/sites-available/wsdb-le-ssl.conf
2016-01-07 01:33:32,413:DEBUG:letsencrypt_apache.configurator:Apache version is 2.2.22
2016-01-07 01:33:32,531:INFO:letsencrypt_apache.configurator:Deploying Certificate to VirtualHost /etc/apache2/sites-available/fgo-le-ssl.conf
2016-01-07 01:33:32,532:DEBUG:letsencrypt_apache.configurator:Apache version is 2.2.22
2016-01-07 01:33:32,649:INFO:letsencrypt_apache.configurator:Deploying Certificate to VirtualHost /etc/apache2/sites-available/arimil-le-ssl.conf
2016-01-07 01:33:32,650:DEBUG:letsencrypt_apache.configurator:Apache version is 2.2.22
2016-01-07 01:33:57,047:INFO:letsencrypt.reporter:Reporting to user: If you like Let's Encrypt, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: Donate - Let's Encrypt
Donating to EFF: https://eff.org/donate-le[/code]

Debian 7.9, Apache 2.2.22

I added wildcards to the virtualhost lines because apache ignores the files and redirects all the subdomains to arimil.com if they contain the domain like letsencrypt outputs them.

<VirtualHost *:443>

instead of

<VirtualHost arimil.com:443>

The latter is invalid and apache will output errors and it causes routing issues.

13

Well, if the client reports a “Congratulations”, you should have a valid certificate somewhere in /etc/letsencrypt/

You could check every cert.pem in the directories with openssl x509 -noout -text -in cert.pem and look at the Issuer as well as the X509v3 Subject Alternative Name information. (Because you already have an old Let’s Encrypt certificate without the other subdomains in the SAN you shouldn’t jump for joy if you find the old certificate ;))

It would have been better if you had put the self signed certificates outside the /etc/letsencrypt/ directory for clearity sake IMHO.

@pfg I don’t know why the client fails the tls-sni-01 challenge even without HTTPS VirtualHosts, but in the mean time a self signed certificate does the trick to generate a LE certificate :slightly_smiling:

14

This might be the reason you're still seeing your self-signed certificates. The files created in /etc/letsencrypt/live/example.com/ are just symbolic links to the actual cert and key files. I'm not sure the client is able to handle cases where those symlinks were changed or replaced by actual files; those files shouldn't really be modified manually. I would suggest deleting them and re-running letsencrypt; if that doesn't work, you could try manually recreating the symlinks. /etc/letsencrypt/live/example.com/cert.pem should point to /etc/letsencrypt/archive/example.com/cert<N>.pem, etc. <N> is probably 1 if you only created one certificate so far; take a look in the folder and simply pick the highest number.

15

We don't want @Renari to hit any rate limits now do we? :wink: I would recommend checking the /archive/ directory manually and fixing it manually..

16

Sure, but manually messing with files in /etc/letsencrypt caused this issue in the first place. He’s successfully generated one or two certificates so far, one more won’t hurt. --staging is still an option if rate limits are a concern. :wink:

17

These still are symbolic links, linking to the very location you specified. I tried removing them and then letsencrypt outputs

Action 'configtest' failed. The Apache error log may have more information. Syntax error on line 33 of /etc/apache2/sites-enabled/arimil-le-ssl.conf: SSLCertificateFile: file '/etc/letsencrypt/live/arimil.com/cert.pem' does not exist or is empty

I have since recreated the symlinks and there is in-fact only 1 cert in /etc/letsencrypt/archive/arimil.com this is where I copied the self-signed cert when rerunning letsencrypt.

18

And in other directories in /archive/? Could you run find /etc/letsencrypt/archive/ to get a full listing of files? Because it could be that the client choose another domain as its “main” domain.

19

I’m not sure what happened there, but if you don’t have any Let’s Encrypt-issued certificates in /etc/letsencrypt/archive/ (check other directories in there too!), you’ll definitely need to re-run the client. It’s probably best if you first delete the self-signed certs (both the symlinks and archive files) so the same thing doesn’t happen again.

20

find /etc/letsencrypt/archive/ /etc/letsencrypt/archive/ /etc/letsencrypt/archive/arimil.com /etc/letsencrypt/archive/arimil.com/privkey1.pem.bak /etc/letsencrypt/archive/arimil.com/fullchain1.pem /etc/letsencrypt/archive/arimil.com/cert1.pem /etc/letsencrypt/archive/arimil.com/privkey1.pem /etc/letsencrypt/archive/arimil.com/cert1.pem.bak /etc/letsencrypt/archive/arimil.com/chain1.pem

The two .bak files are the signed certificate that was working for the primary domain only. I overwrote them with the self-signed one to get past the error as instructed. However it doesn’t seem they are being changed.