First you'll create a CA certificate, after that you have to deal with your users and servers and issue certificates to them.
Generate the key for the user. This has the problme that the the CA knows the private key of the user. For a paranoid user this might leave feeling of disconfort.
Receive PKCS10 certificate requests fromusers. PKCS10 is a request for a certificate. The user may specify what DN they want as well as provide a certificate signing request (CSR). To prove the user have the key, the whole request is signed by the private key of the user.
What people might want to see.
Re-issue certificates just because people moved within the organization.
Expose privacy information.
Using Sub-component name (+ notation).
Certificates that a CA issues may need to be revoked at some stage. As an example, an employee leaves the organization and does not bother handing in his smart card (or even if the smart card is handed back – the certificate on it must no longer be acceptable to services; the employee has left).
You may also want to revoke a certificate for a service which is no longer being offered on your network. Overlooking these scenarios can lead to security holes which will quickly become a nightmare to deal with.
There are two primary protocols for dealing with certificate revokation. Namely:
If however the certificate in qeustion has been destroyed, there is no need to revoke the certificate because it can not be used by someone else. This matter since for each certificate you add to CRL, the download time and processing time for clients are longer.
CRLs and OCSP responders however greatly help manage compatible services which may authenticate and authorize users (or services) on an on-going basis. As an example, VPN connectivity established via certificates for connecting clients would require your VPN software to make use of a CRL or an OCSP service to ensure revoked certificates belonging to former clients are not allowed access to (formerly subscribed) network services.