TheSSL/TLS protocolis about security and authentication. It allows for the encryption of data communications over open networks, safeguarding against tampering and interception by malicious actors. In addition, the use of SSL certificates authenticates communicating parties, creating a trust environment. Security and authentication are the building blocks of successful enterprises in the digital world.
To establish the required level of trust and eliminate the use of rogue certificates impersonating legitimate companies, SSL certificates need to be signed and validated by a trusted Certificate Authority (CA). CAs issue trusted root certificates who are included in trust stores. The digital certificates that are signed with the root private key are trusted by all devices and applications whose trust store includes the root certificates. Thus, achain of trustis created which is used to authenticate organizations.
Today, digital certificates are used to secure thousands of connections between machines, devices, and applications. Traditionally, organizations use SSL/TLS certificates signed by trusted public Certificate Authorities (CAs). With the proliferation of technologies and initiatives such as cloud, containerization, IoT and mobile devices, and the subsequent explosion in the numbers of digital certificates, many have also deployed internal, private CAs to secure these deployments.
Let’s break down some of the key differences:
Publicly-trusted certificates
Publicly trusted SSL/TLS certificates are used for public-facing web servers and applications. A publicly-trusted certificate can only be issued by an external, trusted third-party CA (e.g. Entrust, DigiCert, etc.) which verifies the domain owner.
Privately-trusted certificates
Privately-trusted SSL/TLS certificates are used to authenticate users and devices on the internal network. A privately-trusted certificate can be issued by either a public CA, or more often, by any organization that runs their own dedicated internal public key infrastructure (e.g. Microsoft CA).
What is a Self-Signed Certificate?
Another strategy is to issue self-signed SSL certificates. A self-signed certificate is one that is not signed by a CA at all – neither private nor public. In this case, the certificate is signed with its own private key, instead of requesting it from a public or a private CA.
Self-signed certificates offer some advantages when used in internal networks and software development phases, however, they can also create several risks without proper visibility and control.
The biggest challenge with self-signed certificates is that security teams often lack visibility over how many they have, where they are installed, who owns them, and how the private key is stored. It’s hard enough keeping track of certificates issued by a number of different public and private CAs. It’s virtually impossible to keep track of self-signed certificates issued without any formal request or approval process.
If the corporate network is breached, there is no way of knowing if a self-signed certificate (and it’s private key) has been compromised. Compromised self-signed certificates can pose many security challenges, since attackers can spoof the identity of the victim. Unlike CA-issued certificates, self-signed certificates cannot be revoked. The inability to quickly find and revoke private key associated with a self-signed certificate creates serious risk.
The Risks of Self-Signed Certificates & CAs in DevOps
These risks are accelerated by the number of built-in, self-signed CAs within DevOps tools and cloud services, as well as self-signed certificates issued by developers.
DevOps is about speed and agility. While self-signed certificates allow developers to obtain certificates quickly and easily, they often circumvent the policies you’ve put in place to keep your network secure. Whether developers create a self-signed certificate or spin up a self-signed CA, these methods create a false sense of trust in your development and delivery process.
So, why would developers use self-signed certificates? The better question is, why wouldn’t they. The usual manual process of submitting a certificate signing request (CSR), then waiting hours for verification and signing just isn’t intuitive. To save time and frustration, it makes sense for developers to opt for self-signed certificates or built-in CAs like HashiCorp Vault,Istio, and Kubernetes.
In their report “Managing Machine Identities, Secrets, Keys and Certificates”, Gartner recommends “Having the secrets managers integrate with policy compliant issuers (public or private CAs)” and “Having certificate management systems monitor the issuance of the secrets manager to help audit and manage the life cycle of issued certificates.”
Simply setting up a self-signed CA and issuing high volumes of certificates without adhering to proper PKI practices and certificate policies is not a viable option.
Despite the obvious advantage of accelerating the development process, this practice presents several security implications, since oftentimes security is afterthought. Untrusted, untracked self-signed certificates can be used in software supply chain attacks and allow bad actors to downstream malicious code.
Organizations need to ensure that all their certificates are issued from a secure root of trust, are compliant with policies and best practices, and managed throughout their lifecycle.
The Alternative: Shift from Self-Signed to Self-Service
The solution to overcome this challenge requires a fundamental shift in the way security and development teams work together. Ultimately, you need to enable developers with fast, easy access to certificates from within their workflows, without sacrificing trust and policy.
At Keyfactor, we work with DevOps teams to make the shift from self-signed certificates to certificates as-a-service. That means developers can obtain certificates using automated processes and APIs integrated directly with cloud-native tools like Jenkins, Ansible, Kubernetes,HashiCorp Vault, Istio and others. Meanwhile, every certificate is issued from an enterprise-trusted PKI as-a-Service and security maintains full visibility and control over every certificate issued.
Enabling PKI as-a-Service in DevOps
PKI as-a-Service (PKIaaS) is the right mix of trust and ease of use. Certificates are issued from a trusted, privately rooted PKI, and DevOps teams can easily request and issue certificates via self-service processes, reducing the need for self-signed certificates.
To learn more about how you can eliminate the need for self-signed certificates and embrace self-service automation, request demo of Keyfactor today.
