As I’m unable to get an automated client running for Apache, as the Let’s Encrypt client is depending on some custom scripts from Debian (-based) distributions (and Gentoo doesn’t include those), I’m trying to run the client with the webroot plugin. And as I’m not needing the whole Apache-part, I thought to myself: I won’t be running the client as root. So far so good.
Root (sudo) is required to run most of letsencrypt functionality.
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Generating key (4096 bits):
/home/osiris/letsencrypt/keys/0005_key-letsencrypt.pem
Creating CSR: /home/osiris/letsencrypt/csr/0005_csr-letsencrypt.pem
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Performing the following challenges:
http-01 challenge for ${domain}
http-01 challenge for www.${domain}
Waiting for verification...
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Reporting to user: The following 'urn:acme:error:connection' errors
were reported by the server:
Domains: ${domain}, www.${domain}
Error: The server could not connect to the client for DV
Unfortunately, everything with --tls-sni-01 seems to fail or not do anything… --standalone-supported-challenges tls-sni-01 doesn’t influence the Webroot plugin obviously.
My server does give a HTTP 301 redirect, but the ACME server doesn’t do anything with that aparently… Not according to my Apache logs nor according to tcpdump… No TLS connection what so ever.
Is this something by design or something that could be implemented in the future? Or am I missing a command line option?
Oh, by the way, webroot.py did have something about TLS in it’s history, but aparently it’s stripped away in the current master webroot.py… No TLS what so ever when I search for it
I'm trying to exclude the path /.well-known/acme-challenge/ from the redirect, but I'm using the Redirect directive and I'm having difficulties with that.. An empty <Location "/.well-known/acme-challenge/"></Location> doesn't "cancel" out the Redirect set somewhere else I'm afraid..
Ofcourse, it would be rather simpel with mod_rewrite.. But I'm hoping it's possible without such a heavy mechanism for something rather.. simple..
As @jmorahan already mentioned, if you configure your webserver to not only redirect HTTP-URLs to the https://yourdomain.com/ but to the exact path the user or in this case lets encrypt is requesting, it will succeed. We have several domains forcing the use of TLS that way and it worked like a charm.
Here would be (one) example of how to do that on nginx: return 301 https://$server_name$request_uri;
Never quite understood regexes, always a pain in the ()#$()#* when I want to implement one.. For example, I had no idea what the (?!foo) syntax was.. Apparently this is something called negative lookahead. I recon a fancy PCRE regex substitution for a 'logical not' or something
Ah well, as long as it works.. Let's see what the Let's Encrypt client thinks
Hmm, removed the “Solution”-mark, because I’m interested in a discussion about whether or not the client should support TLS anyway and perhaps the mentioned ‘solution’ is just a workaround
The acme server when performing http-01 challenge do follow http redirects to https.
So I think that you may have a broken redirect, a redirect to another host, or maybe some other configuration which hide the challenge folder in your apache config files.
Check all logs of apache usually in /var/log/apache2
Ofcourse I've checked all kinds of logs, even tcpdump: no TLS incoming connections were made what so ever. And the redirect works, I've checked that also ofcourse, manually and in the browser..
Didn't see your previous post, sorry: yes, my server is accessible from the outside world on port 443, both IPv4 and IPv6
I'm going to accept the aformentioned solution as a solution anyway, as the SimpleHTTPS challenge for the Webroot plugin was removed for a reason, as I found out from this post: Preventing Letsencrypt 3rd party clients going the Android way? - #29 by My1
Seems to be a vulnerability with default TLS vhosts and SNI: that way a misconfigured host apparently could 'steal' the domain validation or something..
path_to_letsencrypt -d letsencrypt.example.com
I performed a letsencrypt-auto -v, to check if my version was up to date.
with this config file:
#
rsa-key-size = 4096
# Now live so default is this server.
#server = https://acme-v01.api.letsencrypt.org/directory
email = admin@example.com
agree-tos = true
# Do not use ugly curse interface
text = true
# Webroot challenge
authenticator = webroot
webroot-path = /var/www/letsencrypt
Apart some weird blacklist on 443 of the acme server I’m out of idea.
There might be strange behaviour with ipv6 and ipv4, but I highly doubt that. My server is ipv4 only.
since when is the LE browser human operated? LE is CLEARLY automatic.
also here it says Mozilla was PREVIOUSLY used to indicate compatibility with it, rather than just stating “I am compatible with HTML5” or whatever, what would be more usefulthe browser makers are at fault on their own using Mozilla in the agent just to get around the issues they caused themselves is plain cheating, and still it is previous so each browser should be honest, and mozilla be only denoted in actual browsers of Mozilla.
As I’m getting the same error I’d be interested what apache configuration entry triggers that kind of error. I understand that the workaround works. It does for me too. But I have no indication that my configuration could be somehow misconfigured. I’m also using 301 redirects.
However, when I enable the redirect I get the error again.
In the apache error log I can only find the entry: [Wed Dec 16 12:41:08.152193 2015] [core:info] [pid 10075] [client 66.133.109.36:59143] AH00128: File does not exist: /var/www/letsencrypt/DK1Kwm_ZlZPDXNg7AnB2bWu5Iyh9nwQVGzkNRHMn9k0
But when I check the directory with watch -n .1 ls I can see the file is created and is removed as soon as LE throws the error.
both http and https go to the correct https version for me. Do you need to clear your local cache when checking ? or have you already corrected the issue ?
