Does this service attempt to verify over http?

[ismay]

I'm using this service in my coreos cloud config. Currently it works just fine, but I've been having some issues with docker-letsencrypt-nginx-proxy-companion trying to verify certificates in the .well-known directory over http. Is that correct?

Also, nginx-proxy (or this container) seems to then redirect the request to https. Is that correct as well? I'm asking since it wasn't clear to me from the documentation, and it would be helpful for me to know what the intended behaviour is, so that I can set up my cloudflare page rules correctly.

[buchdag]

Hi,

Do you mean the container self verification or the (external) verification made by Lets Encrypt ?

[ismay]

Hi @buchdag, I mean the verification that certbot does, where it checks if there is a file in www.domain-i-want-to-verify.com/.well-known/acme-challenge/random-filename.

I just now found some documentation stating that certbot does indeed verify over http (which makes sense), https://certbot.eff.org/docs/using.html#webroot.

So what I'm now wondering, does the standard configuration of https://github.com/jwilder/nginx-proxy coupled with this container redirect all http requests to https? Also the ones to domain.com/.well-known? Because it looks like that's what's happening in my case.

[buchdag]

Yes, the standard configuration (which depends on nginx.tmpl) does redirect http requests to https BUT the Lets Encrypt validation server does not follow redirections to https when attempting to validate a challenge over http.

[cpu]

@buchdag I think you might have misinterpreted my comment a little bit :-) Boulder does follow redirections from HTTP to HTTPS. I was saying it ignored certificate validation after being redirected. Hope that helps clarify!

[ismay]

Ok, so I can expect certbot to be redirected to https when using the standard config and then attempt to validate a file in https://domain.com/.well-known/acme-challenge? Just so I understand what's going on.

[buchdag]

@cpu > I remembered you said it ignored cert validation, went to your comment to verify, and manage to read a "don't" that isn't there. derp.

@ismay > I'm not so sure of that. The redirection to https only happens if a certificate and key corresponding to the domain exists when docker-gen create the default.conf and reloads nginx.

The old certificates / keys, if they exist, should be deleted and nginx reloaded through docker-gen just before certificate creation or renewal, so all challenge validations should happen over http.

[ismay]

I'm not so sure of that. The redirection to https only happens if a certificate and key corresponding to the domain exists when docker-gen create the default.conf and reloads nginx.
The old certificates / keys, if they exist, should be deleted and nginx reloaded through docker-gen just before certificate creation or renewal, so all challenge validations should happen over http.

Ok cool, thanks for clarifying, that helps a lot! I'll update my config accordingly. Thanks for the help!

[buchdag]

My bad, I completely misread the linked code yesterday, what is deleted are certificates of a given type (test or non test) if you ask for a certificate of the other type.

So challenge validation should happen over http:

• on first creation of a certificate no matter the type
• on creation of a non test certificate if a previous test certificate for the same domain was created
• on creation of a test certificate if a previous non test certificate for the same domain was created

Challenge validation should happen over https on renewal of a certificate by a certificate of the same type.

Sorry for yesterday misinformation.

[ismay]

No problem, thanks for the update!

[ismay]

Ok, so just got this reply from cloudflare about this issue:

This redirect is happening at your origin webserver which is why the redirect loop occurred:

curl -sv -o /dev/null http://ismaywolff.nl/.well-known/acme-challenge/ECcBmzPPHFbyyTEgdAJL3cJVrvIfepvmMb3oqoGX9UI --resolve ismaywolff.nl:80:138.68.122.12

< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.13.3
< Date: Tue, 15 Aug 2017 09:12:29 GMT
< Content-Type: text/html
< Content-Length: 185
< Connection: keep-alive
< Location: https://ismaywolff.nl/.well-known/acme-challenge/ECcBmzPPHFbyyTEgdAJL3cJVrvIfepvmMb3oqoGX9UI

This meant Cloudflare was redirecting https --> http, but your origin was redirecting http --> https so this was looping.

You would need to remove the redirect at your origin to resolve this issue.

So this means that in the end all requests would end up going over https, regardless of if they're attempted over http at first.

(This issue was originally about a redirect loop, which is what the cloudflare engineer is referring to. That's been solved by removing the redirect on cloudflare). Maybe it might be good to remove the automatic redirect for the .well-known folder so a request over http is possible?

[TheDevFreak]

@ismay I'm currently having this issue, how did you manage to remove the redirect at cloudflare?

I've turned off SSL + rewrite http to https at CF but i am still encountering the problem

[ismay]

What I did for cloudflare:

• Always use https: off
• Hsts: off
• Opportunistic encryption: off
• Automatic https rewrites: on

Add a page rule:

• For: *ismaywolff.nl/.well-known/*
• With: Disable Security, Cache Level: Bypass, Automatic HTTPS Rewrites: Off

For my docker config see my cloud config above.

[TheDevFreak]

Hmm, I cant find "Opportunistic encryption" as an option anywhere. neither can i find always use https. still getting stuck in a 301 loop

[ismay]

Weird. It's in the cloudflare settings for me. Under encryption I believe

[TheDevFreak]

@ismay not on my site!

[TheDevFreak]

Ah! the option appears after enabling cloudflare's SSL

[TheDevFreak]

That's done it! thanks.

[pcjmfranken]

Sorry for the necro but I'm having some issues with Cloudflare atm.

My site works fine - even in HTTPS - with the Cloudflare CDN turned off (grey cloud), but when the CDN is enabled (orange cloud) I get ERR_SSL_VERSION_OR_CIPHER_MISMATCH errors.

I have Cloudflare SSL as well as all the HTTPS redirect settings mentioned in previous comments turned off.

It would be wonderful if anyone could tell me what I'm doing wrong.

[mich2k]

Having the same issue, @pcjmfranken did you manage to solve this?

[pcjmfranken]

There turned out to be two separate causes producing that same error across various sites:

The first one was due to a Cloudflare misconfiguration which I managed to fix with some help of this post on their support forums: https://community.cloudflare.com/t/step-2-setting-up-ssl-with-cloudflare/94646. First check if the site loads over HTTPS when the Cloudflare cloud thingy is set to grey, leave the cloud on the grey setting for now, then in your Cloudflare dashboard set the "SSL/TLS encryption mode" to "Full (strict)", then enable "Always Use HTTPS", then set the cloud to orange mode, pray to the orange cloud spirits while you wait for them to do their thing, and then profit, hopefully.

The second one boils down to some mistakes in my override configs causing these long, inefficient, and problematic redirect chains that Cloudflare refused. Checking out the redirect chains for all the variations on your url might be worth doing - just FYI browsers might modify/normalise some of those variations in the address bar before the request is sent, something like curl would work better for this if you're familiar with it.

Let me know how things work out!