3 ms·
Apologies. Your implementation was a little tricky to understand. Excellently commented though. Can you give me an example config file for the client? (I could
by ktta 9y ago
Apologies. Your implementation was a little tricky to understand. Excellently commented though.
Can you give me an example config file for the client? (I could only see one for the server)
PS: In a couple places, 'Ellyptic' was written so you might want to correct that.
- bluejekyll 9y agoThe Client/Resolver doesn't actually have a config for enabling TLS ATM, this should be added as a backlog issue. At the moment you'd have to build this into a custom Rust impl. I've been considering whether it can be an addition to the resolv.conf, or should just have a separate TOML. If you don't mind, would you want to file an issue and describe how you want to use this? Edit: I have been planning on a system daemon caching resolver that can be run on any OS. This work is only just getting started. > In a couple places, 'Ellyptic' was written Yeah, me and spelling have had a issue going all the way back to 1st grade ;) Edit: btw, you're comment about CN got me thinking again about the correct usage of that, and I wonder if "name" is even correct. It might be better to have the certs be validated against IP's listed in the Subject of the Cert... I need to revisit this. btw, here's a good example from one of the tests that shows how to set this up: https://github.com/bluejekyll/trust-dns/blob/master/rustls/src/tests.rs#L193-L207 https://github.com/bluejekyll/trust-dns/blob/master/rustls/s...
- ktta 9y agoThanks. I'll check it out. What you are saying can work if the client has a an IP/port and the CN that is in the Server's Cert in a config file. If you are targeting linux I would say have a new config file in /etc . Messing with resolv.conf isn't recommended since it is re-generated frequently.