Another: Client lacks sufficient authorization

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: getafloat.co.uk

I ran this command: certbot certonly --webroot -w /opt/bitnami/apps/wordpress/htdocs -d getafloat.co.uk -d www.getafloat.co.uk

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for getafloat.co.uk
http-01 challenge for www.getafloat.co.uk
Using the webroot path /opt/bitnami/apps/wordpress/htdocs for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. getafloat.co.uk (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://yoursite.com/ [18.188.39.34]: "\n\n\n\n\n <meta charset=“UTF-8”>\n <meta name=“viewport” content=“width=device-width,”

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: getafloat.co.uk
    Type: unauthorized
    Detail: Invalid response from https://yoursite.com/ [18.188.39.34]:
    "\n\n\n\n\n <meta
    charset=“UTF-8”>\n <meta name=“viewport”
    content=“width=device-width,”

    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): nginx version: nginx/1.14.0 (Ubuntu)

The operating system my web server runs on is (include version):
Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-47-generic x86_64)

My hosting provider, if applicable, is: DigitalOcean

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

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 0.23.0


I’ve been trying to migrate a client’s site from AWS to a new DigitalOcean server, but am running into problems adding their domain to the server’s existing cert. Their domain getafloat.co.uk is registered with 123-reg.co.uk and (at the moment) points to AWS nameservers, which in turn are configured to point to their AWS web server and both www.getafloat.co.uk and getafloat.co.uk correctly resolve. From what I understand my client used an Indian developer/admin to carry out maintenance/config work in the past and back in Feb also got him to update their Let’s Encrypt certificate for the domain, which is currently working on the AWS platform. However, since I could not see certbot installed on the server, I asked him how he installed their Let’s Encrypt cert, but he avoided the question and has not got back to me since.

I’ve been used to using Let’s Encrypt / Cerbot for about a year and a half and feel relatively comfortable installing the software and creating new certs, but admittedly struggle with deeper issues.

I’ve migrate the getafloat.co.uk site from a code and database import level, but am having issues adding the domain onto the existing certificate for their other domain on the server: activities.uk.com (which is working fine).

Specifically, I’ve changed the A records for both www.getafloat.co.uk and getafloat.co.uk to point to the new DigitalOcean server, waited a reasonable time and checked those domain names resolve to the new DigitalOcean server’s IP before trying to add the getafloat domain to the certificate, but am getting this weird error:

