RE: Understanding PKI

["Dave Thompson" <dthompson@prinpay.com>]

>From: owner-openssl-users@openssl.org On Behalf Of Rodney Simioni
>Sent: Friday, 21 June, 2013 10:36

>I want to really understand certificates, pki, etc; so forgive me 
>if these questions are elementary.

>Before creating a certificate, I need to generate the CSR on the 
>actual server where I am going to install the certificate?

>(reason why I'm asking is because a wildcard csr was sent to me 
>and I don't know if I should use the wildcard csr or the one 
>generated on the server).

It can vary depending on who does what, and whether you are doing 
only server-authentication or client-authentication as well, which 
is not common for SSL/TLS in general but I don't know for LDAP.
Client-authentication is often called "client certificate", although 
this is loose wording because you actually need the cert *and key*.
Similarly server-authentication is often called "server cerificate"
but often it is left implicit since it is practically always there.
(Formally there are non-authenticating "anonymous" suites in TLS, 
but they are rarely used and very rarely a good idea.)

FWWIW http://www.openldap.org/doc/admin24/tls.html says 
"All servers are required to have valid certificates, whereas 
client certificates are optional. Clients must have a valid 
certificate in order to authenticate via SASL EXTERNAL."
Optional could mean 95% but not 100%, or it could mean 2%.

The canonical process is:
- the "user" system that will be authenticated -- usually server, 
sometimes client -- generates a keypair and generates a CSR using 
that keypair (which includes the publickey part)
- a CA uses the CSR to create a user cert (which copies the user 
publickey from the CSR and thus originally from the keypair); 
the cert is signed using the *CA* key-and-cert.
This may be a "public" CA like Verisign or (in your case) GeoTrust, 
or it can be private, but see below
- the user system uses its privatekey and its cert in SSL/TLS
- each *peer* system -- all clients for a server usually -- must 
have the root cert of the CA in its truststore (which as described 
earlier can be a single file or a directory). For public CAs the 
roots are available both on the CA site and other places that can 
be used to confirm their correctness and legitimacy, like every 
copy of Windows (including IE) or Firefox or Java; private CA roots 
are generally only available from the CA, whom you must trust
- if the CA uses an intermediate cert (or several) which in your 
case GeoTrust did, then the server *should* send the intermediate 
cert(s), and optionally the root, in the SSL/TLS handshake. How 
to do this varies, but in your case it appears openldap doesn't 
use openssl's option for a chainfile, so you must put the cert(s) 
in the truststore the server uses. For the rarer case of client 
authentication, s/server/client/.

If someone else generates your key, they can give you the key 
and let you generate the CSR and request the cert; they can 
generate the keypair and CSR and let you request the cert; or 
they can generate the key and CSR and get the cert. In your case 
your "admin" gave you all three, implying the third choice. The 
third choice also includes the case where it's really their key;
they created a key and CSR and got a cert and (then) decided to 
let you share their identity. Since this apparently is as you said 
a "company" cert (and key) it makes sense for you to share.

>Once the CSR is created, a CA will use the CSR to create the certificate?

Exactly. (The user cert, not the CA cert(s) which are different.)

>A CA was sent to me, it's the company's CA (wildcard); if the above answer 
>is yes, do I use the CA, the private key, and CSR to create the
certificate?

You didn't get any CA, you got a user cert *issued by* (or from) GeoTrust. 
GeoTrust is the CA. If I remember (without searching) it is a cert *for* 
*.securesites.com which is a wildcard, so this cert can be used by any
system 
whose DNSname matches that pattern.

>A CSR will only work with the private key it was generated with?

A CSR is generated from, and is for, a given keypair (private+public). 
A cert based on that CSR is for that publickey, and thus only works 
with that privatekey. Once you have the cert, you don't use the CSR 
for anything except possibly getting a new cert -- if you want a new 
cert for the same keypair and Subject name, and any extensions that 
are specified in the CSR and honored.