Redirect HTTP to HTTPS - which approach is better?

The technique described in this blog post under the heading "I want HTTPS redirection!" is done in the dynamic configuration, whereas there's also the following approach via static/startup configuration:

"--entryPoints.web.http.redirections.entryPoint.to=websecure"
"--entryPoints.web.http.redirections.entryPoint.scheme=https"

Is one approach "better" than the other?

Also, does the Let's Encrypt ACME challenge require HTTP, or can it be done over HTTPS? If the former and http --> https redirection is in place, how can it succeed? And if the latter, and redirection is in place, how does LE access a secure URL that has no cert in order to generate the initial cert?

1 Like

Hi,

Sorry maybe this is not your answer, but from what I tried

--entryPoints.web.http.redirections.entryPoint.to=websecure

The redirection is work, but somehow there will be /tcp/ appended in the url

curl -I http://some-address.com
HTTP/1.1 308 Permanent Redirect
Location: https://some-address.com:443/tcp/

When I use this

--entryPoints.web.http.redirections.entryPoint.scheme=https

the redirection doesn't works on my setup

Do you have same issue, or both of the static configuration are working on your setup?

Hi @shot

That blog post was October 2019 the 2.2 release in March introduced the EntryPoint Defaults.

Better? I think so. If you have no intention of doing http(and why would you these days) then this becomes one of your default parameters.

You can specify either httpChallenge or tlsChallenge for the certificate resolver. Don't forget dnsChallenge too.

The httpChallenge documentation states:

Redirection is fully compatible with the HTTP-01 challenge.

It is part of the acme-tls/1 Protocol Definition. This is very useful in scenarios where you may not have port 80 available.

While this protocol uses X.509 certificates, it does not use the authentication method described in [RFC5280] and, as such, does not require a valid signature on the provided certificate nor require the TLS handshake to complete successfully.

In my experience, both static config values are required for redirection to work. That's ONE approach. The OTHER approach is described in the blog post I referenced. My question was simply about which approach is better and why. I just don't understand why there are seemingly 2 different means to the same end.

I know you were not replying to me as I posted in the same minute. But an answer for you none the less.

From the 2.2 release post:

As a result, you told us that the configuration ended up being a bit too verbose, and that you're missing some sort of redirects on Entrypoints, as we had something similar with Traefik 1.x.

For that reason, we introduced the concepts of Entrypoint redirects, and default router configuration.

Ok, thanks for the clarification, @cakiwi. So basically, the blog post is outdated with regard to Traefik 2.2. Got it.

Aha, I didn't' catch that. So I should enable http --> https redirect and then specify tlsChallenge - not httpChallenge.

Just so I'm clear on this, you're saying that's an alternative approach to http or tlsChallenge, right? Or do I have to enable that as well? I currently get the LE "fake" cert as described in the docs, so I'm guessing it'll work once I disable the staging URL, right?

Thanks for the help.

I use tlsChallenge. If you have an entryPoint on port 80 you could stick with httpChallenge too. The only must in terms of letsencrypt is the httpChallenge(HTTP-01) has to be port 80 and the tlsChallenge(TLS-ALPN-01) on port 443. It is really up to you.

Yes just one of the options you have.

1 Like

I totally missed this the first time around...

1 Like