Learn Public Key Infrastructure (PKI) Basics – Part 2

Just like you have different clothes for different occasions similarly there are different types of digital certificates for different types of cryptographic operations. These types are typically from Code Signing, Timestamping, OCSP Signing, SSL Client Authentication, SSL Server Authentication and few others.

1. Email Signing Certificate: Used to digitally sign emails, can be used inside desktop email client software like Microsoft Outlook, Thunderbird etc.

2. Document Signing Certificate: Used to digitally sign documents e.g. PDF, Word, Excel, Power point files etc. A more targeted document signing certificate is from Adobe termed as AATL based certs

3. SSL Client Authentication Certificate: Used to authenticate users over TLS based secure connection

4. Code Signing Certificate: Used to sign code e.g. jar, executable files like exe, dlls, so etc.

5. SSL Server Authentication Certificate: Used to authenticate a web server, network device etc. There are different variants from Domain Validated, Organisation validated certificated (OV) and Extended Validated.

6. Timestamping Certificate: Used to sign timestamp responses originating from a Timestamp server

7. OCSP Certificate: Used to sign OCSP responses from a OCSP server

Why can’t we have just one certificate supporting all these types? Technically speaking you can but this is not done in practice. Note that the Email, Document signing, SSL Client are issued to users while SSL Server, Code signing is issued to a company so its not assigned to an end-user. Timestamping and OCSP certificate are similar like SSL Server certs but just serving timestamping and OCSP needs. Note that as certificate might require different expiry periods or key types or lengths hence its always better to issue separate certificates infrastructure certs i.e. Code Signing, Timestamping and OCSP. As a CA’s end-users could be in millions hence its better to issue one user certificate for all the user’s cryptographic needs (Authentication, & Signing). This also reduces the CAs certificate management efforts and support plus easy for user to handle.

There are also some auxiliary Certificate versions like Organisation Validated (OV) SSL, Extended Validated (EV)-SSL, EV-Code Signing, EV-SSL Client. From a security point of view these don’t add much. These are also expensive but gives a better user experience e.g. showing company name in the browser with the green bar OR company name when you hit some javascript to validate the site seal..

Want to get a free digital certificate for a limited time? Codegic provides different types of certificates in just few minutes. Click here to learn more.

To give an example, say two computers needs to communicate securely, they will exchange their digital certificates, get hold of each others public keys and start encrypting data which only they can decrypt due to the inherent principles of public key cryptography. In reality they will do a lot more like generate a share key called symmetric key (as it is 100x faster than public key encryption) and then use that to encrypt/decrypt. For more see what is SSL.

The PKI Certificate Life Cycle of any certificate whether CA, Infrastructure or End-entity is the same and can be summarized as follows:

• Certificate Generation

• Certificate Renewal / Rekey (Optional)

• Certificate Expiry

Certificate Generation

A user, device, machine, mobile request a certificate from a CA and get’s one. The key pair could be generated at the client side or could be at the server.

Client Side Key Generation: A CSR (Certificate Signing Request or PKCS#10) file is created by the client’s machine and sent to the CA to issue the certificate. In return you get the certificate file (Base64 or Binary encoded). This ensures the maximum key security as the private key part never goes out.

Server Side Key Generation: The CA generates the Keypair and sends a password protected PKCS#12 file contains both the private key and the issued certificate (containing the public). User can then install PKCS#12 file inside their computer, mobile, switch etc. Although this has a more risk of your key to be hacked but recent advancements like support of Cloud based HSMs and 2 factor authentication has reduced this risk further.

The decision of where the key pair is generated depends upon your needs some of which are:

• Document Signing: Both Client Side and Server side key generation can be used. Server side keys are good for where any computing device can be used to sign. There is hence no need to carry any USB tokens as well. Typically this is good for web based signing options. For higher security a USB token could be used but increases cost.

• Desktop based Email Signing & Authentication: For maximum security, client side key generation must be used. Also server side operations are normally not supported hence desktop application needs a direct access to the keys (PKCS#12 file or USB tokens).

End-Entity Certificate Issuance

Issuance of a certificate for a client (end-entity) can follow a process like you getting a driver license by providing some basic information about your self like, provide your ID card, address, a CSR (for client side key creation) and make some payment (for public CA). Processing may take few minutes to days to finally get your Digital Certificate as well. You may get a PKCS#12 file directly from the CA (if keys are created at the CA) or a USB based Crypto token. If you generated the key pair locally then you will only get a digital certificate file which you can bundle with your private key to generate a PKCS#12 file.

Certificate Renewal & Rekey

Prior expiry, clients could optionally renew their certificate. At renewal, the contents of the certificate remains the same including the keys and the CA just re-issues the same certificate hence extending the expiry dates. In renewal there is no need to send the CSR as the CA can use the old one to create a new certificate.

• Pro: Nothing to do at client other than updating the issue certificate inside the applications

• Cons: As same key pair is used hence more risk of being guessed

Rekey is similar to Renew with the only change of key pair is done while the expiry period remains the same as before. A new CSR has to be sent in client side key generation with a new key pair.

• Pro: Key is updated hence lesser risk of being guessed

• Cons: Certificate life time is same as before so a newer one would soon be needed

In either Renew or Rekey a new certificate has to be issued so better to always generate a new CSR to lower the risk and get a new certificate.

Certificate Expiry

Once the certificate has expired, it can’t be used further for authentication or signing. It could still be used for data encryption if its only you who will encrypt and decrypt data. A new certificate will hence be required repeating the same certificate generation process as before. If a certificate has expired doesn’t mean you can throw the corresponding private key. Any data which you have protected with such a certificate will still require the original private keys to decrypt the data hence protecting keys (private key) for expired certificate is still very important.

Certificate Revocation

We have now established that a certificate is a claim from a higher authority of an entity (machine, device, people etc.) and that claim contains its name, location and possibly attributes like role and designation. This claim may change prior the certificate expiry and hence the certificate requires revocation. There may be the following reasons to trigger revocation:

• Your key has been compromised i.e. stolen or suspect to be hacked

• CA keypair has been compromised

• Your designation has changed e.g. switched departments or left the company

• Your role has changed

More about the revocation reasons can be found here. Once a certificate is revoked, any operations done with it will either no work e.g. authentication or if performed will be detected and hence rejected e.g. signing

Revocation Checking Use Cases

When is this revocation check made? In reality any time a certificate is being verified. Some of the use cases are:

• When you authenticate with your certificate to a web server it will check for your certificate revocation

• When you open a secure website your browser will check revocation for the website’s certificate

• When you verify a signed document, you check whether the signer certificate is revoked or not

Once the CA receives the revocation request, it process it and generate a Certificate Revocation List (CRL). A CRL is a digitally signed file (signed by the CA) contains the list of revoked certificate entries. Application can now at certificate verification time, check the revocation status of the certificate using either the CRL or directly via an OCSP check.