Renew failed: Failed authorization procedure urn:acme:error:unauthorized

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: kegge.ca

I ran this command: sudo certbot certonly --cert-name mail.kegge.ca

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?

1: Apache Web Server plugin - Beta (apache)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)

Select the appropriate number [1-3] then [enter] (press ‘c’ to cancel): 1
Plugins selected: Authenticator apache, Installer None
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for mail.kegge.ca
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. mail.kegge.ca (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 90f0353b9c04f0ce512d20233a7d903a.dd70203b90f6f642e84980667473d3c1.acme.invalid from [2001:41d0:302:2100::71ab]:443. Received 2 certificate(s), first certificate had names “www.kegge.ca

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: mail.kegge.ca
    Type: unauthorized
    Detail: Incorrect validation certificate for tls-sni-01 challenge.
    Requested
    90f0353b9c04f0ce512d20233a7d903a.dd70203b90f6f642e84980667473d3c1.acme.invalid
    from [2001:41d0:302:2100::71ab]:443. Received 2 certificate(s),
    first certificate had names “www.kegge.ca

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

My web server is (include version):
Server version: Apache/2.4.6 (CentOS)
Server built: Oct 19 2017 20:39:16

The operating system my web server runs on is (include version):
CentOS Linux release 7.4.1708 (Core)

My hosting provider, if applicable, is: N/A

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

Hi @tneo,

There seems to be a discrepancy between the configuration of https://mail.kegge.ca/ in IPv4 and IPv6. This discrepancy could be causing the error that you’ve seen. Can you take a look at your configuration and make sure that all of the virtual hosts are configured equivalently for IPv4 and IPv6?

Hi @schoen ,

What kind of discrepancy are you referring to? DNS entries are identical for the www and the mail domain. My Vhosts are very simple, just a redirect from :80 to :443 and the correct root folder.

If I curl -4 https://mail.kegge.ca/ and curl -6 https://mail.kegge.ca/, I get two different kinds of certificate error, indicating that different certificates were provided in this case.

Hmm. Google was doing difficult with my mail. So I configured the IPv6 in the DNS later (after the initial issue of the certificate). I did renew the main domain certificate. All went well. How can I fix the issue, so I get a correct certificate again?

@schoen
Do you have a suggestion how I can fix this issue? Can I simply remove the existing certificates and install them anew for the domain?

Well, I’m not positive about the underlying reason for the problem.

The error about “Incorrect validation certificate for tls-sni-01 challenge” refers to a challenge method that is being phased out.

This is not the reason that your validation has failed (if it were, you would see a different error message; the continued use of TLS-SNI-01 is permitted for renewals of names which previously had Let’s Encrypt certificates), but it might be a good incentive to switch over to the HTTP-01 validation method, either by upgrading Certbot to 0.21 or later, or by using -a webroot -i apache instead of --apache (or -a standalone -i apache if you don’t have Apache listening on port 80 now). This validation method is very different and should not run into the same problems that you’re experiencing now.

certbot does not think I’m friendly still when I use the -a webroot -i apache

Waiting for verification…
Cleaning up challenges
Failed authorization procedure. mail.kegge.ca (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://mail.kegge.ca/.well-known/acme-challenge/UBUxAnrn7s_CsaJNLdVYqcrbX_0tWvDjB2itX4kXbT4: "

<html lang="en" dir="ltr" prefix="content: http://purl.org/rss/1.0/modules/content/ dc: http://purl.org/dc/term"

IMPORTANT NOTES:

When I check my webroot the .well-known directory is created, but the additional acme-challenge directory is not.

Can you create a file manually at this location and access it via the web server?

Yes that is not an issue. I can become root to add that file, just need to know correct owner to assign I suppose.

So, could you try making a file at http://mail.kegge.ca/.well-known/acme-challenge/test.txt for verification?

Which webroot directory did you specify to Certbot, and how did you specify it?

The plain HTTP will not get you the file, the HTTPS works.

It looks like you have a rewrite problem where you’re missing a trailing slash (you rewrite “http://mail.kegge.ca/” to “https://mail.kegge.ca” without the trailing slash). This results in forming the invalid URL https://mail.kegge.ca.well-known/acme-challenge/test.txt.

A lot of people have had this problem before; it should be OK (or at least better in this regard) if you can add the trailing slash to the definition of the rewrite.

Also, it has to work over HTTP in order to use this authentication method with the CA. :slight_smile: (A redirect is OK, including a redirect to HTTPS, but the initial connection is always made over HTTP.)

Trailing slash is added, so the http goes through now. Though the renewal is not :frowning:

Well, that looks like progress! Do you still see the same error message as before? How are you specifying the webroot directory to Certbot?

Same error still indeed:

Domain: mail.kegge.ca
Type: unauthorized
Detail: Invalid response from
http://mail.kegge.ca/.well-known/acme-challenge/egO38tewTKOMpI6Ul72bIm7f0Oj0WaYhVpb5PZD2XvU:
"

<html lang="en" dir="ltr" prefix="content: http://purl.org/rss/1.0/modules/content/ dc: http://purl.org/dc/term"

I tried with and without a trailing slash in the webroot, but the result is the same. I do use SELinux if that matters, but the directory is owned by Apache and has the rw permission there. I have run the restorecon command to re-affirm that permission scheme: drwxr-xr-x. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 acme-challenge

Can you see a particular error in your web server error logs associated with the CA’s attempt to connect?

Are you sure that the webroot directory is right? (It should be pointed at the directory that contains .well-known/acme-challenge, not at .well-known/acme-challenge itself.)

I do not see any errors that may of help. I use the webroot as I have configured in my configuration file for roundcube. And now I’ve reached my incorrect authorization limit attempts.

Is it possible to delete the current certificates and install the certificates again with the webroot command?

Sorry about that. The failed authorization rate limit will reset after one hour (so perhaps imminently).

If you can post the exact directories in question (what you provided as the webroot and where you put the test.txt), maybe I can see if I can see anything wrong.

Yes, although that doesn’t affect rate limits in any way. You can use certbot delete for this.