Failed authorization procedure. getafloat.co.uk (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://yoursite.com/ [18.188.39.34]:

However, we have nothing to do with the domain or IP that it says we’re getting an invalid response from: https://yoursite.com/ [18.188.39.34]:

I’m totally guessing but this seems to be a DNS issue, since (when I’ve changed the A records to point to the new DigitalOcean server) www.getafloat.co.uk resolves and correctly delivers/renders the site, but getfloat.co.uk (without the www.) doesn’t and instead redirects to the other (main/default) site on the (DigitalOcean) server activities.uk.com. Trying other options, I then updated the 123-reg.co.uk nameservers to point directly to the DigitalOcean DNS (which I needed to configure anyway), but I still get the same problem.

As it currently stands getafloat is back to its previous configuration, being served from AWS and the 123-reg.co.uk nameservers reset back to point to AWS - to keep my client’s site up.

I’ve informed my client about this issue, but has said he has no idea. He also knows I’m trying to migrate the domain, so I have some leeway with the site being up/down, but obviously would rather keep it up.

I’m really not sure what to do next, but would really appreciate any help anyone might be able to give.

All the best,

Derrick

Hi @derrickr

I don't see such a problem.

Your ip addresses ( https://check-your-website.server-daten.de/?q=getafloat.co.uk ):

Host T IP-Address is auth. ∑ Queries ∑ Timeout
getafloat.co.uk A 35.176.145.151 yes 1 0
AAAA yes
www.getafloat.co.uk A 35.176.145.151 yes 1 0
AAAA yes

And checking these domains via their ip addresses:

There is a redirect http -> https, but no redirect to another ip address 18.188 ...

The answer looks ok, there is the expected result http status 404 - not found checking /.well-known/acme-challenge/unknown-file

So if you use the correct webroot (sometimes a problem using Bitnami) that should work.

PS: Your certbot is very old:

But if webroot is supported, that should work.

PPS: The current nameservers are ns-1204.awsdns-22.org ...

The content of non-www and www is the same (checked with my browser), there is no redirect.

The certificate

CN=getafloat.co.uk
	07.03.2019
	05.06.2019
expires in 46 days	getafloat.co.uk, www.getafloat.co.uk - 2 entries

works. So you don't need now a new certificate. So if this is the old server, manage the move of the server. If this is done, create a new certificate with your new server.

Or use (one time) dns-01 validation with --manual certonly, that works always. Then you have a new certificate you can use 90 days.

Thanks Juergen,

Yes, I had to revert back to the old server, so the previous working config would’ve worked.

I’ve just switched over to the new DigitalOcean setup and once again am seeing the errors explained above.

I’ve also just tried to add the getafloat domain to the cert on the server using the following command:

certbot certonly --webroot -w /opt/bitnami/apps/wordpress/htdocs -d getafloat.co.uk -d 
www.getafloat.co.uk -w /var/www/html -d activities.uk.com -d activities.uk.com

Which gave this response:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
You have an existing certificate that contains a portion of the domains you requested (ref: /etc/letsencrypt/renewal/activities.uk.com-0001.conf)

It contains these names: activities.uk.com

You requested these names for the new certificate: getafloat.co.uk, www.getafloat.co.uk, activities.uk.com.

Do you want to expand and replace this existing certificate with the new certificate?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(E)xpand/(C)ancel: E
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for getafloat.co.uk
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. getafloat.co.uk (http-01): urn:ietf:params:acme:error:unauthorized :: 
The client lacks sufficient authorization :: Invalid response from https://yoursite.com/ [18.188.39.34]: "<!-- HEADER -->\n<!DOCTYPE html>\n<html>\n\n<head>\n    <meta charset=\"UTF-8\">\n    <meta name=\"viewport\" content=\"width=device-width,"

IMPORTANT NOTES:
 - The following errors were reported by the server:

Domain: getafloat.co.uk
Type:   unauthorized
Detail: Invalid response from https://yoursite.com/ [18.188.39.34]:
"<!-- HEADER -->\n<!DOCTYPE html>\n<html>\n\n<head>\n    <meta
charset=\"UTF-8\">\n    <meta name=\"viewport\"
content=\"width=device-width,"

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.

So once again, www.getafloat.co.uk is resolving, but getafloat.co.uk redirects to the main/default domain on the server.

And I’m also seeing that reference to: https://yoursite.com/ [18.188.39.34] once again.

Apologies for my earlier confusion of reverting back, but the nameservers are now pointed to the new DigitalOcean implementation so one can actually see the issue I’m experiencing.

Perhaps this might now allow a proper diagnosis?

Once again many thanks for your help!

P.S.
The version of certbot was the latest that I could install with the standard 18.04 LTS build from DigitalOcean.

However, I followed https://certbot.eff.org/lets-encrypt/ubuntubionic-nginx.html to upgrade it to: certbot 0.31.0

Yep, now the error is visible:

Host T IP-Address is auth. ∑ Queries ∑ Timeout
getafloat.co.uk A 167.99.91.126 yes 1 0
AAAA yes
www.getafloat.co.uk A 167.99.91.126 yes 1 0
AAAA yes

There are curious redirects:

Domainname Http-Status redirect Sec. G
http://getafloat.co.uk/
167.99.91.126 301 https://www.activities.uk.com/ 0.054 E
http://www.getafloat.co.uk/
167.99.91.126 200 0.127 H
https://getafloat.co.uk/
167.99.91.126 301 https://www.activities.uk.com/ 0.414 N
Certificate error: RemoteCertificateNameMismatch
https://www.getafloat.co.uk/
167.99.91.126 301 https://www.activities.uk.com/ 0.347 N
Certificate error: RemoteCertificateNameMismatch
https://www.activities.uk.com/ 200 0.457 B
http://getafloat.co.uk/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
167.99.91.126 307 Best Website Builder | Create A Website & Go Online| Yoursite.com 0.054 D
Visible Content: 307 Temporary Redirect nginx
http://www.getafloat.co.uk/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
167.99.91.126 307 Best Website Builder | Create A Website & Go Online| Yoursite.com 0.053 D
Visible Content: 307 Temporary Redirect nginx
Best Website Builder | Create A Website & Go Online| Yoursite.com 302 https://www.yoursite.com 0.337 E
Visible Content:
https://www.yoursite.com 301 https://yoursite.com/ 1.194 A
Visible Content: 301 Moved Permanently nginx/1.14.1
https://yoursite.com/ 200 1.314

http + /.well-known/acme-challenge is redirected to

http://acme.yourdomain.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de?redirect=yes

that's redirected to https://www.yoursite.com.

Is this an own server or is it a shared hosting? Looks like your hoster blocks /.well-known/acme-challenge.

Using webroot certbot must run on the 167.99.91.126, but that doesn't help if the hoster catches the /.well-known/acme-challenge - path in front of your server.

I’m using a DigitalOcean VPS like many of the other sites I successfully manage Let’s Encrypt upon. Indeed the other domain on this server activities.uk.com is running fine, so (could be wrong but) I kind of doubt it’s being blocked.

Oh, that domain has the same problem ( https://check-your-website.server-daten.de/?q=activities.uk.com ):

The ip is the same:

Host T IP-Address is auth. ∑ Queries ∑ Timeout
getafloat.co.uk A 167.99.91.126 yes 1 0
AAAA yes
www.getafloat.co.uk A 167.99.91.126 yes 1 0
AAAA yes

The redirects - there is the same picture:

/.well-known/acme-challenge is redirected to yoursite.com.

The certificate is 60 days valid:

CN=activities.uk.com
	21.03.2019
	19.06.2019
expires in 60 days	activities.uk.com, www.activities.uk.com - 2 entries

Looks like your hoster has changed something in the last 30 days.

-->> Ask your hoster.

Okay, thanks Juergen, I’ve raised a ticket with DigitalOcean.

1 Like

Okay, I think I’ve managed to resolve it.

I didn’t do anything fancy, but am suspecting the DNS is still propagating which might not have helped. I also reviewed the command line and had an almost eureka moment when I noticed that the webroot path wasn’t specific to the domain(s) but rather the certificate! All very confusing since I couldn’t see the documentation spelling this out (or perhaps me just not understanding). However, I gave it another go, using what I thought were the correct (new) settings and voila! It worked :slight_smile:

I know my client’s site has a number of other inherent issues, but that’s for another day.

Thought I’d let you know all the same.

Cheers,

Derrick

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