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.