Certificate Management, or more specifically, x.509 certificate management, is the activity of monitoring, facilitating, and executing every certificate process necessary for uninterrupted network operations. In other words, it is the process of purchasing, deploying, renewing, and replacing certificates on their respective endpoints (which could be an application, a server, a device – or any other network component). The ideal certificate management program would be capable of doing all that, possess functionality to monitor the entire certificate infrastructure in real time, and automate any certificate operation that can be automated – renewals and provisioning, for instance.
A well-defined certificate management strategy is invaluable to businesses in the long run, since the increased visibility and control over their infrastructures helps them prevent application downtime and outages which are caused due to faulty, misconfigured, or expired certificates.
2.1 How do digital certificates work?
In order to gain an understanding of a certificate management strategy, you need to understand how certificates function (if you’re already familiar with this, click here to jump to section 3.2, where we cover the steps for certificate management).
Commonly called SSL/TLS certificates, they’re an essential component of a network’s Public Key Infrastructure (PKI). In essence, it acts as the digital identity of a network endpoint, and assures entities that communicate with the endpoint that it is legitimate. Certificates build a foundation of trust for a network and its components, since they are digitally signed by Certificate Authorities (CAs) – bodies that issue certificates to clients after verifying their legitimacy. Hence, certificates that are not issued by CAs are considered dubious, and are mistrusted by browsers, causing them to block entry to websites that are secured by such certificates (or are not secured by certificates at all).
The most important function of a digital certificate is to facilitate the encryption and decryption of information transmitted over a network. It does this by confirming the holder’s lawful ownership of a public key. The presence of a valid x.509 certificate is the first step in a process called the ‘TLS handshake’ – standard background procedure for and client and a TLS-secured server to begin communicating with each other after verifying each other’s credentials, and settling upon the encryption parameters they will be applying to the session.
2.2 What is a TLS handshake?
Here’s a quick run-through of a typical TLS handshake:
Step 1: Client Hello
The ‘client’ hits a server with a request to communicate. It also presents the server with the cipher suites and TLS version it is compatible with.
Step 2: Server Hello
The server acknowledges the outreach, picks a compatible cipher suite from the list offered, ensures that it uses a version of TLS compatible with the client, and presents its certificate (and public key) to the client.
Step 3: Pre-Master Key Generation
If the server’s certificate is valid, the client reads its private key and uses it to initiate an intermediate verification process for extra security. It encrypts a ‘Pre-master key’ which can only be decrypted using the server’s private key, and sends it across.
Step 4: Shared Secret Generation
The server uses its unique private key to decrypt the pre-master key, and in turn, uses the pre-master key to generate a ‘Shared Secret’ (or in simpler terms, a Master Key or Master Secret). This shared secret represents the mutually agreed-upon algorithms that will be used to encrypt/decrypt the session.
Step 5: ‘Finished’ Message Testing
The client sends a message to the server, encrypted by the shared secret. If the server can successfully decrypt it, it does the same – by sending the client an encrypted message. Once the client verifies that it has decrypted the message, both sides of the transaction have verified the security of the session – that all communication from this point on will be encrypted.
And that’s when you see the padlock symbol on your browser’s omnibar!
Note: SSL was the original HTTP encryption protocol. With the emergence of TLS (and its vastly superior security features), SSL has been rendered obsolete. TLS is the new standard for cryptographic protocol, though SSL is widely used in name only as a synonym for TLS.
2.3 How are certificates used?
Now that you know how certificates function, you’ll want to know how they’re used. It’s a fundamentally simple process:
3.1 Why do you need a certificate management system?
With the advent of digital transformation, nearly every enterprise process has taken to leveraging digital systems to operate. There has been an unprecedented explosion in the number of connected devices used today: ranging from cloud applications to the internet of things (IoT). Every system that is connected to the internet, or to another system, requires at least one digital certificates to operate securely.
That being said, an administrator in charge of managing PKI for an organization or a business unit often has to deal with hundreds, if not thousands, of certificates. Every individual certificate is associated with several variables which are different for each one, such as:
Additionally, these certificates need to be constantly monitored to ensure that they’re effective. Administrators also require control over who gets to request and approve certificates, to ensure that unwanted certificates are not added to the system. All these processes are impossible to handle on manual systems like spreadsheets, prompting the need for a specialized certificate management process.
3.2 What are the steps involved in certificate management?
While the following section is listed in no particular order, it accurately represents the ‘life cycle’ of any given certificate, in other words, every certificate has to go through each of these steps from between the time it is issued to the time it is retired. Hence, an administrator would have to consider each of these processes while orchestrating a certificate management system.
When a new certificate is required, a private key needs to be created and the cipher suites need to be configured before it is sent to a CA to be digitally signed. The process of requesting a digital signature is called a Certificate Signing Request (CSR), and is the trigger for a CA to issue a valid certificate.
Certificates, once procured, must be installed onto endpoints (servers, devices, applications et al.). When certificate chains need to be established, care must be taken to correctly configure root and intermediate certificates to prevent confusion during renewals.
Certificate discovery is the process by which the entire network infrastructure is scanned to determine where each certificate is deployed and validate whether it is correctly deployed. Employing a discovery scan ensures that the system is free of unknown certificates that might have unresolved vulnerabilities that could potentially become weak links that could be exploited.
Organizing certificates into a centralized inventory makes certificate operations such as renewals and revocations easier. It’s also advisable to group certificates and managed entities based on the teams that are using the certificate, to simplify location.
Dynamic monitoring and reporting systems serve two purposes. One, it gives administrators at-a-glance information regarding certificates and their statuses, and provides quick answers to essential questions: How many has each CA issued? How many need to be renewed? How many require replacement? Two, it ensures that there is no blind spot in the system, which allows administrators to prevent outages by preemptively preventing expirations.
All certificates have limited validity periods, and need to be periodically renewed by a CA to ensure that they remain valid. This process can be automated by commercial certificate management tools to automatically send CSRs and get certificates renewed, and provisioned.
Certificates need to be revoked, rather than renewed, at the end of their life cycle for various reasons: perhaps a hash function was deprecated, or maybe the administrator desired the use of a different type of certificate. Revoking a certificate renders it invalid, and is a necessary step to ensure that the discarded certificate is not used by malicious actors to masquerade as a legitimate client.
AppViewX CERT+ is a turnkey solution for all enterprise public key infrastructure (PKI) needs. It not only simplifies setting up and operating a private CA environment with PKI as a Service (PKIaaS), but also provides very rich certificate lifecycle management (CLM) capabilities.
With AppViewX CERT+, enterprises can quickly setup their internal root certifying authority (CA) as well as issuing CAs without having to upfront invest in costly hardware or complicated processes or cumbersome PKI operations. Certificate lifecycle management (CLM) in CERT+ simplifies all certificate operations between CA and the applications where certificates are to be used.
CERT+ simplifies management of certificate and keys across various technologies like SSL/TLS, SSH, IoT, code signing etc. in varied hybrid cloud and multi-cloud deployment environments. CERT+ natively supports long list of devices and applications for certificate provisioning as well as all major public and private CAs for certificate enrollment. Support for protocols like enrollment over secure transport (EST), automatic certificate management environment (ACME) etc. especially comes handy for high speed certificate enrollment for IoT device manufacturing.