Cannot Renew Certificate - authorisation error

And I just noticed the “server” responding isn’t Apache:

 curl -Iki
HTTP/1.1 301 Moved Permanently
Content-Type: application/binary
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Date: Mon, 11 May 2020 14:46:29 GMT
Content-Length: 0
Server: ESF
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff

What is “ESF” ? ? ?
Hindsight = 20/20
It was there the whole time!

I don’t know, I believe it might be a google thing…

Are you even on the right server?
What shows?:

Are you even on the right server?
What shows?:

[lack of sleep]

That returns the IP of my server.

Is the redirection of the google site overriding anything apache is doing ?

I don’t know enough to answer that question.
I don’t even know what “SPF” stands for in the context of “server type”.

An SPF record is a Sender Policy Framework record. It’s used to indicate to mail exchanges which hosts are authorized to send mail for a domain. It’s defined in RFC 4408, and clarified by RFC 7208.


Don’t you mean ESF ?

From what I can see, any call to will get a response from the google site, and not the server. From what you say, we need to be able to get a call from in order to help certbot validate the site? This http address is not setup on the server or on the virtual host. Is there anything I can add or change to make this so, or have I got this wrong ?

I was able to set up the https certificate in the first place, and it is clearly working now; my site is using an https secure address. I do not understand why certbot cannot validate when everything appears to already be in place?

If we cannot solve it on the community, what recourse do I have to “letsencrypt” to get this resolved ?

That’s NOT the SPF we are talking about.

My eyes! my eyes!
Yes, not SPF, ESF.

Now that we know HTTP is NOT an option.
We can focus on the HTTPS path.
[I was starting to think I was a bit crazy there for a minute]

We need to compare a working https config with this failing config.
Which includes reviewing their renewal conf files.

Sorry My bad… Isolated too long.

@RIP No worries, we are all going through the same thing (together | apart).
If you can, walk around the block.
See the random little critters that have come out to claim the world we left behind.
[we have strange African lizards roaming the streets like they own them … I kinda guess they do, now]

1 Like

Ah good, I am not alone!

Shall I post my renewal conf as well here ?

You already have.

I think we should try the --webroot -w /doc/root/path method
That bypasses the “logic” that tries to figure where to put the files and forces a specific location.
The “logic” falls on us to determine and ensure it works.
And when it does it works flawlessly.

OK, how do we do that ?

We match certbot webroot to the expected root of the web server vhost config (or specific location for /.well-known/… therein, if specified).

So what does the HTTPS vhost config look like now?
[since everything is being redirected to HTTPS - despite our best efforts]

OK tried this:

sudo certbot certonly --webroot -w /var/www/ -d

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
Using the webroot path /var/www/ for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from [2607:f8b0:400f:800::2013]: "<!DOCTYPE html><html lang=\"en-US\" itemscope itemtype=\"\"><head><script type=\"text/javascript\" nonce=\"5Bs"

 - The following errors were reported by the server:

   Type:   unauthorized
   Detail: Invalid response from
   [2607:f8b0:400f:800::2013]: "<!DOCTYPE html><html lang=\"en-US\"
   itemscope itemtype=\"\"><head><script
   type=\"text/javascript\" nonce=\"5Bs"

   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.

I reverted the virtual host entry to how it was when we started:

<VirtualHost *:80>
         DocumentRoot /var/www/
         ErrorLog ${APACHE_LOG_DIR}/error.log
         CustomLog ${APACHE_LOG_DIR}/access.log combined
     RewriteEngine on
     RewriteCond %{SERVER_NAME}
     RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]