[solved] Manual http to https rewrite/redir

Help
1

Because I am using a letsencrypt wildcard cert generated by certbot according to docs caddy won’t do automatic http rewrite. Fine but when I do it I get a directive error for r.

Error during parsing: Unknown directive 'r'

FYI, without rewrite section I get no errors and caddy starts.

My Caddyfile

(wildcard_cert) {
    tls /etc/letsncrypt/live/xxxx.net/cert.pem /etc/letsncrypt/live/xxxx.net/privkey.pem  {
        wildcard
    }
}

nas.xxxx.net:8090 {
    import wildcard_cert
    root /mnt/data/test
}

rewrite {
	     r ^(http:\/\/)(.*)
	     to     https://{2}
}
2

Getting closer but the http to https rewrite is not working (although no directive error).
The log to stdout logs nothing about the rewrite so I have no idea if it’s ignored or flawed or what.

the commented lines are my various attempts.

Any help here? Wondering if I should be using a redir instead

(wildcard_cert) {
    tls /etc/letsncrypt/live/kebler.net/cert.pem /etc/letsncrypt/live/kebler.net/privkey.pem  {
        wildcard
    }
}

nas.kebler.net:80 {
log stdout
rewrite {
      # r ^(http:\/\/)(.*)
     # to https://{2}
     to  https://{path}
      }
  }

https://nas.kebler.net {
root /mnt/data/webs/main
import wildcard_cert
}
3

Despite community silence on my post (nobody in the know following new posts?) it seems I’ve solved it myself using redir.

(wildcard_cert) {
    tls /etc/letsncrypt/live/kebler.net/cert.pem /etc/letsncrypt/live/kebler.net/privkey.pem  {
        wildcard
    }
}

# works for any subdomain
*.kebler.net:80 {
log stdout
redir https://{label1}.kebler.net{uri}
}

https://nas.kebler.net {
root /mnt/data/webs/main
import wildcard_cert
}
4

It’s not the biggest community, and sometimes the volunteers don’t manage to get around to helping out every request inside of 24hrs (the developer offers 1-2day turnaround basic email support for their commercial licenses, same-day response for extended support).

That solution is a good one. Here’s an alternate approach with a single site definition:

http://example.com, https://example.com {
  import wildcard_cert
  root /mnt/data/webs/main
  redir {
    if {scheme} is HTTP
    / https://{host}{uri}
  }
}
5

Hey @Whitestrake

What’s better? {scheme} or {>X-Forwarded-Proto}? I remember months ago, my post about global redirect and your suggestion was {>X-Forwarded-Proto}.

6

This is 100% dependent on whether Caddy is at the edge or not. {scheme} will pick up whatever the client connecting to Caddy used, and it’ll always be available; if it’s being directly connected to by your users, it’s the only one that matters.

On the other hand, there’s no guarantee that {>X-Forwarded-Proto} will be there - it’s only used as a common standard for transparent proxies. But if you know it’ll be there - maybe because Caddy is behind another proxy you’ve configured to send that header - and you want to dictate how the actual user connects, use that instead.

1 Like
7

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