In the Part 1, basic concepts of PKI was explained, its usage in the real world and some brief intro on certificate and CAs. In this Part 2 we will learn more about Digital Certificate, its life cycle and revocation.
Version of the digital certificate format e.g. V1, V2, V3. Latest is V3
A unique number assigned to each certificate hence easier to identify
Algorithm used to sign this digitally sign the certificate e.g. sha256withRSAEncryption
The issuing authority name e.g. CN=Codegic Sub CA, O=Codegic, C=PK
Time from when this digital certificate is valid from
Time at which this digital certificate will expire
Name of the entity this certificate is issued to: C=US, O=Acme, CN=Ahmad, Efirstname.lastname@example.org
Your Public Key. Could be any from the popular RSA 2048+ or ECDSA based 160+ where 2048 and 160 are key sizes
Authority Key Identifier
Identifier of the issuing authority, helps in finding who issued this certificate. Normally is the hash of the issuer’s (CA) public key
Defines how the CA issues this certificate, its security practices and processes. For a Public CA must point to online CPS document. e.g. Legal Repository | DigiCert.com
Defines whether this is a CA certificate or an end entity. Also defines how big the PKI chain could be
CRL Distribution Point
Points to the Certificate Revocation Lists (CRL) issued by the CA. CRL files are also digital signed objects containing the list of revoked certificates
Authority Information Access
Points to the either the:
Subject Key Identifier
Hash of the certificate’s public key
Identifies for which purpose this certificate will be used for i.e. encrypting keys, data or creating digital signatures on data
Extended Key Usage
Defines the exact purpose of the certificate i.e. SSL, Code Signing, Timestamping, OCSP signing etc.
Note that digital certificates are digitally signed objects hence all of what is mentioned above is digitally signed by the issuing authority e.g. CA and that digital signature is also attached with the digital certificate. Without a digital signature we can’t truly trust who has issued it so the claim in a certificate can be wrong plus the contents can be tampered as without digital signature we can’t ensure integrity.
Digital certificates are valid for a certain time e.g. 1, 2, 3 year and then you have to re-issue. This also acts as a deterrence to hackers as by the time they will hack your certificate you will get a new certificate. This also creates a PKI management challenge as now certificate needs to be re-issued. CA certificate have more life time like 10, 15, 20 years due to the fact as their key sizes are much bigger i.e. RSA 4096 hence hacking is difficult plus CA key pair issuance ceremony is quite costly as that needs to be observed by auditors and documented hence can’t be repeated every other year.
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.
Email Signing Certificate: Used to digitally sign emails, can be used inside desktop email client software like Microsoft Outlook, Thunderbird etc.
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
SSL Client Authentication Certificate: Used to authenticate users over TLS based secure connection
Code Signing Certificate: Used to sign code e.g. jar, executable files like exe, dlls, so etc.
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.
Timestamping Certificate: Used to sign timestamp responses originating from a Timestamp server
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.
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 Renewal / Rekey (Optional)
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.
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.
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.
What if the step 4 above fails? Ideally the application should stop trusting the certificate being processed as it could have been revoked and you are still using it to authenticate to an enterprise portal. Note that CRL could be slow due to a bigger sized file hence applications rely mostly on OCSP which is light weight and is fast.