[Webroot] Only performs http-01 challenge which doesn't follow HTTP redirects to HTTPS site

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

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..

This is pretty strange, I just did a validation with RedirectPermanent activated against the live server and here are my log:

letsencrypt.example.com:80 66.133.109.36 - - [04/Dec/2015:22:32:14 +0000] "GET /.well-known/acme-challenge/VioViw79I_0eLxhK1WGPBxK-XCPw-OWSjGA_sC6mo2g HTTP/1.1" 301 675 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"
letsencrypt.example.com:443 66.133.109.36 - - [04/Dec/2015:22:32:15 +0000] "GET /.well-known/acme-challenge/VioViw79I_0eLxhK1WGPBxK-XCPw-OWSjGA_sC6mo2g HTTP/1.1" 200 2505 "http://letsencrypt.example.com/.well-known/acme-challenge/VioViw79I_0eLxhK1WGPBxK-XCPw-OWSjGA_sC6mo2g" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

Precision: the web server is configured to serve self-signed certificate, with name mismatch.

If you see no tls connection with tcpdump, this make me think of some firewall interfering.

With what letsencrypt command line did you manage that? :open_mouth:

Because I’m very, very sure my server is accessible by TLS… Otherwise SSLLabs wouldn’t give it an A+ I recon :wink:

Well the usual letsencrypt command:

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.

Le Uses Firefox? LOL!

With the risk feeding the troll: https://en.wikipedia.org/wiki/User_agent#Format_for_human-operated_web_browsers

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.

Sure sure… But even if your point is sound, practically every bot out there uses this scheme… And it’s quite off topic… So… :confused:

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.

Here I created a certificate without having a redirect enabled, that works flawlessly: https://www.ssllabs.com/ssltest/analyze.html?d=interndemo.sfg-singen.de

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.

I created a test file which is accessible:
https://interndemo.sfg-singen.de/.well-known/acme-challenge/test

http://interndemo.sfg-singen.de/.well-known/acme-challenge/test

However, with http it gets redirected to http://interndemo.sfg-singen.de.well-known/acme-challenge/test

I have no idea why :frowning:

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 ?

This is not a solution and only a workaround. If it doesn’t work, your redirect doesn’t work properly.

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

Because your redirects are broken and miss a / before .well-known.

 $ http "http://interndemo.sfg-singen.de/.well-known/acme-challenge/f1ooD18w2PdWwZcTL8QdELNBCbrihcTTXR97ryoicaE"

results in:

Location: https://interndemo.sfg-singen.de.well-known/acme-challenge/f1ooD18w2PdWwZcTL8QdELNBCbrihcTTXR97ryoicaE

This is how my config looks like:

<VirtualHost *:80> ServerName interndemo.sfg-singen.de Redirect 302 / https://interndemo.sfg-singen.de </VirtualHost>

Try adding an extra / to the end of your Redirect directive?

From the documentation:

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.

1 Like

I did that, with the letsencrypt client it still won't work but in curl the redirect and everything works:

`curl -Lv http://interndemo.sfg-singen.de/.well-known/acme-challenge/test

  • Hostname was NOT found in DNS cache
  • Trying 176.9.146.143...
  • Connected to interndemo.sfg-singen.de (176.9.146.143) port 80 (#0)

GET /.well-known/acme-challenge/test HTTP/1.1
User-Agent: curl/7.38.0
Host: interndemo.sfg-singen.de
Accept: /

< HTTP/1.1 302 Found
< Date: Wed, 16 Dec 2015 13:58:10 GMT

  • Server Apache/2.4.10 (Debian) is not blacklisted
    < Server: Apache/2.4.10 (Debian)
    < Location: https://interndemo.sfg-singen.de/.well-known/acme-challenge/test
    < Content-Length: 338
    < Content-Type: text/html; charset=iso-8859-1
    <
  • Ignoring the response-body
  • Connection #0 to host interndemo.sfg-singen.de left intact
  • Issue another request to this URL: 'https://interndemo.sfg-singen.de/.well-known/acme-challenge/test'
  • Found bundle for host interndemo.sfg-singen.de: 0x7f53416d4550
  • Hostname was NOT found in DNS cache
  • Trying 176.9.146.143...
  • Connected to interndemo.sfg-singen.de (176.9.146.143) port 443 (#1)
  • successfully set certificate verify locations:
  • CAfile: none
    CApath: /etc/ssl/certs
  • SSLv3, TLS handshake, Client hello (1):
  • SSLv3, TLS handshake, Server hello (2):
  • SSLv3, TLS handshake, CERT (11):
  • SSLv3, TLS handshake, Server key exchange (12):
  • SSLv3, TLS handshake, Server finished (14):
  • SSLv3, TLS handshake, Client key exchange (16):
  • SSLv3, TLS change cipher, Client hello (1):
  • SSLv3, TLS handshake, Finished (20):
  • SSLv3, TLS change cipher, Client hello (1):
  • SSLv3, TLS handshake, Finished (20):
  • SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
  • Server certificate:
  •    subject: CN=interndemo.sfg-singen.de
    
  •    start date: 2015-12-16 09:42:00 GMT
    
  •    expire date: 2016-03-15 09:42:00 GMT
    
  •    subjectAltName: interndemo.sfg-singen.de matched
    
  •    issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X1
    
  •    SSL certificate verify ok.
    

GET /.well-known/acme-challenge/test HTTP/1.1
User-Agent: curl/7.38.0
Host: interndemo.sfg-singen.de
Accept: /

< HTTP/1.1 200 OK
< Date: Wed, 16 Dec 2015 13:58:10 GMT

  • Server Apache/2.4.10 (Debian) is not blacklisted
    < Server: Apache/2.4.10 (Debian)
    < Last-Modified: Wed, 16 Dec 2015 11:46:22 GMT
    < ETag: "1d-52702748b8057"
    < Accept-Ranges: bytes
    < Content-Length: 29
    < Content-Type: application/jose+json
    <
    Wed Dec 16 12:46:22 CET 2015
  • Connection #1 to host interndemo.sfg-singen.de left intact`

What’s the LE log now? That’s more interesting.

OMG my alias was wrong… I missed that letsencrypt actually creates those directories. Now my config looks like this:

Alias /.well-known/acme-challenge /var/www/letsencrypt/.well-known/acme-challenge

So it is working now! But it also works without the additional / in the end.

Ah.. Good to know :stuck_out_tongue: 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.