There is a growing need for digital certificates to identify and control who can access and operate on company networks. Organizations today would like to set up wireless access points that restrict access to external devices and allow only people and machines who are supposed to have access to your network.
Digital certificates are the primary vehicle by which people and machines are identified and authenticated. As the number of identities in a company grows, so does the difficulty of managing and protecting certificates at scale.
Effective certificate management requires constant issuance, renewal, and revocation of digital certificates—and there’s no room for error.
A certificate authority (CA) is responsible for attesting to the identity of users, computers, and organizations. The CA authenticates an entity and vouches for that identity by issuing a digitally signed certificate. The CA can also manage, revoke, and renew certificates.
A certificate authority can refer to:
Many organizations and individuals rely on third-party CAs for SSL certificate management.
By installing the Certificate Authority, you can configure your server to act as a CA. Before installing a Certificate Authority locally, you must plan a public-key infrastructure (PKI) that is appropriate for your organization.
Typical uses of Private CA’s include:
Secure communications between internal services and interoperable communications between third parties, including containerized or application program interface (API) connected cloud environments.
There are two common strategies used for obtaining certificates:
Before creating a Certificate Signing Request (CSR), the applicant first generates a key-pair, keeping the private key secret. Also, the CA will usually require you to provide proof of your legal identity.
Obtaining a certificate through a trusted CA is a fairly straightforward process. If you ask a CA to issue a certificate for you, you must include your public key and some information about yourself. You must use a tool that supports the generation of Certificate Signing Requests, but most certificate management platforms have made this process easy and painless.
The CA will then produce the certificate and return it. If you create the certificate yourself, you will take the same details, add a little more (dates when the certificate is valid, serial number) and build the certificate using some tool.
Not all will accept self-signed certificates. One value CAs offer is to serve as a neutral and trustworthy introductory service, partly based on their authentication criteria, which are published freely in their Certification Service Practices (CSP).
Before creating a Certificate Signing Request (CSR), the applicant first generates a key-pair, keeping the private key secret. Also, the CA will usually require you to provide proof of your legal identity. Sign this information online and forward it to the CA. The CA will then produce the certificate and return it.
Certificate Management involves discovering, analyzing, monitoring, and managing all digital certificates deployed by the Certificate Authority. Proper certificate management should be fundamental to your organization’s security strategy.
To understand the broad scope of certificate management, we must first see the full picture and how it relates to the Public Key Infrastructure (PKI).
PKI comprises the people, roles, policies, procedures, hardware, software, and firmware systems needed for secure communications across broad public and private networks. While exchanging sensitive information, network participants can trust each other’s identities by exchanging digital certificates.
The most common PKI — SSL/TLS — uses a hybrid cryptosystem that uses both types of encryption. Each party signs a message with their public keys and sends the message to the other. They decrypt the received messages with their private keys. This process creates a shared secret key.
The main entities that play a role in PKI Certificate Management are as follows:
The Certificate Authority is a trusted third party that issues end-user keys and certificates and manages their life cycle, including generation, revocation, expiry, and updating.
The root CA is the highest level of the hierarchy and serves as the trust anchor. For an end-entity certificate to be trusted, the root CA it chains up to must be embedded in the operating system, browser, device, or whatever is validating the certificate. Root CAs are heavily secured and kept offline (more on this below).
These live between the root and end-entity certificates, and their primary purpose is to define and authorize the types of certificates that can be requested from the root CA. For example, on public hierarchies, you must separate SSL and S/MIME Subordinate CAs. Another common scenario is separate Subordinates for different locations, or you might have one for certificates with ECC keys and one for RSA keys.
Note: There may be one or more subordinate CAs between a root CA and end-entity certificates. Subordinates that live between the root CA and another subordinate are sometimes called intermediate CAs.
These are the certificates installed on servers, machines, cryptographic hardware, and devices.
Client Application is an end-user software that requests, receives, and uses public-key certificates to conduct secure electronic commerce.
A Managed PKI needs additional services that will inter-operate with the other three mentioned components. These provide unique services that allow for many applications of electronic commerce. Typical services include:
The Certificate Repository provides a scalable mechanism for storing and distributing certificates, cross-certificates, and Certificate Revocation Lists (CRLs) to PKI end-users.
Because of their central position in the PKI, these components need to be responsive and interoperable.
Certificate Lifecycle Management is a discipline that coincides with PKI but has its own set of rules and protocols — focused on the discovery, management, and monitoring of Digital Certificates.
Certificate Management is usually concerned only with certificates issued by mutually trusted Certificate Authorities. Once the Digital Certificates have been issued, they must be managed diligently through its entire validity period. It may seem simple in context, but the management of certificates is anything but simple.
Here are the seven stages of certificate lifecycle management.
Certificates Discovery is the process by which the entire network infrastructure is reviewed to determine where each certificate is installed and to verify if it is implemented correctly. A discovery scan ensures the network is free of unknown certificates that may be expired or configured with weak protocols.
Organizing certificates into a centralized inventory makes certificate operations such as renewals and revocations easier. Correlate devices to certificates to keep track of each device’s status and know when its certificate will expire. A common practice is to categorize certificates based on their intended purpose.
When constructing certificate chains, care must be taken to configure root and intermediate certificates correctly to prevent confusion during renewals. There are different classes of certificates available to you. Purchasing the right certificates prevents fraud and keeps communications secure.
The applicant first creates a key pair before generating a CSR, yet while keeping the private key secret. The CSR includes details identifying the applicant (such as a distinguished name for an X.509 certificate) that must be signed using the private key of the applicant. The CSR also includes the applicant’s preferred public key.
If you create the certificate, you must take the same details, add a little more (dates during which the certificate is valid, a serial number), and build the certificate using some tool.
The variety of types and attributes of certificates particularly increases the complexity of certificate management.
Security leaders need to compensate for and manage several certificate formats that can define a wide range of specifications for metadata property such as encryption key length and cryptographic algorithms
Deploy the certificate on time with the proper configuration.
It could be a device, a server, an application, or even a website. Knowing the status and location of all certificates on your network is crucial.
One user must verify the certificate of another, and related CRLs, for performing public-key operations. A standard protocol must be in place to allow access to the certificates of other users and relevant information about the revocation. This includes creating digital public-key certificates and Certificate Revocation Lists to monitor the certificate’s status and interoperability with other client applications and other PKI’s.
The certificate will continue to function until its validity expires (the current standard is 398 days, which promotes an annual maintenance schedule with a small buffer).
Handling keys and certificates is the most common task of certificate management. Protocols to submit, update, back up, restore and revoke keys and certificates require interoperability between applications from clients and the Certification Authority. Some certificate management systems enable automatic certificate renewal within a specified pre-expiry period.
While some vendors provide life cycle management with their certificates, “true life cycle vendors” provide integrated certificates digitally signed by multiple CAs.
The administrator must either renew the certificate with the Certificate Authority that issued the certificate or revoke it and purchase a fresh one to be installed at the endpoint.
First, it gives administrators at-a-glance information regarding certificates and their statuses and provides quick answers to essential questions, such as:
Second, closely monitoring your certificates ensures that there is no blind spot in the system, which allows administrators to prevent outages by preemptively preventing expirations.
Authentication at the time of transaction involves verifying if the certificate is legitimate with the CA or with a server. This is done online from the receiver’s screen. If the certificate is withdrawn, the receiver is not going to do business based on it.
Each certificate is valid only for a limited amount of time. This period is described by a start date and time and an end date and time, and can be as short as a few seconds or almost as long as a century. The validity period chosen depends on several factors, such as the strength of the private key used to sign the certificate or the amount one will pay for a certificate.
This is the expected period that entities can rely on the public value if the associated private key has not been compromised.
Different circumstances can cause a certificate to become invalid before the validity period expires. These situations include a name change, a change of relationship between subject and CA (e.g., an employee ends employment with an organization), and compromise or alleged compromise of the related private key. In these cases, the CA must withdraw the certificate.
Certificate management also consists of the key task of revoking certificates.
X.509 certificates offer a mechanism for revoking certificates before their scheduled expiration date. In this process, the issuing CA periodically publishes a signed data structure called a Certificate Revocation List (CRL). The CRL is a time-stamped list containing information about certificates that have been revoked by the issuing CA or a designated CRL holder. This list includes the serial number of each revoked certificate and is made publicly available through a repository.
A benefit of this revocation approach is that CRLs can be distributed, through untrusted servers and untrusted communications, by the same means as certificates themselves.
One drawback of the CRL revocation method: the CRL will not be modified until all current CRL notifications are scheduled to be changed when a single revocation is issued.
This can be up to one hour, one day, or one week depending on the frequency of the CRLs being released.
Online revocation notification approaches could be available as an alternative to the X.509 CRL in specific environments.
The status of a certificate is considered to have changed if it is revoked or placed on hold. The following explains each condition.
A certificate is irreversibly revoked if, for example, it is discovered that the certificate authority (CA) had improperly issued a certificate, or if a private-key is thought to have been compromised. Certificates may also be revoked for failure of the identified entity to adhere to policy requirements, such as publication of false documents, misrepresentation of software behavior, or violation of any other policy specified by the CA operator or its customer.
The most common reason for revocation is the user no longer being in sole possession of the private key (e.g., the token containing the private key has been lost or stolen).
This reversible status can be used to note the temporary invalidity of the certificate (e.g., if the user is unsure or if they have lost the private key). In this example, the private key was found, and nobody had access to it, the status could be reinstated, and the certificate is valid again, thus removing the certificate from future CRLs.
In an era defined by digital transformation, building strong digital trust has become paramount. But it’s important to remember that your organization is responsible for establishing and maintaining its own digital trust, with identity management at the center.
Each device that connects to the internet or the public network requires at least one digital certificate to operate securely. But does your organization still rely on manual spreadsheet-based certificate tracking procedures?
Many companies still use manual certificate management processes that leave their most valuable data susceptible to infiltration. Managing certificates by manual process workflows, such as spreadsheets, almost always leads to an inability to account for all PKI certificates.
As the scope of the certificate is extended to devices, containers, and IoT, you will need to use automated certificate management to prevent system failures and increase efficiency. Certificate management is the best way to protect yourself against false certificates — valid certificates that have been compromised.
The ‘drop everything’ nature of responding to an outage only adds to a team’s burden. Having a certificate management solution and intelligent workflow automation can prevent these certificate outages and greatly benefit your organization.
Failure to renew certificates on time can result in complicated system outages. Yet pinpointing the root cause of outages is challenging in complex IT environments! But these certificate outages are costly, both in terms of downtime and the resources required to identify and remediate the issue.
Certificate-related outages disrupt critical services. They make your site inaccessible to employees and customers, which can impact productivity, revenue, customer satisfaction, and your company’s reputation. The consequences of inadequate certificate lifecycle management can also lead to compliance violations, audit failures, and legal liabilities, exposing your organization to fines and penalties.
We often refer to digital certificates as public-key certificates, since SSL certificates are made up of a private key and a public-key pair.
SSL is the standard for an encrypted connection between a web browser and a web server. The encrypted link uses encryption to mask the data between two parties so that the data remains privately kept and unchanged.
SSL stands for Secure Sockets Layer, a now-deprecated cryptographic protocol that has kept only its name in everyday use. All SSL certificates are technically TLS certificates, TLS being the successor of the SSL technology. TLS or Transport Layer Security is a more advanced and secure protocol that’s been the standard encryption technology for more than a decade.
The way TLS is used has also changed. The validation period for public certificates has decreased from two years to a little more than one year, with the extra time intended to promote annual SSL certificate management. To minimize outages caused by the expiration of manually managed certificates, you should first get a full view of all the certificates in your PKI. Then seek to automate your certificates’ lifecycle management processes as much as possible.
Security leaders need to ensure they are knowledgeable and manage a scaling repository of certificates. While external certificate management can be handled with manual methods such as spreadsheets, security leaders should simplify their approach with a certificate management solution. It can include reducing the time spent managing digital certificates and driving cost savings by maximizing SSL / TLS purchases.
Overall, if IT leaders have several hundred certificates from multiple CAs, we strongly recommend the use of certificate management software.
As companies continue to increase their use of mobile apps, whether corporate-issued or in-house, user identification remains essential. Therefore, when security leaders accept certificate-based methods to protect and identify their mobile devices, they must ensure their certificates’ robust and detailed full-lifecycle management.
The certificate management tool must discover certificates issued by mobile solutions for comprehensive certificate management cases.
You should determine the advantages of certificate management systems and resources that implement accessibility solutions.
Organizations have many factors to consider before embarking on IoT initiatives. When considering IoT’s certificate-based identity and authentication methods, security leaders will pursue solutions with embedded or interoperable certificate management systems. Although this is a new and evolving field, some security leaders may prefer to deploy purpose-built IoT platforms with tightly integrated PKI systems with integrated certificate management.
These systems may be independent of corporate or internal PKI systems, and certificates may not govern them. Organizations will need certificate management systems, software, and techniques to allow certificate-based IoT initiatives and strategies to optimize and extend their current PKI platforms.
As DevOps and virtualization continue to expand, security leaders need to recognize these fast-moving ecosystems’ protection and integrity.
While some methods use container identification, using digital certificates is one approach.
However, containers’ robust and elastic nature makes them unfeasible for manual certificate management methods.
When security leaders and their organizations rely on certificates to allow a wide variety of critical business applications, comprehensive management becomes a necessity quickly.
Of certificates, then security leaders would need to consider using a certificate management approach over spreadsheet-based methods.
Automated PKI applications should have access to update their keys for them quickly. Automated SSL solutions allow administrators to:
These details play an essential role in recovery because they help to enable scalable or automated recovery from potentially malicious actions.
Enterprise Certificate Management is the ideal solution to help enterprises secure a wide range of websites, including:
Intranet Sites:
Protect confidential information about your company on internal websites.
VPN Access:
Improve user experience with password-free Wi-Fi access while improving security and ensuring that only authorized users have access to your network.
Point of Sale (POS) systems:
Protect POS systems and ensure that only allowed POS terminals can connect to your payment system.
Networking Devices:
Improve the security of authentication for network switches and routers.
Internet of Things (IoT):
Automate the installation and management of certificates on connected built-in devices.
DevOps:
Ensure the identity and integrity of the containers, the code they contain, and the production applications that use that code.
Cloud / Multi-Cloud:
Secure cloud-based application and virtual server instances, on a single cloud provider or across multiple providers, for both single and multi-tenant environments.
Encryption Email signing:
Ensure emails are sent from the intended sender, protecting against fraud vectors such as phishing and Business Email Compromise (BEC).
Application Development:
Digitally sign software to protect end-users from downloading and installing compromised software.
Mobile Devices:
Improve the security and trust of mobile apps and machines on which they operate.
Peace of Mind:
Nobody wants to suffer the next botnet disaster.
Here are some important steps to consider as you look ahead:
