Renewal fails for all domains: Invalid response

Help
1

My domain is: cloud.ducky.rocks, pics.ducky.rocks, ducky.rocks, monitor.ducky.rocks, portainer-home.ducky.rocks

I ran these commands, both had same error:
certbot renew
certbot --certonly -d cloud.ducky.rocks

It produced this output:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/cloud.ducky.rocks.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for cloud.ducky.rocks
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (cloud.ducky.rocks) from /etc/letsencrypt/renewal/cloud.ducky.rocks.conf produced an unexpected error: Failed authorization procedure. cloud.ducky.rocks (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://cloud.ducky.rocks/index.php/login [2606:4700:3032::681f:53ee]: "<!DOCTYPE html>\n<html class=\"ng-csp\" data-placeholder-focus=\"false\" lang=\"en\" data-locale=\"en\" >\n\t<head\n data-requesttoken=\"LSwQ". Skipping.

- - - - - - - -

My web server is (include version):

Server version: Apache/2.4.46 (Ubuntu)
Server built:   2020-08-10T12:32:00
Server's Module Magic Number: 20120211:93
Server loaded:  APR 1.6.3, APR-UTIL 1.6.1
Compiled using: APR 1.6.3, APR-UTIL 1.6.1
Architecture:   64-bit
Server MPM:     
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"

The operating system my web server runs on is (include version):

Distributor ID: Ubuntu
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Codename: bionic

My hosting provider, if applicable, is: Local Server.

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): 0.27.0

Other information
I had the same problem on a seperate domain, on a different machine (but behind the same network) a few hours ago, when i tried to renew. I ended up using --certonly and select option 3 to put the files in the web directory. That worked. Cannot do that with these domains.

I have also tried to go to .htaccess file for cloud.ducky.rocks specifically to add:
RewriteRule ^\.well-known\/acme-challenge\/ - [L] before any other rewrite rules.

I am running everything behind cloudflare, and these domains do have cloudflare proxy on, but it has worked before - could cloudflare be the reason behind this issue?

Thank you for your help

2 Likes
2

Hi @dennorske

no, I don't think that's the problem.

See your error - there is a redirect to your login.

May be not a rewrite rule, instead an application or .htaccess redirect.

You have to remove that redirect if the url starts with /.well-known/acme-challenge.

2 Likes
3

Thank you!

In regards of the redirect, I stated that I had already tried to edit my htaccess file with the contents in my original post. The htaccess file does not contain anything else than the rewrites, and my apache config file has no entries that would indicate such.

The same issue also happens when I spin up a standalone webserver (and shutting down my main one). As far as I know, the verification then happens using a temporary nginx instance, which is not using any of the existing configuration.

