Wildcard help needed

[samcro1967]

Describe the issue

Trying to convert to wildcard certs. Used #79 to make changes to Caddyfile. Not getting any errors in the log, but only get a white screen when I go to the login page (https://auth.{$FQDN}.net). The wildcard with CloudFlare works fine for my test app that is not behind mypolicy so I feel good that caddy, CloudFlare, and the wildcard cert is working. Must have something now quite right in the security block, but now sure what it is.

Configuration

Paste full Caddyfile below:

{
	https_port	443
	email {$EMAIL}
	debug
	order authenticate before respond
	order authorize before basicauth
}
	security {
		credentials {$EMAIL} {
			username {$EMAIL}
			password {$CADDY_EMAIL_SECRET}
		}
		messaging email provider gmail {
			address {$SMTP}
			protocol smtp
			sender {$EMAIL}
			credentials {$EMAIL}
		}
		local identity store localdb {
			realm local
			path /config/caddy/users.json
		}
		user registration localdbRegistry {
			dropbox /config/caddy/registrations.json
			title "User Registration"
			code "{$CADDY_REG_CODE}"
			require accept terms
			require domain mx
			admin email {$EMAIL}
			email provider gmail
			identity store localdb
		}
		authentication portal myportal {
			enable source ip tracking
			cookie domain {$CLOUDFLARE_DOMAIN}
			cookie lifetime 86400
			crypto default token lifetime 86400
			crypto key sign-verify {$CRYPTO_KEY}
			#backend local /config/caddy/users.json local
			enable identity store localdb
			transform user {
				match origin local
				require mfa
				action add role authp/superadmin authp/user
			}
			ui {
			      password_recovery_enabled yes
			       links {
			            "My Identity" "/auth/whoami" icon "las la-user"
				}
			}
			transform user {
				exact match sub {$USER}
				action add role authp/superadmin
				ui link "Portal Settings" /auth/settings icon "las la-cog"
			}
		}
		authorization policy mypolicy {
			validate source address
			set auth url https://auth.samcro1967.net
			crypto key verify {$CRYPTO_KEY}
			allow roles authp/superadmin authp/user
		}
	}
}

*.{$FQDN}.net {
	tls {
		dns cloudflare {$CLOUDFLARE_API}
	}
	@auth host auth.{$FQDN}.net
        handle @auth {
		authenticate with myportal
	}
	@test host test.{$FQDN}.net
	handle @test {
		reverse_proxy 192.168.1.104:8092
	}
}

Version Information

Provide output of caddy list-modules -versions | grep git below:

security v1.1.5

[mholt]

	order authorize before basicauth
}

Did you mean to close the global options block there?

[samcro1967]

Extra brace I left when I removed logging in that section before posting to shorten the config. My Caddyfile is a few hundred lines. Was trying to pare it down to just the essentials. Below is the logging piece I removed which had the dangling brace.

{
	http_port	8069
	https_port	443
	email {$EMAIL}
	debug
	order realip first
	order authenticate before respond
	order authorize before basicauth
	log {
		output file /data/caddy.log
		format json {
			time_format "wall"
			level_format "upper"
        }
    }
	security {
		credentials {$EMAIL} {
			username {$EMAIL}
			password {$CADDY_EMAIL_SECRET}
		}
      ...

[greenpau]

@samcro1967 , what happens when you browse to “https://auth.%7B$fqdn%7D.net/auth/“

[samcro1967]

Below are the full configs of Caddyfile (minus caddy-docker-proxy labels) before and after. If I understand #79 correctly, it does not have a /auth after the FQDN. I tried both in the browser (with and without /auth) and get a blank white screen for both. My test app (hammond) works fine in both the before and after configs. I suspect trying to remove the /auth subdirectory is where I am getting wrapped around the axle and have made a mistake.

Working config before switching to wildcard
Link

Config after switching to wildcard
Link

[greenpau]

@samcro1967 , the one thing I am noticing is the mix of handle, route, individual directives (e.g. redir) and default route.

Please try removing all redir and route directives and report what you are getting.

Also, check why you have this redirect to login. It should go to auth.samcro1967.net:

	route {
		redir https://{hostport}/login/ 302
	}

[samcro1967]

I removed all redir's for the osu.* sections and updated the route statement to the below. When say say a mix of handle and routes, does that mean they cannot be mixed? Will be quicker to convert the 2 handles I have to routes if that is the case rather than convert 50+ routes to handles. I could just comment out all routes for testing and then convert and enable them to handles once I have it working. Just want to make sure I understand before I go making a bunch of changes.

	route {
		redir https://auth.samcro1967.net
	}

[greenpau]

When say say a mix of handle and routes, does that mean they cannot be mixed?

@samcro1967 , I don't know yet. However, I want to see whether then handle directives work. Thus, the removal of route, etc. The experience tells me it might matter.

Additionally, I recommend adding https://github.com/greenpau/caddy-trace everywhere you can and add different tags to see which handles, routes hit, e.g.

route {
  trace tag="default-route-hit"
  redir https://auth.samcro1967.net
}

I am not sure whether trace works with handles, but you could try.

*.samcro1967.net {
        trace tag="entrypoint"
	realip {
		header "X-Forwarded-For"
		from cloudflare
		maxhops 5
		strict true
	}
	tls {
		dns cloudflare {$CLOUDFLARE_API}
	}
 	@auth host auth.samcro1967.net
	handle @auth {
                trace tag="myportal"
		authenticate with myportal
	}
 	@hammond host hammond.samcro1967.net
	handle @hammond {
                trace tag="hammond"
		reverse_proxy 192.168.1.104:8092
	}

[samcro1967]

I got it working with the CaddyFile below. I removed all caddy labels and cut the config down until I can get this working. I do see the trace for hammond in both caddy.log and access.log. None of the other traces appear in either log. I did have to add order trace before handle in the global block in order for trace to work at all.

I am able to get logged in now and can get to "My Identity" and "Portal Settings". None of the other UI links work.

CaddyFile
Link

[samcro1967]

I figured out where I went wrong. I think I understand now how to convert routes to handles for both subdomains and subdirectories with wildcards and caddy-security. The only piece that does not seem to be working as I would expect is trace.

[greenpau]

The only piece that does not seem to be working as I would expect is trace.

@samcro1967 , I think I tested trace to work with routes. I never tested if with handles (i don’t use them). What is unexpected?

[samcro1967]

Yes, trace does not seem to work with handles. Makes sense if they were not tested.

Handles also do not seem to work reliably or consistently. I setup handles using the exact same syntax (copy and paste) for 4 subdirectories. It worked for one and not the other three. I switched the other 3 from handles to routes and they work fine. So I can say mixing handles and routes does work when you can get handles to work. I think I will stick with routes given the inconsistencies with handles.

The only issue I still have not figured out is authentication directly to an app. If I logout of the portal and go to hammond.samcro1967.net, I get the hammond login page and not the portal login page. If I enter my hammond credentials, it fails. That is good. If I auth in a different browser tab to the portal, and then enter my hammond creds I get in. Also good.

I thought though before I made all of these changes if I was not logged into the portal and went to hammond.samcro1967.net, I was redirected to auth.samcro1967.net and then once authenticated redirected back to hammond.samcro1967.net. But maybe, that was not the case.

Caddyfile
Link

[greenpau]

The only issue I still have not figured out is authentication directly to an app. If I logout of the portal and go to hammond.samcro1967.net, I get the hammond login page and not the portal login page.

@samcro1967 , I think this is connected to another issue #92. Specifically, "I think it's common to have multiple domains and you want them projected using only one authentication portal.". Your thoughts?

In short, there could some replacing of the set auth url directive, e.g.

set auth url https://auth.{req.domain}/

[samcro1967]

My case is a little different. #92 is about different root domains where as I am using the same root domain, but different subdomains. Is it still relevant to my use case? I do not see it as a big issue. I will direct folks to the portal always, not directly to an app on a subdomain.

Snds like a future release may add some options to covert one or both of these use cases if I understand correctly?

[samcro1967]

I got everything converted to wildcards as either subdomains or subdirectories (if the app supports running with a base url) using routes. The issue of not getting the login page when going directly to a subdomain seems to be a browser cache issue. If I logout of the portal, close the browser, relaunch the browser, and go directly to a subdomain I am always redirected to the portal login.

Thank you for your help as always. Closing this as the original question has been answered.

[bbrendon]

Hi @samcro1967

subdomains or subdirectories (if the app supports running with a base url) using routes

How did you convert handles to routes? Currently I'm getting this error.
Error: adapting config using caddyfile: parsing caddyfile tokens for 'handle': directive 'authenticate' is not an ordered HTTP handler, so it cannot be used here

[mholt]

@bbrendon That only happens with Caddyfile. As with other handler plugins, you need to specify the handler order relative to another handler directive either by using it in a route block or specifying the order global option at the top.

[greenpau]

@samcro1967, I am looking to add testimonial sections to https://authcrunch.com. Could you please write one and send it to me at greenpau@outlook.com?