Help with reverse_proxy redirect with SSO login domain

1. The problem I’m having:

Hello guys, I’m building a webapp that uses SSO for login which is quite simple.
I press a button on my website, the user gets redirected to a provider (let’s say https://mylogin.com. There, he inputs his credentials. The provider then browser redirects the user to the dev environment of my website, and sends me a JWT token in the url param. Let’s say my website is deployed at https://dev.myapp.com.

What I’m trying to do is use Caddy as a reverse proxy so that when the provider redirects the user to https://dev.myapp.com, the user gets redirected to localhost:3000 instead. The purpose is to be able to test the flow locally and be able to login in my local environment.

tl;dr I want to write https://dev.myapp.com and get redirected to localhost:3000

2. Error messages and/or full log output:

2024/01/19 14:56:48.170	ERROR	http.acme_client	challenge failed	{"identifier": "dev.myapp.com", "challenge_type": "tls-alpn-01", "problem": {"type": "urn:ietf:params:acme:error:unauthorized", "title": "", "detail": "Cannot negotiate ALPN protocol \"acme-tls/1\" for tls-alpn-01 challenge", "instance": "", "subproblems": []}}
2024/01/19 14:56:48.170	ERROR	http.acme_client	validating authorization	{"identifier": "dev.myapp.com", "problem": {"type": "urn:ietf:params:acme:error:unauthorized", "title": "", "detail": "Cannot negotiate ALPN protocol \"acme-tls/1\" for tls-alpn-01 challenge", "instance": "", "subproblems": []}, "order": "https://acme-staging-v02.api.letsencrypt.org/acme/order/133034164/13791164864", "attempt": 2, "max_attempts": 3}
2024/01/19 14:56:48.170	ERROR	tls.obtain	could not get certificate from issuer	{"identifier": "dev.myapp.com", "issuer": "acme-v02.api.letsencrypt.org-directory", "error": "HTTP 403 urn:ietf:params:acme:error:unauthorized - Cannot negotiate ALPN protocol \"acme-tls/1\" for tls-alpn-01 challenge"}
2024/01/19 14:56:49.420	ERROR	tls.obtain	could not get certificate from issuer	{"identifier": "dev.myapp.com", "issuer": "acme.zerossl.com-v2-DV90", "error": "[dev.myapp.com] solving challenges: authz https://acme.zerossl.com/v2/DV90/authz/ykH4wMHPJsuasPR7Tt9KLw has unexpected status; order will fail: invalid (order=https://acme.zerossl.com/v2/DV90/order/6ZwW-j1fZm8RNYsRGP_VlA) (ca=https://acme.zerossl.com/v2/DV90)"}
2024/01/19 14:56:49.420	ERROR	tls.obtain	will retry	{"error": "[dev.myapp.com] Obtain: [dev.myapp.com] solving challenges: authz https://acme.zerossl.com/v2/DV90/authz/ykH4wMHPJsuasPR7Tt9KLw has unexpected status; order will fail: invalid (order=https://acme.zerossl.com/v2/DV90/order/6ZwW-j1fZm8RNYsRGP_VlA) (ca=https://acme.zerossl.com/v2/DV90)", "attempt": 4, "retrying_in": 300, "elapsed": 351.18008261, "max_duration": 2592000}


3. Caddy version:

v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=

4. How I installed and ran Caddy:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

a. System environment:

Linut Mint LTS.

b. Command:

sudo caddy reverse-proxy --from dev.myapp.com --to localhost:3000 --change-host-header

c. My complete Caddy config:

{"apps":{"http":{"servers":{"srv0":{"listen":[":80"],"routes":[{"handle":[{"handler":"vars","root":"/usr/share/caddy"},{"handler":"file_server","hide":["/etc/caddy/Caddyfile"]}]}]}}}}}

5. Links to relevant resources:

https://caddyserver.com/docs/automatic-https#issuer-fallback

That’s not a redirect, that’s proxying. Different concepts.

Caddy is failing to get a certificate for your domain. Do you have ports 80 and 443 open and forwarded to your dev machine? Do you have DNS set to your WAN IP?

If not you probably want to enable --internal-certs to have Caddy issue a cert using its internal CA.

But really, I recommend you use a Caddyfile. The CLI is very limited in what you can do with it.

1 Like

Thanks for your answer!

That’s not a redirect, that’s proxying. Different concepts.

Oh yes, my bad.

If not you probably want to enable --internal-certs to have Caddy issue a cert using its internal CA.

Ok, I tried creating a caddy file to test it out.

The content is this:

myexample.com {
    reverse_proxy localhost:3000
    tls internal
}

The caddy terminal after I start caddy looks like this:

sudo caddy run -c /etc/caddy/Caddyfile 
2024/01/21 20:17:36.048	INFO	using provided configuration	{"config_file": "/etc/caddy/Caddyfile", "config_adapter": ""}
2024/01/21 20:17:36.048	WARN	Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies	{"adapter": "caddyfile", "file": "/etc/caddy/Caddyfile", "line": 2}
2024/01/21 20:17:36.049	INFO	admin	admin endpoint started	{"address": "localhost:2019", "enforce_origin": false, "origins": ["//localhost:2019", "//[::1]:2019", "//127.0.0.1:2019"]}
2024/01/21 20:17:36.049	INFO	tls.cache.maintenance	started background certificate maintenance	{"cache": "0xc0001d8a00"}
2024/01/21 20:17:36.049	INFO	http.auto_https	server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS	{"server_name": "srv0", "https_port": 443}
2024/01/21 20:17:36.049	INFO	http.auto_https	enabling automatic HTTP->HTTPS redirects	{"server_name": "srv0"}
2024/01/21 20:17:36.055	INFO	pki.ca.local	root certificate is already trusted by system	{"path": "storage:pki/authorities/local/root.crt"}
2024/01/21 20:17:36.055	INFO	http	enabling HTTP/3 listener	{"addr": ":443"}
2024/01/21 20:17:36.055	INFO	http.log	server running	{"name": "srv0", "protocols": ["h1", "h2", "h3"]}
2024/01/21 20:17:36.055	INFO	http.log	server running	{"name": "remaining_auto_https_redirects", "protocols": ["h1", "h2", "h3"]}
2024/01/21 20:17:36.055	INFO	http	enabling automatic TLS certificate management	{"domains": ["myexample.com"]}
2024/01/21 20:17:36.056	WARN	tls	stapling OCSP	{"error": "no OCSP stapling for [myexample.com]: no OCSP server specified in certificate", "identifiers": ["myexample.com"]}
2024/01/21 20:17:36.056	INFO	autosaved config (load with --resume flag)	{"file": "/root/.config/caddy/autosave.json"}
2024/01/21 20:17:36.056	INFO	serving initial configuration
2024/01/21 20:17:36.060	WARN	tls	storage cleaning happened too recently; skipping for now	{"storage": "FileStorage:/root/.local/share/caddy", "instance": "528b761a-294f-485b-8ffb-c5c118250c18", "try_again": "2024/01/22 20:17:36.060", "try_again_in": 86399.99999973}
2024/01/21 20:17:36.060	INFO	tls	finished cleaning storage units

If I visit https://myexample.com with my browser, I don’t get proxied to localhost:3000.

If I telnet to myexample 80 or 443, I don’t get proxied to localhost:3000

Am I thinking something the wrong way?? Shouldn’t this work?

But what behaviour are you actually seeing? Saying “it doesn’t work” doesn’t give us any clues as to the problem.

Caddy is an HTTP server, using telnet won’t do anything unless you write an HTTP request to the connection.

Try with curl -v and show what you get.

Add the debug global option to your Caddyfile, then make a request and show your logs.

You mean you’re testing SSO intergration locally. You want to visit https://dev.myapp.com and get redirected to localhost:3000 for login requests?

You’ll need to set this up on https://dev.myapp.com then, also it needs to be able to connect to your localhost:3000, which means you’ll deploy that site locally. The whole workflow of SSO involves the user, your service and your SSO server, and they all need to be connected.

By the way, you should use internal ssl issuer in this case.

But what behaviour are you actually seeing? Saying “it doesn’t work” doesn’t give us any clues as to the problem.

For example, If I visit https://myexample.com, I just visit the actual existing website instead of being proxied to my localhost:3000 server. It seems like caddy is not “intercepting” the request.

What I did to fix this is that I put in my /etc/hosts file a redirect rule for myexample.com to go to my localhost. Then with caddy, I redirect port 80 to 3000. This seems to have did the trick and now it’s working as I want it.

Unfortunately I don’t have access to https://dev.myapp.com since it’s a 3rd party client’s of ours so that’s not an option.

In my above comment you can check the solution I found, if you’d like to comment on it. Thank you very much!

It’s still unclear what you mean by this. Please show an example request with curl -v.

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