Renewal fails: The client lacks sufficient authorization

Help
1

Please fill out the fields below so we can help you better.

My domain is: dbs9.dx30.net SNI (5 domains)

I ran this command: letsencrypt-auto renew --dry-run --agree-tos --apache (and many variations)

It produced this output:

Processing /etc/letsencrypt/renewal/dbs9.dx30.net.conf

Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for dbs9.dx30.net
tls-sni-01 challenge for www.harshawtrane.com
tls-sni-01 challenge for www.oksanamastersusa.com
tls-sni-01 challenge for www.stseducation-us.com
tls-sni-01 challenge for www.thecenteronline.org
Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.
Falling back to default vhost *:443…
Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.
Falling back to default vhost *:443…
Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.
Falling back to default vhost *:443…
Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.
Falling back to default vhost *:443…
Encountered vhost ambiguity but unable to ask for user guidance in non-interactive mode. Currently Certbot needs each vhost to be in its own conf file, and may need vhosts to be explicitly labelled with ServerName or ServerAlias directories.
Falling back to default vhost *:443…
Waiting for verification…
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/dbs9.dx30.net.conf produced an unexpected error: Failed authorization procedure. dbs9.dx30.net (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 7555e3241e782cfe623d9989cabc9c3e.fb82ffedf865b0d88f79a2f29a3cbd04.acme.invalid from 23.253.213.249:443. Received 2 certificate(s), first certificate had names “dbs9.dx30.net, www.harshawtrane.com, www.oksanamastersusa.com, www.stseducation-us.com, www.thecenteronline.org”, www.harshawtrane.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 1dc2ed1a55939205f36996b763827285.9aadb37c9d0f7e5fe110cd019960fb59.acme.invalid from 23.253.213.249:443. Received 2 certificate(s), first certificate had names “dbs9.dx30.net, www.harshawtrane.com, www.oksanamastersusa.com, www.stseducation-us.com, www.thecenteronline.org”, www.oksanamastersusa.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested a3e0e8e97ad89ec4334af45d02c779d2.969bccc166bc7092ab4e5ca7371f8ef0.acme.invalid from 23.253.213.249:443. Received 2 certificate(s), first certificate had names “dbs9.dx30.net, www.harshawtrane.com, www.oksanamastersusa.com, www.stseducation-us.com, www.thecenteronline.org”, www.stseducation-us.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested b2a3b2d6a5ef1dc6c3e0e5014139b6f3.a6b68a54eb69f6180463b13e3ea01851.acme.invalid from 23.253.213.249:443. Received 2 certificate(s), first certificate had names “dbs9.dx30.net, www.harshawtrane.com, www.oksanamastersusa.com, www.stseducation-us.com, www.thecenteronline.org”. Skipping.
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/dbs9.dx30.net/fullchain.pem (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

My operating system is (include version): Ubuntu 16.04 LTS

My web server is (include version): Apache/2.4.18 (Ubuntu)

My hosting provider, if applicable, is: self hosted

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

==================

Other notes …

The current certs are working fine.

Attached the LE debug log.

Attached output of: openssl s_client -showcerts -connect dbs9.dx30.net:443 </dev/null > /tmp/openssl.out.txt

openssl.out.txt (5.6 KB)

letsencrypt.log.txt (60.3 KB)

2

try using DNS or HTTP challenge

you can specify which challenge you want using the syntax below

–preferred-challenges PREF_CHALLS
A sorted, comma delimited list of the preferred
challenge to use during authorization with the most
preferred challenge listed first (Eg, “dns” or “tls-
sni-01,http,dns”). Not all plugins support all
challenges. See
https://certbot.eff.org/docs/using.html#plugins for
details. ACME Challenges are versioned, but if you
pick “http” rather than “http-01”, Certbot will select
the latest version automatically. (default: [])

3

Thanks for the reply. I tried several variations, but they don't help. Anything but tls-
sni-01, errors out with:

Attempting to renew cert from /etc/letsencrypt/renewal/dbs9.dx30.net.conf produced an unexpected error: None of the preferred challenges are supported by the selected plugin. Skipping.
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)

There is a python traceback in the log as well.

With tls-sni-01 still getting this error:

Domain: dbs9.dx30.net
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
5848ae44e78e4cf46a10c6a53de19b60.2a175c6ee18c2384e20a7a462d46c378.acme.invalid
from 23.253.213.249:443. Received 2 certificate(s), first
certificate had names "dbs9.dx30.net, www.harshawtrane.com,
www.oksanamastersusa.com, www.stseducation-us.com,
www.thecenteronline.org"

4

This error is caused by a situation in which the Certbot client is unable to modify the certificate returned by the server. The TLS-SNI-01 verification method is based on serving a custom self-signed certificate in response to requests from the CA, but the error is showing that even though Certbot thought it had modified your Apache configuration to serve this certificate, your Apache server went right on serving the normal certificate instead.

That in turn might have to do with an unusual certificate configuration in your Apache configuration files; maybe if you post your web server configurations here, someone might be able to recognize a related problem. We can also ask @bmw for other likely causes.

5

That might make sense. We are using a totally non-standard vhost configuration (for legacy reasons), non-standard location with all vhosts listed in one file. BUT … this renewal process has worked fine previously, so is this new functionality and is there a way to handle this situation? Thanks.

6

Other people have been reporting similar problems here. In that thread I explain what the most useful information you can give us to track down the problem is as well as a possible workaround that should work depending on your server configuration.

7

The test for .well-known/etc fails. There is apache config blocking access to all dotfiles. Removing that rule for one test domain in the SNI, didn’t change the outcome.

Attached is the apache conf that is in play.

Thanks!

vhosts_ssl.conf.txt (21.3 KB)

8

Are all of these vhosts in one file or did you just upload them that way for convenience? Currently, our Apache plugin doesn’t support multiple vhosts in one file but we’re working on adding this soon.

9

No that’s intentional, I mentioned that previously. There is legacy reasons for it, going way back. We have quite a few systems set up that way and it would be time consuming to undo it. If I could wave a wand and do it, then no problem.

Previously, the bot would complain about this but it still always worked fine (with manual edits) … both during creation and renewal.

10

Is the only option to redo the vhosts configs? I need to get this working pretty soon. Thx.

11

I am going to have some freaked out clients over this pretty soon.

If I blow away the whole installation and redo it, as it was created (with one big vhost file), is there any chance that will work?

Will things work ok if I break up the vhosts into separate files, like a standard Ubuntu installation? Is that the proper fix?

12

As test, I broke out one of the 5 clients that are part of the SNI, moved it to the std sites-enabled Ubuntu folder, restarted apache, ran a test, and it failed renewal identically to before. All 5 vhosts failed like ...

Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.

Do I need to blow this away and start over?

13

Hi @hal1,

I’m not particularly familiar with the nature and consequences of the problem of multiple vhosts per file but I think it’s possible that having any instances of multiple-vhost files currently confuses Certbot when using hte Apache integration.

If all of the webservers are serving at least some static files out of directories, you may be able to get better results with the letsencrypt-auto certonly --webroot approach, which is based on specifying a webroot directory and then completing a different kind of challenge (called HTTP-01) based on creating files under it. It does not install the certificate by modifying your webserver configuration, so you have to edit the webserver configuration yourself to refer to the files that get created under /etc/letsencrypt/live.

In this case, Certbot won’t attempt to read, parse, or modify your Apache configuration at all, and indeed is completely indifferent to what web server software you’re running or what its configuration looks like.

It may be possible to switch the existing certificates to webroot by referring to them individually when running a letsencrypt-auto certonly --webroot command, or you can make new certificates instead (including blowing away the old configuration, as you suggested).

14

Thanks, that gives me something to chew on and try. “I’ll be baaack.” :wink:

15

Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/dbs9.dx30.net/fullchain.pem. Your cert will
expire on 2017-05-21.

Bingo! Now my one disappointment is removing the dotfile block from my .htaccess. Is there a way around that?

16

Glad it worked! You mean that you’d like continue to prevent Apache from serving dotfiles in general, but still allow /.well-known/acme-challenge?

17

Yea, but I’ve got an .htaccess rule now that Allows that one URI, and blocks everything else. I guess thats good enough!

Thanks for the help! Much appreciated.

18

Sure thing. I’m glad it’s working now. Sorry that the issue about multiple vhosts can produce those unexpected and tricky errors.

19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.