Please fill out the fields below so we can help you better.
My domain is: alarmcomplete.co.uk
I ran this command: certbot renew
It produced this output:
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.completesecurityessex.co.uk
http-01 challenge for alarmcomplete.co.uk
http-01 challenge for completesecurityessex.co.uk
http-01 challenge for completesecurityessex.com
http-01 challenge for www.alarmcomplete.co.uk
http-01 challenge for www.completesecurityessex.com
Waiting for verification…
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/www.completesecurityessexsufficient authorization :: Invalid response from http://www.alarmcomplete.co.uk
- META TAGS -
- ". Skipping.
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
The wrong website is being chosen. We use SNI and it works correctly with clients visiting the correct page (please feel free to attest/contest this). The snippet of returned page when certbot visits http://www.alarmcomplete.co.uk/.well-known/acme-challenge/FolMVFuGoFEOAoBY-vR is showing a snippet for another domain (https://www.aegisalarms.co.uk) which is hosted on the same IP address.
Renewals get all their information from etc/renewal/domain.conf
Review that file as it may explain why you are getting errors
You can review the manual (https://certbot.eff.org/docs/using.html) especially the --allow-subset-of-names flag which should assist in resolving your issues
There is no /etc/renewal/domain.conf file all the config files live in /etc/letsencrypt/renewal instead.
Unfortunately --allow-subset-of-names does not work. It is as if the certbot is going to https://126.96.36.199 which shows the page of https://www.aegisalarms.co.uk instead of going to https://www.alarmcomplete.co.uk
Here is a copy of the config file:
renew_before_expiry = 30 days
version = 0.10.2
archive_dir = /etc/letsencrypt/archive/www.completesecurityessex.co.uk
cert = /etc/letsencrypt/live/www.completesecurityessex.co.uk/cert.pem
privkey = /etc/letsencrypt/live/www.completesecurityessex.co.uk/privkey.pem
chain = /etc/letsencrypt/live/www.completesecurityessex.co.uk/chain.pem
fullchain = /etc/letsencrypt/live/www.completesecurityessex.co.uk/fullchain.pem
Options used in the renewal process
authenticator = webroot
installer = None
account = b8ca35b90ed98c0c2b8cbfc2818fe84c
webroot_path = /www/complete,
must_staple = True
rsa_key_size = 4096
www.completesecurityessex.com = /www/complete
completesecurityessex.co.uk = /www/complete
www.alarmcomplete.co.uk = /www/complete
www.completesecurityessex.co.uk = /www/complete
completesecurityessex.com = /www/complete
alarmcomplete.co.uk = /www/complete
For now what I’ve done is “ln -s /www/aegis/.well-known /www/complete/.well-known” to get past this month’s renewals. I cannot recreate the SNI problem myself, so it seems the only client going to the wrong page is the certbot auth system. As it received the challenge from the wrong domain in an SNI environment, presumably this is a concern for yourselves?
Looking at https://www.aegisalarms.co.uk and https://www.completesecurityessex.co.uk via a web browser vs what the auth system uses should show you the problem.
A) You are using the webroot plugin which is a HTTP Challenge
B) SNI should not play any part in it as it’s a HTTPS (SSL) construct
C) If you are redirecting to HTTP to HTTPS in your server configs it could explain why you are having issues
D) The important test is not to go via HTTPS version of your website but rather via HTTP and observe the behavior from there
a general review of the authenticators you are using in the certbot documentation would reveal why this is not really a concern
sorry to be blunt
All of those websites support both IPv4 and IPv6. I haven’t checked the others, but for https://www.alarmcomplete.co.uk/, IPv4 redirects to one website, and IPv6 has an incorrect certificate and redirects to a different website.
Sorting out the IPv6 configuration issues may solve whatever is wrong here.
@mnordhoff thank you - it looks like our DNS provider has broken the AAAA records
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.