Most certificate lifecycle management solutions distribute private keys out to endpoint devices along with the certificates, creating unnecessary security risks. Additionally, this last-mile distribution process, sometimes referred to as orchestration, is one of the most expensive parts of certificate management and the part that is often performed incompletely or manually.
This post outlines a new approach that keeps the cryptographic keys secured in a centralized key management system and significantly reduces the need to distribute keys out to endpoint devices, securing and streamlining certificate lifecycle management across the enterprise.
Certificates vs. Private Keys: Understanding the Difference
Let’s take a moment to clarify the difference between a certificate and a private key. These terms are sometimes used interchangeably, but this is misleading, as they are distinct (though interrelated) assets.
A private key is what it sounds like: a sensitive piece of data that must always be kept secret. It’s what is known as an unshared secret. Depending on the cryptographic operation, the private key is used to either decrypt and read private messages (sometimes via a key exchange protocol), or to create digital signatures. Digital signatures are used for a variety of purposes, including code signing, document signing, and key-based authentication via protocols like TLS and SSH.
For every private key, there is a corresponding public key, which is embedded in the key pair’s digital certificate, along with some other data. So, roughly speaking, the public key is synonymous with the certificate. Unlike the private key, the public key can be shared publicly without degrading the security of the system. For instance, when an end-user visits a website from a browser, the browser verifies the server with the server’s digital certificate and public key.
When it comes to certificate management, the important point to understand is that the digital certificate does not need to remain confidential. In fact, a certificate must be made available to any other end-user that needs to see it. This stands in stark contrast to the private key, which must be protected with a high level of security. Ideally, private keys are always stored and centrally-managed in a hardware security module (HSM) or secure key manager.
Digital Certificates Are Everywhere
The digital transformation of recent years has caused the number of devices on corporate networks to rise exponentially. Routers, switches, printers, databases, servers, virtualized containers, IoT devices, and more, are all connected to the network, with each and every one of those devices typically having one or more digital certificates assigned to it.
Furthermore, digital certificates are not exclusive to non-human users. Many enterprises assign a certificate to every employee, too. These certificates are used for authentication (e.g., VPN access), email protection (e.g., S/MIME), file encryption, and more.
The Necessity of Automated Certificate Lifecycle Management
With a digital certificate assigned to every machine on the network— and potentially to every human end-user, as well— the number of certificates within a given enterprise can be enormous. This makes certificate lifecycle management a real challenge for large organizations. If a few certificates aren’t known to the enterprise, there is an increased chance that one will expire, causing a service outage.
The unplanned downtime caused by expired certificates can damage brand reputation among consumers and cause real financial losses for the enterprise. A 2014 report from Gartner puts the average cost of unplanned downtime at $5,600 per minute, or well over $330,000 per hour.
With so many certificates to manage, and outages threatening to cause such significant financial losses, enterprises need an automated solution. Automated certificate management solutions automatically renew certificates before they expire, preventing costly outages, and enable the enterprise to generate, deploy, monitor, manage, and revoke certificates as needed.
Traditional Automated Certificate Management Solutions
The first generation of certificate lifecycle management solutions made it much easier for enterprises to avoid outages and downtime. Moreover, with all certificates inventoried in a centralized database, and old certificates being renewed automatically, certificate lifecycle management became much less time-consuming than it was before the advent of these solutions.
However, like any technology, first-gen automated certificate management solutions are not without tradeoffs. In particular, there are two primary limitations. First, private keys are distributed out to and stored on endpoint devices, introducing security vulnerabilities. Second, it’s very difficult to fully automate the process of distributing and installing the appropriate files on all machines because custom integrations are often required.
For example, a common use case is to automate TLS certificates for web servers and databases. For the first installation on a given server, the certificate and private key is centrally generated by the certificate management platform and then exported to the server in a format that the server understands (e.g., PKCS12, JKS, etc.). This bundle is then installed to the application that is using it, a process that varies based on the software and/or operating system that the server is running.
At some point before the certificate expires the certificate management system will generate a new certificate (and, potentially, a new private key) and distribute that out to the server. The new certificate will need to be installed and the software making use of it will need to be informed of the new certificate. All of these steps are very specific to the software consuming the certificate. Furthermore, once the bundle has been distributed to the server the private key only has “software-level protection,” meaning that there is no physical protection of the private key, making it very simple for attackers to compromise it.
Centrally-Secured Private Keys: The GaraSign Difference
As noted above, it’s common practice for PKCS12 files, which contain both the digital certificate and the private key, to be distributed out to and stored on endpoint devices. However, this method presents serious security risks. If an attacker compromises a device and steals a private key, they can potentially decrypt and read sensitive data, forge messages, and pivot within the corporate network to compromise additional systems.
A better approach is to leave the private keys centrally secured in a key management system, distribute only the certificates, and enable end-users to access and use the private keys remotely. GaraSign uses this approach, and it is what sets it apart from other solutions on the market.
With GaraSign, end-users, both human and machine, can still use the private keys whenever necessary without any disruptions to existing processes or limitations to performance. This architecture provides an extremely high level of security and enables the enterprise to enforce a wide range of security controls before allowing any end-user to use one of the keys. Optional controls include multi-factor authentication, device authentication, notifications, approval workflows, IP address whitelisting, and more.
In addition, GaraSign removes the need to distribute private keys out to endpoint devices, simplifying and streamlining the orchestration process. It’s no longer necessary to manually install files on web servers or develop custom integrations to automate the process. Instead, endpoint devices are given a key identification number and granted permission to use a particular key that’s stored in the HSM or key manager proxied by GaraSign. When that device sends a request to use a key to GaraSign, GaraSign authenticates the device and generates the digital signature.
Get in touch with the Garantir team to learn more about deploying GaraSign in your environment.
