Redirect HTTP->HTTPS option breaks LetsEncrypt

Submitted by kristofferR on Thu, 08/17/2017 - 09:21

During setup I selected the "Redirect HTTP to HTTPS by default" option. Unfortunately it works by adding a redirect that breaks LetsEncrypt.

With the redirect option enabled:

Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying www.domain.com...
Wrote file to /home/domaincom/public_html/.well-known/acme-challenge/adsfasdfasdfasdfasdfajkshdf, but couldn't download http://www.domain.com/.well-known/acme-challenge/adsfasdfasdfasdfasdfajkshdf
Traceback (most recent call last):
  File "/usr/libexec/webmin/webmin/acme_tiny.py", line 235, in <module>
    main(sys.argv[1:])
  File "/usr/libexec/webmin/webmin/acme_tiny.py", line 231, in main
    signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, args.dns_hook, args.cleanup_hook, log=LOGGER, CA=args.ca)
  File "/usr/libexec/webmin/webmin/acme_tiny.py", line 184, in get_crt
    domain, challenge_status))
ValueError: domain.com challenge did not pass: {u'status': u'invalid', u'validationRecord': [{u'addressesResolved': [u'12.34.56.789'], u'url': u'https://domain.com/acme-challenge/tokenasdfasdfasdf', u'hostname': u'domain.com', u'addressesTried': [], u'addressUsed': u'12.34.56.789', u'port': u'443'}, {u'addressesResolved': [u'12.34.56.789'], u'url': u'http://domain.com/.well-known/acme-challenge/tokenasdfasdfasdf', u'hostname': u'domain.com', u'addressesTried': [], u'addressUsed': u'12.34.56.789', u'port': u'80'}], u'keyAuthorization': u'tokenasdfasdfasdf.dfghdfghdfgh', u'uri': u'https://acme-v01.api.letsencrypt.org/acme/challenge/asdfasdfasdfasdf/452345', u'token': u'tokenasdfasdfasdf', u'error': {u'status': 403, u'type': u'urn:acme:error:unauthorized', u'detail': u'Invalid response from http://domain.com/.well-known/acme-challenge/tokenasdfasdfasdf: "<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"'}, u'type': u'http-01'}

When you remove the redirect it works again. Here's a proper way to do HTTP->HTTPS redirects that won't break LetsEncrypt:

.htaccess

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/[0-9a-zA-Z_-]+$
RewriteRule ^(.*)$ https://domain.com/$1 [R,L]
Status: 
Active

Comments

Submitted by JamieCameron on Thu, 08/17/2017 - 23:55

Which Virtualmin version are you using? In the latest release, this redirect should be disabled temporarily when requesting a Let's Encrypt cert.

Submitted by kristofferR on Sat, 08/19/2017 - 18:10

the latest, version 6. I installed it fresh yesterday.

Submitted by JamieCameron on Sat, 08/19/2017 - 19:40

Ok ... and how did you setup the HTTP -> HTTPS redirect exactly?

Submitted by kristofferR on Sun, 08/20/2017 - 00:58

Virtualmin - System Settings - SSL Settings - Redirect HTTP to HTTPS by default - Yes

Submitted by JamieCameron on Sun, 08/20/2017 - 12:01

When this redirect is enabled, if you go to the Aliases and Redirects page what path is it setup for?

Francewhoa's picture
Submitted by Francewhoa on Thu, 08/24/2017 - 22:34

We tested #4 above. But not with Let's Encrypt. This is to confirm that #4 worked without Let's Encrypt. Using Debian Jessie 8. And Virtualmin 6.00.

When "Redirect HTTP to HTTPS by default" is set to "Yes". After creating a new virtual server, on the "Aliases and Redirects" page, paths are automatically set to:

  • "Regexp URL redirects" ---> "From": /(?!.well-known)(.*)$

  • "Regexp URL redirects" ---> "Status": empty

  • "Regexp URL redirects" ---> "To": https://<DOMAIN-NAME>/$1

Where <DOMAIN-NAME> is your domain name

For those not familiar with "Aliases and Redirects", it is located at Virtualmin ---> Services ---> Configure Website ---> "Aliases and Redirects for <DOMAIN-NAME>:80"

If you either add or change a redirect on an already existing virtual server, for the redirect to be effective, you need to restart Apache

Submitted by JamieCameron on Thu, 08/24/2017 - 21:54

Someone else reported a similar issue yesterday - it turns out that there is a bug in the way the whole-domain redirect is setup by Virtualmin that can break Let's Encrypt. This will be fixed in the next release.