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 ?
Well I still get the letsencrypt error: Failed authorization procedure. interndemo.sfg-singen.de (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to http://interndemo.sfg-singen.de/.well-known/acme-challenge/f1ooD18w2PdWwZcTL8QdELNBCbrihcTTXR97ryoicaE
Additional path information beyond the matched URL-Path will be appended to the target URL.
Keyword here is additional: as your URL-path is a single slash /, the .well-known/acme-challenge/foobar is the additional part. Without the slash. And as your URL doesn't contain a trailing slash, it all goes awry.
Ah.. Good to know Curious though why CURL did work in the mean time, while that didn't work before... Or perhaps it was the combination of both: the added slash in the Redirect directive (I'm assuming you didn't roll back that change?) ánd the fixed Alias?
No my alias looked like that before: Alias /.well-known/acme-challenge /var/www/letsencrypt
I created the test file in /var/www/letsencrypt. But I also thought that LE puts the files directly in there but it actually creates the subfolders. That’s why I got a 404 in the end.