Redirect to https causing problems


#1

Hi,

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]

Input
http://www.example.com/.well-known/acme-challenge/ek4Hq2e4X_xxkIoZQP2wnTFsxReXPh8esOKYewT6nA4

Output
https://www.example.com/.well-known/acme-challenge/ek4Hq2e4X_xxkIoZQP2wnTFsxReXPh8esOKYewT6nA4

And yet I was only able to get the renewal to happen when I commented out the ReWrite stuff.

Any suggestions what to look for and how to test while I wait for my next expiry/renew cycle?


#2

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. https://crt.sh/?q=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):


#3

Try:
RewriteEngine On
RewriteRule ^.well-known/acme-challenge/ - [L]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]


#4

Thanks Jared,

Apologies for mis-categorizing.

My domain is:
https://bridgingnursing.ca and .com

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: "

<!–[if IE 7]>

<![endif]–", www.bridgingnursing.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.bridgingnursing.com/.well-known/acme-challenge/ORng-w80LJcu14ulQJ5N4syYqDN0kL1RrS2oVlH6Qxk: "

<!–[if IE 7]>

<![endif]–". Skipping.

My web server is (include version):
Apache 2.2

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

My hosting provider, if applicable, is:
N/A

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


#5

Thanks @rg305,

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.


#6

Have a look at your redirect chain:

$ wget --no-check-certificate -S -O/dev/null ‘http://bridgingnursing.com/.well-known/acme-challenge/foo

–2018-04-27 15:01:44-- http://bridgingnursing.com/.well-known/acme-challenge/foo
HTTP/1.1 301 Moved Permanently
Date: Fri, 27 Apr 2018 13:01:54 GMT
Server: Apache/2.2.15 (CentOS)
Location: https://bridgingnursing.com/.well-known/acme-challenge/foo
Content-Length: 351
Connection: close
Content-Type: text/html; charset=iso-8859-1
–2018-04-27 15:01:44-- https://bridgingnursing.com/.well-known/acme-challenge/foo
HTTP/1.1 302 Found
Date: Fri, 27 Apr 2018 13:01:55 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.6.36
Location: https://faculty.nipissingu.ca/
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
–2018-04-27 15:01:45-- https://faculty.nipissingu.ca/
HTTP-Anforderung gesendet, warte auf Antwort…
HTTP/1.1 200 OK
Date: Fri, 27 Apr 2018 13:01:55 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.6.36
Link: https://faculty.nipissingu.ca/wp-json/; rel=“https://api.w.org/
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

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:


#7

Thanks for this @bytecamp

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’

wget --no-check-certificate -S -O/dev/null ‘http://bridgingnursing.com/.well-known/acme-challenge/foo’
http://bridgingnursing.com/.well-known/acme-challenge/foo’: Scheme missing.

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.


#8

Well, all you have to make sure is that the location /.well-known/acme-challenge/ is excluded from being delivered by wordpress.


#9

Yes. Easily enough done. I wonder why it doesn’t become a problem when I am not redirecting from http to https though?


#10

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/


#11

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.

I appreciate your patience and guidance.


#12

actually, the .ca is working correctly. the .com seems to have a misconfiguration. Which I have now fixed.


#13

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