Redirect HTTPS (443) to HTTP (80)? Traefik v2

I'm having a bit of an unorthodox requirement, but it's simple to put into words:

I want to redirect HTTPS (websecure) to HTTP (web) and I can't, by any means, get it to function.
The other way around works, though! Alas, not what I want.

So, two docker-compose.yml files that we can discuss around:

Traefik docker-compose.yml:

version: '3.8'

services:
    reverse-proxy:
    ⦙   image: traefik:v2.3
    ⦙   command:
    ⦙   ⦙   - "--log.level=DEBUG"
    ⦙   ⦙   - "--log.filepath=/etc/traefik/log/traefik.log"
    ⦙   ⦙   - "--api.insecure=true"
    ⦙   ⦙   - "--api.debug=true"
    ⦙   ⦙   - "--providers.docker=true"
    ⦙   ⦙   - "--providers.docker.exposedbydefault=false"
    ⦙   ⦙   - "--providers.docker.network=reverse_proxy_network"
    ⦙   ⦙   - "--entrypoints.web.address=:80"
    ⦙   ⦙   - "--entrypoints.websecure.address=:443"
    ⦙   ⦙   - "--accesslog=true"
    ⦙   ports:
    ⦙   ⦙   # The HTTP port
    ⦙   ⦙   - "80:80"
    ⦙   ⦙   - "443:443"
    ⦙   ⦙   # The Web UI (enabled by --api.insecure=true)
    ⦙   ⦙   - "8080:8080"
    ⦙   networks:
    ⦙   ⦙   - default
    ⦙   volumes:
    ⦙   ⦙   # So that Traefik can listen to the Docker events
    ⦙   ⦙   - /var/run/docker.sock:/var/run/docker.sock
    ⦙   ⦙   - /opt/traefik/acme:/etc/traefik/acme
    ⦙   ⦙   - /opt/traefik/log:/etc/traefik/log
networks:   
    default:
    ⦙   external:
    ⦙   ⦙   name: reverse_proxy_network

The service docker-compose.yml

version: '3.8'

services:
    my-redirect:
    ⦙   image: nginx:alpine
    ⦙   ports:
    ⦙   ⦙   - "8888:8080"
    ⦙   volumes:
    ⦙   ⦙   - ./src:/src
    ⦙   ⦙   - ./default.conf:/etc/nginx/conf.d/default.conf
    ⦙   networks:
    ⦙   ⦙   - default
    ⦙   ⦙   - my-redirect
    ⦙   labels:
    ⦙   ⦙   - "traefik.enable=true"
    ⦙   ⦙   # this (if it ever works) takes care of specific https -> http redirects
    ⦙   ⦙   - "traefik.http.routers.my-redirect.entrypoints=websecure"
    ⦙   ⦙   - "traefik.http.routers.my-redirect.rule=host(`my-redirect.net`) || host(`www.my-redirect.net`)"
    ⦙   ⦙   - "traefik.http.middlewares.my-redirect-http-redirect.redirectscheme.scheme=http"
    ⦙   ⦙   - "traefik.http.routers.my-redirect.middlewares=my-redirect-http-redirect"

    php:
    ⦙   image: php:fpm-alpine
    ⦙   ports:
    ⦙   ⦙   - 9000:9000
    ⦙   volumes:
    ⦙   ⦙   - ./src:/src
    ⦙   networks:
    ⦙   ⦙   - my-redirect

networks:
    default:
    ⦙   external:
    ⦙   ⦙   name: reverse_proxy_network
    my-redirect:
    ⦙   driver: bridge

When I, with curl, hit http://my-redirect.net my traefik-container responds with:

"... GET / HTTP/1.1 404 ..."

curl echos:

"404 Not Found" as I would expect.

When I, with curl, hit https://my-redirect.net my traefik-container:

stays absolutely silent, no output whatsoever,

curl echoes:

"curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above."

and my Traefik-debug-log states:

"time="2020-10-04T13:46:17Z" level=debug msg="Serving default certificate for request: "www.my-redirect.net""
time="2020-10-04T13:46:17Z" level=debug msg="http: TLS handshake error from 192.168.1.1:35722: local error: tls: bad record MAC""

As you can tell, the redirect directives I have added are not taken into account; as soon as someone visits with https:// and not http:// the whole TLS dance starts.

How can I prevent Traefik doing anything except redirecting to HTTP for a specific site/service? I am suspecting it's not possible.... Also, I need this to work on a per-site basis, not as a general approach.

Thank you for any comments/tips/suggestions on figuring this out.

I think the only problem is you don't have a valid tls certificate. If you use -k with curl it should redirect as you expect.

For this to work with a browser you will need to add a valid certificate.

Yeah, I see where things are getting caught up.

Since browsers are conventionally expecting https:// to be handling some kind of encrypted traffic, it will not do anything other than check the validity and authenticity of the certificate first. If not satisfied, the connection is terminated and that's that.

cURL, rightfully so, follow the same convention when dealing with an https:// URL and go through the same due diligence.

Thanks for pointing me in the right direction here, I was going nuts by not being able to configure this.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.