Caddy: Allow revocation list for client cert auth

[Alex131089]

Hello, could caddy add an option to check client certificate against a revocation list ?
This was the object of https://github.com/mholt/caddy/issues/1904, which it was closed as duplicate of https://github.com/mholt/caddy/issues/1375, but https://github.com/mholt/caddy/issues/1375 doesn't seems to implement that.
Best,

---

1. What version of Caddy are you using (caddy -version)?

v0.11.0

2. What are you trying to do?

Disallow revoked client certs

3. What is your entire Caddyfile?

Not relevant, there's no option to do that as per https://caddyserver.com/docs/tls

[mholt]

@Alex131089 Any reason you need to use a CRL specifically? What about some custom logic to check the provided client certificate to see if you'd allow it?

[Alex131089]

Usage: disallow a compromised certificate, like a certificate installed on a lost phone for example.
What kind of logic are you referring to? Checking CN and/or Dates for example, or hash of the certificate?
I don't need CRL specifically, but I believe it's simpler as it is commonly used for this purpose (and maybe already available to the TLS lib?), while managing multiple criterion doesn't sounds good?

[mholt]

I suppose I am interested as to why you'd rather maintain both a list of approved client certs AND a CRL to override entries in that list, than simply a list of approved client certs: if the key is compromised, remove it from the list of approved certs.

[Alex131089]

Hum, what list of approved client certs, I feel I missed something?
If I understand, in the configuration (https://caddyserver.com/docs/tls) you give a list of approved CA, but theses CA may approve multiple certificates, so you might want to revoke one of them. The other solution would be to have 1 certificate per CA?

[francislavoie]

@Alex131089 this is being asked more in the context of Caddy v2. See the discussion relating to this PR https://github.com/caddyserver/caddy/pull/2731

[mholt]

@Alex131089 It's a Caddy 2 feature :wink: -- we've greatly improved TLS controls in v2.

[Alex131089]

Oh ok :)

client_authentication { trusted_ca_certs, trusted_leaf_certs }

My point of view, if it's welcomed: I feel like it's reinventing the wheel for this feature? (Also, base64 certificate in the configuration file?)
But a more pragmatic reason against is, it will be more probable/usual I have to allow a new cert (if I don't forget to edit the Caddy configuration after I generate it ..), than I have to revocate it (should be exceptions), so the less I have to touch the configuration the better.

[Alex131089]

My usage for this feature (client cert) btw: allow access to sensible/untrusted portals/apps (proxmox, irc webclient, ..) only from trusted personal devices, while still exposing them publicly.

[mholt]

My point of view, if it's welcomed: I feel like it's reinventing the wheel for this feature?

I dunno about that; hesitating to implement a feature that _might not_ be needed isn't a re-invention, just questioning whether a CRL is really the right answer here.

(Also, base64 certificate in the configuration file?)

Would you prefer something else? We could change it if the reason is compelling enough...

so the less I have to touch the configuration the better.

I suppose this is true, but with a CRL you have to touch two things: add a CRL to your config, and add the cert to the CRL.

Tell ya what, I'll accept a good pull request that implements this feature; but it's not a priority for me to implement right now.

[Alex131089]

My point of view, if it's welcomed: I feel like it's reinventing the wheel for this feature?

I dunno about that; hesitating to implement a feature that _might not_ be needed isn't a re-invention, just questioning whether a CRL is really the right answer here.

I mean using whitelist instead of CRL, but why not, yes ; more people should probably say what they expect.

(Also, base64 certificate in the configuration file?)

Would you prefer something else? We could change it if the reason is compelling enough...

Certificates are usually loaded from files, when discovering this, I'd be surprised you have to put it directly in the configuration file (involving a possible format conversion and not as simple as copy/pasting a file).

Nginx/Apache are using file directives:

• https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate
• https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_crl
• https://httpd.apache.org/docs/2.4/en/mod/mod_ssl.html#sslcarevocationfile

so the less I have to touch the configuration the better.

I suppose this is true, but with a CRL you have to touch two things: add a CRL to your config, and add the cert to the CRL.

Once the CRL file is in the config, when revoking, you "just" have to generate the new CRL file (appending the new revocation) and replace the old CRL file with this one. If Caddy cannot detect the change in the file (date/size), you'd also have to reload Caddy. But you're not touching the configuration (which would be very error-prone, especially with big base64 strings).

Tell ya what, I'll accept a good pull request that implements this feature; but it's not a priority for me to implement right now.

I get it, as it's not very important to me I'm probably not playing with this but thank you for considering it though :)

