On Sunday, 07/13/2014 at 09:25 EDT, Rick Troth <ri...@velocitysoftware.com> wrote: > Planning to set up your own CA?
No. :-) > It's actually a single file with multiple PEM instances. > [...] > Velocity uses the same format for our "CA Bundle". [...] Indeed. It's excellent for a CA bundle. And for those who only use certs signed by the Usual Suspects, it's fine. > > And if you're using a private certificate, then you probably have a > > separate PEM file that contains it and the certificate chain, and the > > cert's associated private key. > > Sure. Just be really really really careful where that private key hides. > > I've seen a certificate in the same file with its private key. (Two PEM > stanzas; one file.) But I've not yet encountered a cert chain (multiple > cert PEM stanzas) in the same file with a private key. > > Note: chaining can often be done dynamically. It's common for a > certificate to contain a URL where the issuer's certificate can be > downloaded. 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. An application like a web browser will happily let you add the base CA to your inventory of trusted CAs. When you receive a signed cert request for a end-entity (server or client), the signer includes his own certificate and all of the intermediate CAs that prove the worth of the signature. The "receive certificate" function tears the chain apart and adds them all to the certificate inventory (regardless of how the inventory is stored). > > I'm curious as to which way most people do it, and why. > > Academically, it doesn't matter. Either way, the individual certificates > need to be separated for processing. > > Velocity's zSSL uses both methods. We use a bundle for all pre-loaded > certificates. (For validating clients, should you need that function.) > Intermediate and client certificates are stored as individual files. In > my experience, the single file is easier for a massive root store. > Separate files make more sense when automating. 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. 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. Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu 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/