Thanks. >> Suppose you don't trust all those CAs. What can you do? > Then they shouldn't be in your trust root to begin with. It's easy enough to > remove a CA source file from the system cert store and rebuild it, although > what to do is slightly different on each system.
The problem with that approach is that I don't know which one(s) to remove until it is too late. Specifying the root certificate to use for a particular server seemed like a simple way to improve security. Logically, it's removing all but one. I think i/we could write a HOWTO without a lot of work. > That's CA pinning rather than certificate pinning. It only makes sense (to > me anyway) if you expect to have multiple different certificates that refer > to that CA, so maybe if you have a local CA that you don't want to advertise > system-wide. How do I do certificate pinning? I poked around a bit and found HPKP - HTTP Public Key Pinning. That requires extra work on the server side. In particular, it needs a second public key. That doesn't seem compatible with Let's Encrypt. I assume a local CA turns into self-signed certificates. They have to be distributed somehow. We could probably use the web for that. That scales well. It's minor extra one-time work for the server. It's an extra simple step for the client. There are complications when the root certificate times out. -------- I'm looking for something that is practical. That means it doesn't require operator intervention too often. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