[mholt]

Certificates are usually loaded from files

True; I've had a hard time deciding whether to stick with files or with file contents in the Caddy 2 config because the Caddy 2 config is designed to be generated on-the-fly from tooling that may or may not want to use files to load parts of the config, like certificates. Although in some cases we allow both (like loading server certificates in the TLS app), just under different object key names: https://github.com/caddyserver/caddy/wiki/v2:-Documentation#tlscertificates

Anyway, my offer still stands, if there's a PR to implement a CRL, I'll be happy to review it!

[mholt]

Thanks to this discussion, I just realized the v2 docs were out of date for client auth, but I updated them today: https://github.com/caddyserver/caddy/wiki/v2:-Documentation#httpserverstls_connection_policies

[shynome]

need this feature +1.
I like the caddy simple config but I have to go back nginx because nginx support and this is required for security when use tls client certificate.
At last, thank you for so great software

[allardmuis]

@mholt
I'd really like to have this feature as well. I'll try to describe my usecase and why other solutions are not working for me.

I have a system where I have to grand access to my api to other servers. Which other parties are allowed is decided by a government institute. Anyone can apply, and if successfully audited, gets a certificate signed by their CA. So there are many certificates out there, I don't know which ones, new ones can be added every day.
So I allow any client-certificate signed by the CA, without knowing in advance which specific certificates there are. This is easy with Caddy: i just set the CA in 'clients' option.

If a certificate is compromised, or someone fails the yearly audit, the CA revokes the certificates of that party. The certificate is put on the CRL maintained by the CA. I have to check that, otherwise I keep granting access to systems that should not have it anymore.
Even better would be to use OSCP and request to the CA if a client-certificate that is used is still valid.

TLDR; I think CRLs are the only way if you don't hand out the client-certificates yourself, but trust everything signed by an external CA.

Btw: Reading CRLs from file would be much nicer than having them in the config file itself: a CRL might contain hundreds of certificates so the config would get bloated quite a bit.

[Gr33nbl00d]

I need this feature too, we have exactly the same use case like @allardmuis
As this is quite urgent for us we need to find some solution soon.
Could be that im forced to do the changes myself and open a pull requests. But as i have nearly no expirience with golang this will be last solution i would like to go.

@mholt
you might have a look here as example:
https://github.com/cloudflare/cfssl/blob/master/revoke/revoke.go

[mholt]

@Gr33nbl00d

I need this feature too, we have exactly the same use case like @allardmuis
As this is quite urgent for us we need to find some solution soon.
Could be that im forced to do the changes myself and open a pull requests. But as i have nearly no expirience with golang this will be last solution i would like to go.

Absolutely understand -- I can get authorized to work on this feature right away if your company can fund its development. If you fill out this form, we can get the ball rolling today: https://www.ardanlabs.com/my/contact-us?dd=caddy

Thanks for the link, too, that might come in handy!

[Gr33nbl00d]

@mholt
I mentioned it to our product manager today ;) Because of some other problems this is postponed to begin of next year. So we life first without CRL till begin of next year. Than we will see ;)

[wille-io]

I'd also love to see this feature in caddy.
Because I would rather have a list of 2 or 3 compromised certificates in a revocation list than having to put hundreds of certificates in a whitelist.

[mholt]

As I said above, we can prioritize this feature if your company can pay for its development; or anyone else is welcome to propose and implement it voluntarily. It's on the list (as the issue is still open) but on the backlog as I work through more pressing priorities.

[wille-io]

Sorry, didn't want to exert pressure or anything, just wanted to state my point of view.
I wish I knew Go, I can't even find where the variable "ClientCAs" is used, so I could see where to put the counter part for it and implement it myself for Caddy.

[mholt]

@wille-io

I can't even find where the variable "ClientCAs" is used,

It's used by the Go standard library's crypto/tls package. You can find it used in there: https://golang.org/search?q=ClientCAs