[Date Prev][Date Next]
RE: Understanding PKI
>From: firstname.lastname@example.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
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
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
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.