On 07/14/2014 08:54 AM, Alan Altmark wrote: > As far as I know, the only place you'll find a URI is in the CRL portion > of the certificate. When a client or server sends a certificate, the only > assumption it can make is that the base CA certificate is known to and > trusted by the peer. All intermediate CAs, plus the base CA, must be sent > to the peer during the TLS handshake.
Look for the "Authority Information Access" object. There are URIs in other sections too. "They're everywhere." There must be a doc somewhere that affirms the mandate you cite about the intermediates. Not clear how well that is implemented in practice. I regularly see certificates which lack their chaining intermediates. Dunno if those are separated out of band. Possible. > An application like a web browser will happily let you add the base CA to > your inventory of trusted CAs. Correct. And that's normally all one needs. > If you just use the public CAs, then the bundles are fine, but that's the > point of asking the question. Each way has its advantages, but I want to > know how people deal with managing well-known public CAs, self-signed > certs (boo! hiss!), and private CAs in an openssl environment. _Self-signed does not equate to bad._ It simply requires manual assertion or IT department pre-loading. You're frowning on the bad practice of letting end /users perform manual assertion/ of a self-signed cert. That /is/ bad. It's all about trust. A growing number of experts are making noise about the sad state of PKI on this planet. > I'm not concerned about the format of the files, but how you and/or your > Linux admins like to manage them, particularly in light of the fact that > the bundles of well-known CAs is updated from time to time. Yep! It's a pain. More than just pain, it's an exposure for many sites. Managing certs and carrying issue/sign chains makes the PKI trust model more like the PGP trust model. One criticism of the PGP trust model (for consumer use) is the need for such work. Ironic. On 07/14/2014 09:23 AM, David Boyes wrote: > Option 1 has a high probability of human error, and if you break one, you > break them all. ... That's a failure of the implementation. I haven't seen such. Guessing you have. > ... It's also kind of a pain to determine what certs are installed where. Too true. > Option 2 permits easily distributing and installing certificates using RPMs, > which makes updating them (or removing them) a snap. It's also a lot easier > to make sure that any necessary intermediate certificates get pulled in > (package dependencies + something like yum work a treat) and it's super easy > to know which systems are affected if a cert is compromised (rpm -qa |grep > local-cert-xxxxx). It also makes it trivial to automate the c_rehash run in a > post-install script so you don't ever forget to do it. Agreed: individual files are the way to go for general certificate management. I like the bundles for loading a known batch of trusted certs. > It's a little more work to set up certificate distribution that way the first > time, but it's worth it. Yes, it's a good exercise to go through. Keep in mind that discrete-to-bundle and bundle-to-discrete are trivial operations where PEM is used. Got Pipes? -- Rick Troth Senior Software Developer Velocity Software Inc. Mountain View, CA 94041 Main: (877) 964-8867 Direct: (614) 594-9768 [email protected] <mailto:[email protected]> ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
