Does this service attempt to verify over http?

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 ?

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!

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.

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.

No problem, thanks for the update!

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

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

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

[TheDevFreak]

@ismay not on my site!