Here is the output from certonly using standalone webserver:

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): 2
Plugins selected: Authenticator standalone, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for cloud.ducky.rocks
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. cloud.ducky.rocks (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://cloud.ducky.rocks/.well-known/acme-challenge/x8TfkOicsQPlYmjieXgSdtiKEIgiu_HGQBJgtw12th0 [2606:4700:3035::681f:52ee]: "\n\n<!--[if IE 7]> <html class="no-js "

IMPORTANT NOTES:

2 Likes
4

It's simple. You have to find that redirect and you have to remove it.

If not, you can't use http validation.

Read

or switch to dns validation + --manual. May be painful, but with that redirect, http validation can't work.

2 Likes
5

Thank you, I appreciate your time.

Although, the redirect was not present on my final attempt, which confuses me. The redirects/rewrites has not been changed over the past 9 months, I am only reacting to a mail saying my certs will expire if not renewed.

It also looks like Cloudflare has taken priority on the domain SSL, when I inspect my certs.

3 Likes
6

Your certbot version is quite ancient (0.27.0 vs 1.9.0). You might consider updating to the snaps version.

3 Likes
7

Using the Full (strict) SSL option causes Cloudflare to validate the authenticity of the certificate served by your server to Cloudflare (thus requiring you to use either a Cloudflare Origin CA certificate or a certificate from a trusted CA like Let's Encrypt) whereas using the Full SSL option does not (thus allowing you to use a self-signed certificate). I highly recommend that you use the Full (strict) SSL option and a Cloudflare Origin CA certificate, not a Let's Encrypt certificate, because the Cloudflare Origin CA certificate is very easy to manage directly through Cloudflare and lasts much longer than a Let's Encrypt certificate.

To be clear: you cannot avoid using Cloudflare's certificate between your visitors and their network (unless you turn off HTTPS completely)! The only options you have are regarding the encryption of traffic between Cloudflare and your server(s).

3 Likes
8

I'm seeing different responses from cloudflare via http:

curl -Iki cloud.ducky.rocks
HTTP/1.1 301 Moved Permanently

Summary

Date: Sat, 14 Nov 2020 20:48:41 GMT
Connection: keep-alive
Cache-Control: max-age=3600
Expires: Sat, 14 Nov 2020 21:48:41 GMT

Location: https://cloud.ducky.rocks/

curl -Iki cloud.ducky.rocks
HTTP/1.1 403 Forbidden

Summary

X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Content-Security-Policy: frame-ancestors 'self'
Content-Type: text/html; charset="utf-8"
Content-Length: 2935
Connection: Close

And HTTPS returns a redirection to the login page:

curl -Iki https://cloud.ducky.rocks/
HTTP/2 302

Summary

date: Sat, 14 Nov 2020 20:52:22 GMT
content-type: text/html; charset=UTF-8
set-cookie: __cfduid=da0f41059eeb89e17b967bdaaa312305a1605387142; expires=Mon, 14-Dec-20 20:52:22 GMT; path=/; domain=.ducky.rocks; HttpOnly; SameSite=Lax; Secure
set-cookie: oc3obqv3jopc=4o7hdlpmcpn4ko6bt9rgis84sh; path=/; secure; HttpOnly; SameSite=Lax
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
set-cookie: oc_sessionPassphrase=Qv9pKwXYQSbASUj8O%2B9fDOWB%2BJB7Bj%2FVGm5lA2k2zhygTFkm3kQQYEin9c1JjOIIMsShpHed89pf6XP5Y9dOenQC%2FR1MA%2BVVlDdvfaZ5lKCAQJ2%2FYB3lse7mlG%2Frh4Fn; path=/; secure; HttpOnly; SameSite=Lax
content-security-policy: default-src 'self'; script-src 'self' 'nonce-Mi9ISk5iUHQ3VlpvSzZyTUdXaDZWd3JIS1F6c1p3SkQ5aXVsanBsTmU1az06NzV5elV0Mmd1d01IWUp5clhpc05aRUtUSEVTOUtub3J1MGI5emJZZEd0QT0='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: none
x-xss-protection: 1; mode=block
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict

location: https://cloud.ducky.rocks/index.php/login

Summary

cf-cache-status: DYNAMIC
cf-request-id: 066a20dd3100003720153b4000000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
report-to: {"endpoints":[{"url":"https://a.nel.cloudflare.com/report?s=sELxsQ7RRPwJzi%2BgTqZ9zhFYFGWFX8zy5pjb%2FQzLc66pYwy2%2FAHhGmfJOx2Mrz02HY1UcYovk3jhpkzjSfwWPd0aNRPknVg5dGKbXPuEN2ifp0ohflu2xPO5ftjDRQ%3D%3D"}],"group":"cf-nel","max_age":604800}
nel: {"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 5f239da848fc3720-MIA

That breaks the LE challenge request.

2 Likes
9

Hi @griffin!

Thank you for enlightening me! I will indeed update the bot, I was not aware there was a snap version of it. Thats cool!
And yes - a bit out of emberassment I realised it a bit too late that I had the full(strict) enabled, which uses SSL via cloudflare. In that case, I do not need my letsencrypt certificates, and it has indeed confused me in this case.

@rg305 - In regards of the responses you see, these are indeed on my live production apache2 service. I've disabled HTTP/1.1 - and there's a redirect in place to take users to the login page. I could see this rule present in the .htaccess file.

I had tried a standalone webserver to acquire my certificates, but that gave me no luck - and my redirects (as far as i know) should not affect that, or am I wrong on how i understand that, using "certbot certonly -d cloud.ducky.rocks" and then select option 2 ? :slight_smile:

2 Likes
10

The redirects should always exclude requests on /.well-known/acme-challenge/.
Forwarding HTTP to HTTPS is OK.

2 Likes
11

I have rewritten my previous post to make it more explicit. Following my recommendation could save you worlds of headache and time (and 13.3% on your car insurance if you switch to... never mind there).

2 Likes
12

Well done! Thank you :+1:

3 Likes
13

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