I’m using certbot to renew certs on an Apache 2.2 server. I use ModReWrite to redirect http to https. This seems to be causing certbot to fail when validating the domain. I read in this post My server redirects port 80 to 443, and certbot bails when using --manual that 301 and 302 redirects are respected and shouldn’t be a problem. I’ve tested my RewriteCond and RewriteRule and they seem to be fine and the output URL looks perfect
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
I've moved this to the "Help" category - could you please fill out the questions below? (These are what you'd normally be prompted with when creating a new thread under "Help", and will greatly assist us in helping you fix this.) My initial guess would be to check that port 443 is accessible from the public internet, and that your web server properly responds to HTTPS requests.
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. crt.sh | 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:
I ran this command:
It produced this output:
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 initial install for the certificates was run before the force https stuff was added to the .htaccess file. It was when the cron renewal came along that I discovered the issue with the force to https.
# this command went and got certs for all the domains for bridgingnursing
/root/scripts/certbot-auto certonly --webroot -w /home2/specials/public_html -d bridgingnursing.ca -d www.bridgingnursing.ca -d bridgingnursing.com -d www.bridgingnursing.com
I ran this command:
python -c 'import random; import time; time.sleep(random.random() * 3600)' && /root/scripts/certbot-auto renew
It produced this output:
Basically, a 403 error
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/bridgingnursing.ca.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for bridgingnursing.ca
http-01 challenge for bridgingnursing.com
http-01 challenge for www.bridgingnursing.ca
http-01 challenge for www.bridgingnursing.com
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (bridgingnursing.ca) from /etc/letsencrypt/renewal/bridgingnursing.ca.conf produced an unexpected error: Failed authorization procedure. bridgingnursing.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://bridgingnursing.com/.well-known/acme-challenge/u5xnsCvd8SPSXr9CxcyhUHzP0AZjzc7oiOPczVBB7Aw: "
So basically put in a rule to prevent any request for "well-known/acme-challenge/*" from redirecting to https? I'm guessing that would work, and I'll test it later today. It's still my understanding that the 301 or 302 redirects shouldn't be a problem though, and I'd like to satisfy my curiosity on that.
Is this intended?
You should definitly exclude any PHP handler for /.well-known/acme-challenge on your server, otherwise the files certbot creates will not be delivered at all. This is clearly visible in the output of the certbot command:
I'll have to puzzle through that a bit. I get a very different result if I try wget --no-check-certificate -S -O/dev/null ‘http://bridgingnursing.com/.well-known/acme-challenge/foo’
I'll admit to not understanding everything your example is exposing. https://faculty.nipissingu.ca/ is indeed another virtual host on the server, but not connected at all. It is the first vhost in the Apache configuration though, so default I suppose.
This one is obvious, too. Look what happens when connecting via https:
$ openssl s_client -connect bridgingnursing.com:443 -servername bridgingnursing.com </dev/null
CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=CA/ST=Ontario/L=North Bay/O=Nipissing University/CN=*.nipissingu.ca
i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
1 s:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
i:/C=US/O=DigiCert Inc/OU=
You don't seem to have configured https for bridgingnursing.com, so redirecting from http to https confuses the ACME server.
I would recommend disabling http->https redirection for /.well-known/acme-challenge/
I think I'm getting a sense what's going on. If you visit https://bridgingnursing.com you'll see that it is using the Lets Encrypt cert for that domain. *.nipissingu.ca is a DigiCert certificate and the default cert for the server, as most vhosts are subdomains of nipissingu.ca. bridgingnursing.com is one of half a dozen FQDNs on the server using Lets Encrypt certs, all on the same IP address using the SNI model.