Comments (11)
from restconf.
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.
from restconf.
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
from restconf.
from restconf.
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?
from restconf.
from restconf.
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.
from restconf.
from restconf.
from restconf.
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?
from restconf.
from restconf.
Related Issues (20)
- when requesting xml, response is a truncated json response HOT 5
- Feature request: Support XMLparsing HOT 1
- Feature request: Support XML output HOT 7
- ServeHTTP in server is not using Request context HOT 2
- Restconf server automatically opens a HTTP server HOT 1
- Feature request: Improve README HOT 1
- Feature request: Improve reflection support HOT 3
- Feature request: Improve error handling HOT 7
- Yang reference needs bump HOT 1
- Response content type not correctly set after XML pull request merge HOT 1
- local.go:ApplyStartupConfigFile function panics instead of returning an error HOT 2
- Restconf does not set the body in the right format (XML) for errors with a body when the accept in the request is XML HOT 2
- Restconf go.mod does not refer to latest freeconf/yang HOT 1
- Content-Type set in util::handle is overwritten by net/http/server.go HOT 1
- Response body for errors not valid in XML HOT 1
- Edit a leaf with `config false` HOT 2
- Question: how to post binary data with JSON HOT 3
- Bug in support for RFC 8525 HOT 3
- Question: how to view full config after change HOT 9
- Question: how to re-retrieve server configuration HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from restconf.