You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my server set up, I initially set up the server with the firewall allowing HTTP traffic, but once SSL is set up, I'd like to close it up a bit by disabling HTTP completely. (Before traffic hits the server, there's a Cloudflare page rule that redirects HTTP traffic to HTTPS).
This setup should work with LetsEncrypt as well, because
"Let’s Encrypt follows redirects (HTTP 301 and 302) when performing HTTP-01 challenges, both to other domains and from http:// to https://" cite
However, where this falls down is that letsencrypt/tasks/nginx.yml calls the test_challenges module:
(It would need to use HTTPSConnection (note the 'S') to make an HTTPS connection.)
Would you consider updating the test_challenges module so it can make an HTTPS connection? I've whipped up a version of it that first tries via HTTP, and if status back isn't 200, it tries again over SSL. (In reality we'd perhaps want this to be configurable since not everyone will have that same HTTP->HTTPS redirect I have.)
A parallel suggestion would be to have that Ansible module return a bit more info so users could know, for example, the HTTP response code and/or headers they're getting back (because as others have noted, Cloudflare sometimes throws up blocks people may not realize are there, and one may need to disable the "browser integrity check" feature on the .well-known challenge location).
Thank you.
The text was updated successfully, but these errors were encountered:
Having the fallback HTTPS request seems fine to me.
In reality we'd perhaps want this to be configurable since not everyone will have that same HTTP->HTTPS redirect I have.
🤔 is there actually any downside though? Not sure I can think of a situation where the test failing on HTTP and then passing on HTTPS would actually be wrong.
A parallel suggestion would be to have that Ansible module return a bit more info so users could know
That would be useful too! Would you want do give that a try as well?
Not sure I can think of a situation where the test failing on HTTP and then passing on HTTPS would actually be wrong.
I think the ACME protocol says to use the HTTP port (and follow redirects if they are there); I don't think it says to also try over SSL? So, if someone does not have the redirect set up, then only responding to challenges of SSL/port 443 is not correct (as far as I can tell). But perhaps I need to dig into how the Python HTTPConnection works… I'm not sure why it isn't following the redirect.
Hi there,
In my server set up, I initially set up the server with the firewall allowing HTTP traffic, but once SSL is set up, I'd like to close it up a bit by disabling HTTP completely. (Before traffic hits the server, there's a Cloudflare page rule that redirects HTTP traffic to HTTPS).
This setup should work with LetsEncrypt as well, because
However, where this falls down is that
letsencrypt/tasks/nginx.yml
calls thetest_challenges
module:trellis/roles/letsencrypt/tasks/nginx.yml
Line 50 in c8f679e
and in that file, it only makes an HTTP request:
trellis/roles/letsencrypt/library/test_challenges.py
Line 50 in c8f679e
(It would need to use HTTPSConnection (note the 'S') to make an HTTPS connection.)
Would you consider updating the test_challenges module so it can make an HTTPS connection? I've whipped up a version of it that first tries via HTTP, and if
status
back isn't200
, it tries again over SSL. (In reality we'd perhaps want this to be configurable since not everyone will have that same HTTP->HTTPS redirect I have.)A parallel suggestion would be to have that Ansible module return a bit more info so users could know, for example, the HTTP response code and/or headers they're getting back (because as others have noted, Cloudflare sometimes throws up blocks people may not realize are there, and one may need to disable the "browser integrity check" feature on the .well-known challenge location).
Thank you.
The text was updated successfully, but these errors were encountered: