Specific certificate

[bunbopoulos (bunbo)]

1. Caddy version (caddy version):

Later / irrelevant

2. How I run Caddy:

I have not yet decided

a. System environment:

Debian 11

b. Command:

Paste command here.

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

Paste config here, replacing this text.
Use `caddy fmt` to make it readable.
DO NOT REDACT anything except credentials.
LEAVE DOMAIN NAMES INTACT.
Make sure the backticks stay on their own lines.

3. The problem I’m having:

I’d like to limit my public instance of caddy only to clients that have a specific certificate (added manually to android clients and to browsers) like I do with ssh.
How can I do that ?

4. Error messages and/or full log output:

5. What I already tried:

I managed to have caddy working with any client. I’d like to limit access to specific clients.

6. Links to relevant resources:

[francislavoie]

@bunbopoulos

I’d like to limit my public instance of caddy only to clients that have a specific certificate (added manually to android clients and to browsers) like I do with ssh.
How can I do that ?

Yes, via the tls directive’s client_auth options:

tls (Caddyfile directive) - Caddy Documentation

[bunbopoulos (bunbo)]

Thanks.
So this will prevent any client thag does not have the certificate installed to go further the authentication and connection will be refused.

This should dramatically improve security yes ?

I can no longer use a vpn to secure the access to my local resources so I have installed caddy and will implement this certificate restriction in the hope of having a security as good as the one I had with vpn.
If you have hother suggestions, I interested.
Thanks

[francislavoie]

@bunbopoulos

So this will prevent any client thag does not have the certificate installed to go further the authentication and connection will be refused.

Yes, if you set the mode to require_and_verify

@bunbopoulos

This should dramatically improve security yes ?

Sure, if that’s what you’re going for (rejecting requests from unauthenticated clients)

@bunbopoulos

If you have hother suggestions, I interested.

You could reject requests based on the remote IP address if you want, if this makes sense for your usecase:

Request matchers (Caddyfile) - Caddy Documentation

Pair the matcher with the abort directive:

abort (Caddyfile directive) - Caddy Documentation

[bunbopoulos (bunbo)]

That’s very useful. Thanks !
I guess fail2ban would be useful too.
But caddy will be behind a nat (with port fw) that I don’t manage.
So I dont see how I can block based on the ip

[bunbopoulos (bunbo)]

Oh ! I think I understand.
Does caddy look for originating IP in the HTTP headers ?
If yes that can solve my NAT problem.
But at the same time it means it can be faked by the client, right ?

[francislavoie]

@bunbopoulos

Does caddy look for originating IP in the HTTP headers ?

The remote_ip matcher looks at the IP on the TCP packets it received. If there’s no proxy between the client and Caddy (like a CDN like CloudFlare or something, or Docker’s userland proxy) then that IP address should be correct.

The matcher may optionally look at the X-Forwarded-For header if you tell it to, but yes, that can be tampered with.

[bunbopoulos (bunbo)]

But with NAT, the router rewrites those.
So it won’t work right ?

[francislavoie]

I mean, check the IP address in Caddy’s logs. If they look like WAN IPs and not private IPs (the IP of your router), then it’s probably fine. I think in that case it would be doing DNAT (for port forwarding) so it only changes the destination address but not the source address.