Let's encrypt renewal failure on my main servers domain name

I have just started getting a Let’s encrypt renewal failure on my main servers domain name.

I have a virtual server setup using mydomain.co.uk and the server is set up as server.mydomain.co.uk plus mail.mydomain.co.uk and www . mydomain.co.uk This is the default virtual server for the server main IP address and server.mydomain.co.uk is the FQDN for it

I use Certbot and for renewing the command is

scl enable python27 "./certbot-auto certonly --force-renewal --rsa-key-size 4096 --email hostmaster email address --agree-tos -w /home/mydomain/public_html/ -d mydomain.co.uk -d www.mydomain.co.uk -d mail.mydomain.co.uk -d server.mydomain.co.uk --authenticator webroot"

This has been working fine for well over a year but just started getting the error below. It is only the server.mydomain.co.uk which fails the others are fine even though they all point to the same place. Renewing other domains work fine.

Failed authorization procedure. server.mydomain.co.uk (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from server.mydomain.co.uk/.well-known/acme-challenge/...

I just checked the details of the padlock in a browser and it says trusted for a completely different domain which only recently had a SSL added but in the further details they are correct and the SSL works. The initial information is where it says marked as trusted for the different domain is only viewable in Safari.

All very odd but I need to find a solution with the minimum interuption since this effects the mail server used buy lots of poeople.

CERTBOT have some problems with a security BUG LETSENCRYPT

Also do you know it was renewing the hostname LE Cert before this BUG?

IS your certbot plugin updated?
Did you asked also in that community?



Other domains renew fine. Each time Cerbot is run it checks for updates and install if there is. What I don’t undertsand is why since the well-known folder is the same location for all it is saying it can’t reach it, plus the fact of showing the other domain as being trusted etc.

Yes I have already posted the question to the Letsencrypt forum I poste don here in case it might be conected to any updates with Virtualmin / Webmin etc

You can do yourself the test for that file/directory is reachable in browser.
Everything for the hostname vps/server should be right so dns, rewrites and/or security options/settings ports wrong or blocking could also be cause.

So test al of these

in browser
server.mydomain.co.uk/.well-known/acme-challenge/ (mayby must be reachable under http ? ) ( and fur subdomain server ofcourse no www.server.) .
Virtualmin uses some other sub alliases to default as: autoconfig/mail and so on wich you see if creating a virtualserver.
Do you have a virtual server allias/subserver for your server.mydomain.co.uk in your main mydomain?

I already tested and yes it is reachable and no is is not a sub server

Here we did have probs sometime not having it as subsserver of main, the virtualmin host i mean.

Maybe Jamie or Joe or someone else from virtualmin could help out if needed yes or no? ( while certbot is not the LE cert plugin virtualmin uses)

server.mydomain is the FQDN of the server. As I said this worked fine until a the renewal came up a few days ago. I suspect it has got more to do with the other domain being trusted somehow.

I was considering revoking, deleting and get a new cert for the main domain but if that fails it would be a problem.

Re Help sure

You didn’t write versions nrs

Virtualmin, webmin and so on also certbot has updated and lots of problems with that update as you can read there.

So if you didn’t change things then probably one of the updated things as LETsencrypt no more dns.sni for example because security flaw!

So could be a setting that you need to do after updates, or renew with other commands for one time see the links i gave you in that forum some tried things with hook and so on.
If important to have it soon solved create a support ticket virtualmin or…

I sorted it as server.mydomain.co.uk was not set as an alias in httpd conf for the virtual site even though I could reach a file in the directory under that domain and it was never needed to be set previously so may be something changed with an update to Apache.