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/

Reply via email to