Certificate Authority
Introduction
So you want to run a Certificate Authority to manage your Public Key Infrastructure (PKI)?
Mostly that just means a way to generate and sign certificate signing requests (CSR). Here are some tips that may help get you going.
Choices
First, you'll need to choose what software package you will use to manage all this. Here are a few choices...
- Xca
- OpenSSL
- Easy-rsa
- certutil
- tinyca
- OpenCA
- NewPKI
- EJBCA
- Microsoft PKI certificate services
- SUSE has CA management built into their Yast2 utility
- Red Hat also has something whose name I don't recall, probably RHCS
As for myself, I choose Xca almost always because it is easy to work with and supports a wide-range of functionality. It does have drawbacks, namely that it does not provide self-service fulfillment like some of the heftier certificate authorities. There is no support for LDAP and a fancy web interface.
Create the CA
Here are some tips on creating the CA, some learned the hard way.
1. Choose SHA1 digest algorithm. MD5 is deprecated and SHA256 is not widely supported.
2. Specify good descriptions for Organization Name, Organizational Unit Name and Common Name. Example...
- organzationName: Company Name, LLC.
- organizationalUnitName: Company Name Certificate Services
- commonName: Company Name Certificate Authority #N
Here is how it will look when branded into the certificate.
issuer=/O=CompanyName, LLC./OU=CompanyName Certificate Services/CN=CompanyName Certificate Authority #3
which leads me to...
3. Assign numbers to your CA certificates, starting with 1. This can be the same as the serial # if you want, it doesn't matter. Put the # in your commonName so it will "pop" when seen in customers/clients certificate store. It will also help simplify things when troubleshooting who a given Issuer was.
4. Choose a strong key for the CA - 2048 bits at least
5. Choose a nice, long validity term, 10 years at least, or 15 or 20.
6. If you are brave, choose to implement an intermediate CA scheme. This let's you delegate signing authority to other groups or divisions in your enterprise, all leading back to a single central trusted CA. However this invites operational complexity as the use of chaining is required by the users of certificates issued by the intermediary CA.
7. Setup a shared "escrow" folder where users can drop their certificate requests (CSR) and you (the signer) can put the signed certificates for pickup.
8. Decide in advance whether you plan to support revocation lists. These can take the form of a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP). Not all applications support these things, so don't sweat this much... but if you do choose it, you'll want to indicate the URL of either the CRL or OSCP in your CA certificate I believe (or it may be in the signed certificates instead).
Steps to create a certificate authority in Xca
Here are the steps I use to create a CA in Xca.
- Start Xca
- create a new database
- click on "Certificates" tab
- click on "New Certificate" button
- Create a self signed certificate with the serial 1 (or whatever # this ca is)
- choose SHA1 as signature algorithm
- choose [default] CA template and click "Apply" button
- click on "Subject" tab
- specify Internal name: xyzca1
- specify Organisation: Company Name
- specify Organ. unit: Company Name Certificate Services
- specify Common name: Company Name Certificate Authority #1
- click "Generate a new key" button
- specify Name: xyzca1
- specify Keysize: 2048 bit
- click "Create" button
- the new key will be automatically chosen as the Private key
- click "OK" button and the certificate is created
- click on Certificates tab
- right-click on the new CA certificate labeled xyzca1, choose Export
- save xyzca1.crt on your filesystem. This can be put on the company website for distribution.
Related
- OpenSSL Certificate Authority Setup
- CAcert offers free certs, so if you don't want to run your own CA give them a try.
--fostermarkd 10:59, 5 September 2008 (PDT)