What is a Digital Certificate?
Also known as digital IDs, digital certificates contain the basic information necessary to authenticate the identity of people, places, and virtual "things." The certificates are bound to a unique public/private key-pair, which enables us to verify the identity of practically anything across any network environment. Unlike the public key, the private key must remain secure — like a password, only the owner should know the private key.
Digital certificates are essential as they allow us to identify trusted individuals and organizations. They are critical for creating trust in today's ever-growing connected world.
Every certificate fall into one of three basic categories:
- Self-sign certificates transmit a public key to launch the credential paths for use.
- CA certificates from separate organizations are the issuer and the subject.
- Cross-certification extends third-party trust relationships between Certification Authority domains. Cross-certificates reflect a relationship of confidence between the two CAs.
Who is the Certificate Authority?
A certification 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 certification authority can refer to:
- An organization that vouches for the identity of an end-user
- A server that is used by the organization to issue and manage certificates
- Private Certificate Authority
By installing the Certification 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. Remember, not everyone will accept self-signed certificates; one value public CA offers to serve as a neutral and trustworthy introductory service, partly based on their authentication criteria, published freely in the CA's Certification Service Practices (CSP).
Typical uses of Private CA's include:
- Intranet sites
- Virtual Private Network (VPN) certificate or wireless authentication
- Device identification
- IoT (Internet of Things) projects
Secure communications between internal services and interoperable communications between third parties, including containerized or application program interface (API) connected cloud environments.
How do I get a Certificate?
There are two common strategies used for obtaining certificates: you can produce one by yourself, or you can send a Certificate Signing Request to a qualified Certification Authority, and they will generate and sign a certificate for you.
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.
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.
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 aspect of the 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 and PKI Architecture
Certificate Management is discovering, analyzing, monitoring, and managing all digital certificates de-ployed by the Certificate Authority. Proper certificate management should be fundamental to your oranization'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 sensi-tive 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. The server's certificate contains an asymmetric public and private key pair, while the session key created by the server and the browser is symmetrical. After I have exchanged the secret key, the rest of the communication uses symmetrical encryption.
The main entities that play a role in PKI Certificate Management are as follows:
The Certification 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.
End entity certificates
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:
- Code Signing
- Internet of Things (IoT)
- Bring Your Own Device (BYOD)
- Time Stamping
- Access Management
- Automated Registration
- S/MIME Email Servers
- Internal Root Certificate
- Legally binding Electronic Signatures
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
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. However, 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.
Certificates Discovery is the process by which the entire network infrastructure is checked to determine where each certificate is installed and to verify if it is implemented correctly. Using a discovery scan ensures the network is free of unknown certificates that may probably have unresolved bugs that might become weak links that could be exploited.
Organizing certificates into a centralized inventory makes certificate operations such as renewals and revocations easier. Relate devices to certificates, to keep track of each device's status and know how much time is remaining until corresponding certificates expire. A common practice is to categorize certificates based on their intended purpose.
Generation: Generate or purchase a signed certificate from the CA
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. Not all will accept self-signed certificates; one aspect of the value a CA offers 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).
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.
Issuance: 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.
Supervision: Store and manage all certificates on centralized servers, distributed systems, and cloud platforms.
The certificate will continue to function until its validity expires (which could be anywhere from a few months to 2 years, with the maximum period of validity).
Handling keys and certificates is the most common PKI operation. 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 CA.
- Manage all the certificates in the chain.
- Ensure FIPS-140-2 compliance with cipher suite audits and algorithm reporting.
- Use custom fields for additional data storage.
Monitor: Renew them before expiry to avoid a gap in the certificate's validity.
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.
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, such as:
- How many certificates did each CA issue?
- How many need to be renewed?
- How many require replacement?
Closely monitoring your certificates ensures that there is no blind spot in the system, which allows administrators to prevent outages by preemptively preventing expirations.
- Track the purchase orders and costs of certificates
- Get notified in advance before your certificates expire.
- Prevent downtime and embarrassment caused by certificates expiring before it's noticed.
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.
X.509 certificate specifies one process for revoking the certificate. This approach includes each CA issuing a signed data structure periodically, called a list of certificate revocation (CRL). A CRL is a time-stamped list that lists the revoked certificates issued by a CA or CRL holder and made available publicly in a public repository. Its serial number in a CRL knows each revoked certificate.
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 having 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.
Inadequate management of certificates may cause significant adverse business effects from device downtime and Increased incident response costs to the company and the potential for harm to the brand.
The following sections explain to the two most significant risks in certificates management:
System downtime from expired certificates
Certificates expire, whether due to lack of knowledge or supervision, but this is one very costly mistake you want to avoid.
"On average, it costs large organizations $15 million per certificate outage. In addition, there are consequences for security and brand reputation, including a decline in customer trust and sales."
2020 Keyfactor-Ponemon Report
One of the most critical aspects of minimizing the risk of unrecognized digital identities is to know the expiry date of all your certificates—failure to renew certificates on time and results in system outages. If an expired certificate shows one of your domain names, a potential attacker can impersonate your organization. When malicious actors uncover a private key, more valuable data is easily compromised by impersonating your servers.
Unfortunately, too many companies still use manual 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. Hence, when a certificate is distributed across a multi-cloud, heterogeneous environment, information such as locations, owners, associated applications, expiry dates, and signatures must be recorded diligently.
Management by spreadsheet
With the advent of digital transformation, an unprecedented explosion has occurred in the number of connected devices used today. Each device that connects to the internet or the public network requires at least one digital certificate to operate securely.
As the scope of the certificate is extended to devices, containers, and IoTs, you will need to use automated certificate management to prevent system failures and increase process efficiency. This is the best way to protect yourself against false certificates — valid certificates that have been compromised.
Even though some of the most reliable cybersecurity firms provide automated certificate management services, some organizations still rely on manual spreadsheet-based certificate tracking procedures. Conversely, proactive safety managers use systematic lifecycle management and discovery-centered approaches to assess the number of certificates deployed and the time until they expire. They offer full-time certificate management solutions and intelligent workflow automation to complex certificate-based enterprise environments.
How do SSL certificates work?
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 now the standard encryption technology for more than a decade.
During the last few years, we've seen the use of Transport Layer Security (TLS) on the web expand to more than 96% of all Chrome-written traffic on the Chrome OS. That's a rise of more than 35% in just four years, as recorded in our Google Transparency Report.
The way TLS is used has also changed. The validation period for public certificates has decreased from five to two years, which will soon be reduced to 1 year. 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 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.
Certificates and IoT Protection
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.
DevOps, Virtualization, and DevSecOps
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 Certificate Management Environment
Automated PKI applications should have access to update their keys for them quickly. Automated SSL solutions allow administrators to:
- connect devices, applications, and digital identities
- enforce policies and reduce risk with automated workflow
- enforce configurable approval and authorization and detailed logging
These details play an essential role in recovery because they help to enable scalable or automated recovery from potentially malicious actions.
Website Use Cases
Enterprise Certificate Management is the ideal solution to help enterprises secure a wide range of websites, including:
- Intranet Portals
- Ecommerce sites
- Financial services sites
- Customer service sites
- Customer information sites
- Data gathering sites
- Governments' constituent relations sites
Other Use Cases
SSH key management: Discover keys that continue to give past employees access and issue new certificates to employees, replacing the older approach.
Protect confidential information about your company on internal websites.
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.
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.
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).
Digitally sign software to protect end-users from downloading and installing compromised software.
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.
- Determine whether current PKI or external certificate providers provide certificate management solutions or tools.
- If this number reaches 100, certificate management approaches and other risk reduction methods will be introduced.
- Implement automated certificate discovery and renewal management software to reduce the risk of certificates expiring unexpectedly.
- Manual and automated certificate management can delegate responsibility and control to certificates within organizations.
- Consider full-lifecycle certificate discovery and management tools, especially when dealing with complicated, multi-vendor certificate environments use cases like mobile and IoT.
- As security leaders formalize plans to incorporate additional mission-critical use cases, formalized and more comprehensive management of certificates will move from "nice-to-have" to "must-have." As reliance on certificates increases, so will the effect of an activity or security incident.
- Security leaders can improve organizational performance and security by using full-life management methods for dynamic environments.
- Ensure that certificate management is part of the overall cybersecurity response plan to help prepare for security incidents involving obsolete cryptographic algorithms and CA compromises.