Different Phases of a Certificate Lifecycle Management Process for a secure WPA2-Enterprise network
Read time: 10 minutes 45 sec
Organizations need a strong foundation for the WPA2-Enterprise network, and to achieve that, deploying digital certificates should include a Certificate Lifecycle Management solution. Certificate Lifecycle Management systems, also known as Certificate Management Systems (CMS), provide support for using X.509 digital certificates for authentications. CMS allows admins to properly manage and control every part of an individual certificate by maintaining a broader perspective on the network state.
Digital certificate is a type of file or some electronic password that is used to prove the authenticity of a system using techniques of cryptography and PKI. It helps organizations to ensure that only trusted devices or users can connect to the network. Another use is to confirm a website’s authenticity to a web server, known as a Secure Socket Layer (SSL) certificate.
A digital certificate contains credentials like the user’s name, company, and a device’s Internet Protocol (IP) address or serial number. It includes a copy of the Public Key from certificate holders, which must be matched to a private key to compare and verify its authenticity. A Public Key certificate is then issued by Certificate Authorities (CAs) to sign the certificates and verify the credentials of the requested device.
Importance of Digital Certification
Digital Certificates can be requested by organizations, individuals, and websites. A public key is provided through a signing request to validate the information. Upon Validation by a trusted CA, the data is signed by that CA with a key that offers a chain of trust to the certificate. This process enables the certificate to verify the authenticity of a document, authentication, or provide proof of a website’s credentials.
Types of Digital Certificate
Digital certificates can be of different types, and those are:
Transport Layer Security (TLS/SSL) certificate
A TLS/SSL certificate is used on a server to ensure that the communication with its client remains encrypted and private by providing authentication for the web server to send and receive encrypted messages to clients. TLS/SSL certificate comes in three forms:
This is a quick validation method acceptable by any website, cheap to obtain, and can be issued within a minute.
This helps provide light business authentication and is best choice for organizations selling products online.
This offers full business authentication to deal with large organizations’ sensitive and private information. It is generally used by businesses in the financial industry to offer authentication, trust, and security.
Code Signing Certificate
It is mainly used to confirm the authenticity of internet downloaded files or software. Mainly used by developers to provide software available on third-party sites and have these files or software is not tampered with. The developer or publishers need to sign so that users know this software is genuine and can be downloaded.
This certificate is used to identify an individual user to a different user or machine or one machine to another. In an email, a sender signs a communication digitally while the recipient verifies its signature. This can also be used to help access protected databases
Benefits of Digital Certificate
Digital certificates are essential as cyber attacks continue to increase in volume and sophistication. A few crucial benefits of Digital certificates are:
Digital certificates are responsible for encrypting internal and external communications to prevent attackers from stealing or intercepting sensitive data. For example, a TLS/SSL certificate helps encrypt data between a web browser and a web server to ensure that an attacker cannot intercept website visitors’ data.
Digital certificates give businesses of all shapes and sizes with the same quality encryption. These are highly scalable, meaning that they can be easily revoked, issued, and renewed to secure user devices and are then managed through a centralized platform.
Digital certificates are vital to ensure online communication’s authenticity to prevent cyber attacks in this age. These ensure that a user’s messages are always sent and reach the intended recipient. A few use cases are document-signing certificates for digital document signing, TLS/SSL certificates encrypting websites, and Secure/Multipurpose Internet Mail Extensions (S/MIME) encrypt mail communication.
Using a digital certificate ensures that a website is authenticated and genuine and that documents and emails are adequately authenticated. It also reflects public trust by assuring clients that they are dealing with a genuine company concerned with security and privacy.
Only those CAs can issue digital certificates which are publicly trusted. One needs rigorous vetting to ensure that attackers cannot trick victims that use a digital certificate.
What is the difference between Digital Certificate and a Digital Signature?
A digital certificate is a file that is used to verify the identity of a user or a device and enables connections that are encrypted in nature. At the same time, a digital signature is a hashing approach that uses numeric strings to validate identity and provide authenticity. A cryptographic key is used to fix a digital signature to a document or an email, this signature is hashed, and when the recipient receives it, the same hash function is performed for decrypting the message.
Why is Certificate Lifecycle Management important?
Digital certificates are built using public key cryptography, a type of asymmetric cryptography where both parties (sender and receiver) have half of a public-private key pair. Each side uses its half to encrypt the communications, which the holder of the second half can decrypt. This type of cryptography is better than hash cryptography, which is generally used in credential-based systems but requires more steps. Due to its asymmetrical nature, it requires two parties to establish secure communications to provision the public-private key pair. This usually happens through the mutual trust of a CA. A robust Certificate Management System (CMS) is an essential tool for managing the lifecycle of a certificate. This CMS allows a user to view, manage and customize all process aspects.
The Stages of a Certificate Life Cycle
Digital certificates are issued and confirmed by a CA to authenticate an identity. Passwords rely on phrases or words created by a human, the user. But certificates utilize public-private key encryption to encrypt information and are authenticated using Extensible Authentication Protocol TLS (EAP-TLS), one of the most secure authentication protocols. EAP-TLS is defined in RFC 3748, which provides support for multiple authentication works. Certificates offer more advantages because these are easier to use and more secure than credential-based authentications. Most IT security firms (almost 55%) prefer a method of protecting accounts and authenticating them without involving passwords. However, certificates have an expiry, too, and are not valid forever, and their lifecycle is based on an organization’s preferences.
The stages of a certificate are:
- Certificate Enrolment
- Certificate Distribution
- Certificate Validation
- Certificate Revocation
- Certificate Renewal
- Certificate Destruction
- Certificate Auditing
Certificate Enrolment is the first phase of the certificate cycle, which typically begins with a user or a device requesting a certificate from a CA. This request consists of a public key and other enrolment information. Upon receiving a request for the certificate, the CA verifies information based on the advanced set of rules. If the information gets authenticated and is legitimate, the CA creates the certificate and another certificate for requesting party to identify it. There are four steps required for certificate enrolment:
Request a Certificate
A certificate enrolment process starts when a user requests a certificate enrolment with a CA. This request should consist of enough information to enable the CA to verify the user’s identity. The information needed is domain name, business telephone number, which is obtainable via public sources, and three contacts – authorization, technical, and billing. The CA can also ask for additional information depending on the type of certificate requested.
Add required Characteristics
Before submission of the relevant information (in the above step) is completed, the user also needs to submit other details like sending over their public key for the CA’s signature, the hashing algorithm, and the digital signature to create the digital signature using it. This public key, along with a private key, is created by Cryptographic Service Provider (CSP) after receiving the certificate request and passing it to the CA.
CA validates request
After receiving the enrolment request, the CA uses a public key to decrypt the digital signature, calculates a hash, and verifies the hash in the decrypted signature. It also uses all the given verification information for validation purposes. If Validation is successful, the CA digitally signs the public key and sends this completed certificate to the user.
Install the certificate on the user’s machine
After verification is completed, the user needs to install it on the server and take note of its destination. Users should also copy the file received from the Certification and store the certificate’s relevant keys in a secure location. After these, users should publicize copies of their certificates to websites and web browsers for authentication.
Certificate Distribution happens when the CA distributes the certificate to the user. This is a separate process because it requires management intervention from the CA. The CA sets policies that affect the use of the certificate in this stage. Although CA Client Automation does not provide any automated certificate distribution technology, it comes with default certificates for each CA Client Automation node and application-specific certificates. To migrate from the default certificates after an install which was the default, the certificates should be distributed in the following ways:
- Create a new root certificate and ensure the root name differs from the existing CA Client Automation root certificate.
- Schedule the distribution of this new root DER encoded certificate within CA Client Automation infrastructure’s all nodes.
- Create new security profiles in the CA Client Automation management database to replace existing profiles of an application-specific certificate.
- Schedule the distribution of new certificates to all CA Client Automation nodes.
- After successfully distributing the certificate, the previous CA Client Automation certificates must be deleted.
- Delete the old security profiles used for the application-specific certificates.
When a certificate is used, the current status of a certificate is checked to verify whether it is still valid or not. The Certificate Revocation List (CRL) is checked by RADIUS on the server during this process. CRL is the list of certificates revoked by the CA that were previously issued and set to expire. A RADIUS server only rejects a connection request if the device’s certificate serial number is already present in the CRL. This feature is beneficial if a device gets stolen, an employee’s permissions change, or something like that.
Certificate Revocation is the last stage of a certificate lifecycle. This phase comes when a certificate expires or when CA revokes the certificate just before the expiry date. CA automatically adds a certificate to the CRL when it is revoked and thus instructing RADIUS to no longer authenticate it. CRLs can be exhaustive, and the client which conducts these checks must parse through the whole list to find the requested site’s certificate, whether it is present or not. A new and more recent method of detecting revoked certificates is Online Certificate Status Protocol (OSCP). In this method, instead of downloading and parsing the entire CRL, the client can send the selected certificate to the CA, upon which the CA returns the status of the certificate like – “Good,” “Revoked,” “Unknown,” or so on. It involves far less overhead than the CRL method.
If a certificate policy allows a certificate that has already reached its expiration date, it is renewed either automatically or by the user’s intervention. When a renewal process is to be started, the user needs to choose whether to generate new public and private keys or not.
When a certificate has no more uses, that certificate and all its backup copies or archives need to be destroyed along with the associated private key. This helps in ensuring that the certificate is not compromised and used.
Certificate auditing tracks the creation, expiration, and revocation of certificates. In certain instances, it is also used for tracking the successful use of a certificate.
Certificate Lifecycle Management for SSL/TLS Certificate
Certificate Lifecycle Management is one of the essential things in proper PKI management. Apple has decided unilaterally to only trust 398 days of valid SSL and TLS certificates, despite the industry consensus to reject the proposal. This regulation came into effect starting 1st September 2020 and impacted only newly issued certificates as existing certificates were grandfathered in. The average validity period for all the certificates, including SSL/TLS, decreased from 2 to 5 years. This industry trend of shorter certificate lifecycles proved beneficial as it is more secure to replace certificates more frequently, whether necessary or not. This was still an improvement from the 90-day password replacement policies.
At the core of an effective certificate lifecycle management system lies a strict management program for an organization. Organizations without proper certificate lifecycle management are prone to face security and management issues, and certificates may get lost in the system, expire, and cause a loss in revenue. For a certificate lifecycle management to be effective, all the certificates it generates must be consolidated into a single machine identity management system.