Support dynamic addition of client CAs
pdumais opened this issue · 11 comments
If I understand correctly, by adding CAs in fc-restconf.web.tls.ca, a client will have its cert validated against any of the CAs according to
Line 31 in 141e395
Does this mean that if a new CA needs to be added, then the server needs to be restarted?
it would be nice if we could set this to RequireAnyClientCert or RequestClientCert and then be able to manually validate the cert using a Filter. This way, the application using restconf would be able to handle requests and validate the certs using a dynamic list that is handled outside of restconf
Or any other suggestions to achieve the same goal?
If adding certs in the ca bag works without reload, then that's ok the way it is. You are confirming that this should be the case? I'll try to make it work, I was just not able to figure out how to update it during runtime yet.
Would you be able to provide an example on how to add multiple CAs for client auth?
I see I can provide 1 ca only using web.tls.ca.certfile in ApplyStartupConfig.
Should I be directly adding them in http.server.tls.Config.ClientCAs? If yes, would it create conflict with
Line 30 in 141e395
No RFC that I know of.
I think it would be good to have a way to allow users to implement their own strategy outside of freeconf. So freeconf would support all 4 options of ClientAuth and allow to add certs in the certpool. Other users, like myself, may want to skip the certpool and use a filter instead.
What was the intent behind the ca in the yang for tls?
That's correct. in our case, each client could have a different CA since we are working in a multi-tenant environment.
If I understand correctly, implementing those RFCs would add a truststore inside freeconf. I think that's a great feature, but I was initially proposing something simpler where freeconf would completely disregard the client certificates and offload the logic to the users of the library. The only thing preventing a user from using freeconf this way right now is that freeconf will not request a client certificate unless the fc-restconf.web.tls.ca.certFile is set. Freeconf only sets http.server.tls.config.ClientAuth if a certfile is provided and the auth is set to VerifyClientCertIfGiven.
I'm wondering if the simplest fix of all would be for freeconf to set http.server.tls.config.ClientAuth=RequestClientCert by default. With this setting as a default:
- a client cert would be requested but nothing would happen if a cert is not presented. So this is backwards compatible
- If a client cert is sent by the client, freeconf won't do anything about it, but the user could decide to implement a Filter to retrieve the client cert and implement his own strategy.
- if the user sets fc-restconf.web.tls.ca.certFile, then the behaviour will be overriden to VerifyClientCertIfGiven and certificates will be verified automatically. This would prevent the users from implementing their own strategy but that's fine since the user has made the conscious decision of adding a cert himself. This could later be improved to support multiple certificates. But this is not necessarily what I'm requesting from this ticket since I don't mind having to validate the certs myself.
My current PR allows a user to manually set ClientAuth, this adds more flexibility but also adds risks for users to shoot themselves in the foot. So maybe just setting http.server.tls.config.ClientAuth=RequestClientCert as the default would be the least invasive solution.
Does that make sense? I'm still reading through your code so it's possible I might have missed important aspects that makes my proposal impossible to implement.
Yes. This would work. As long as I dont set the root CA cert in the config, otherwise it will get overriden.
This is what I'll use for now.
Do we close this issue? Or would it still be preferable to add "official" support for this?