Certificate Authority (CA)

Definition: What Is a Certificate Authority?

A Certificate Authority (CA) is a trusted organization that issues and revokes digital certificates and certifies websites and other web entities. They do this by providing web entities with digital certificates for digital credentials and cryptographic keys for data encryption and protection in transit. These digital certificates confirm the domain ownership, validate identities, and help establish trust between entities as they communities over the internet. Thus, they make the internet more secure and play a key role in digital security.

Certificate authorities are the pillars of the internet’s PKI (public key infrastructure). The PKIs are established policies, procedures, and underlying frameworks that govern the digital certificate issuing and provide users with unique digital identities.

Why Do We Need Certificate Authorities?

To explain this, let’s go with a scenario.

The internet can be very dangerous, filled with hackers, scammers, and malware. So let’s say you wanted to read about DevOps, containers, and microservices, and you got a link that mentioned you would be redirected to a glossary, https://sematext.com/glossary/, to learn more.

However, it was a phishing link trick that redirected you to a malicious fake http://semtext.com/glosssary/.

How do you ensure a secure connection? How do you know that the website you’re visiting is safe? That’s what the certificate authority does.

The idea behind certificate authority is to verify a website’s or domain’s authenticity and certify organizations to ensure communication within the internet is secure.

For you, the visitor on a website, the certificate authority ensures you connect with the actual website, not a fake website created by someone trying to steal your digital or financial information. That’s why you get that warning messages like “your connection is not private” or “not secure” when visiting some sites. This means a CA has not validated the site, or their validation has expired.

However, for an organization, individual, or website, the digital certificate provided by the certificate authority validates them and assures their clients that they’re real and can be trusted. Hence CAs establish trust between the visitor and the entities online.

What Does a Certificate Authority Do?

The certificate authority stands at the forefront of the internet’s PKI by performing the following functions:

Verification and Validation

A certificate authority is responsible for verifying domain names and organizations to validate identities and ensure secure communication. The verification process typically involves authenticating the applicant’s identity and cross-checking it with government-issued and other identifying documents. Once the verification is done, the CA can issue the certificate. The validation process, however, differs based on the type of certificate requested. We will talk more about this later in this glossary.

Issues Digital Certificates

The CA issues digital certificates after the applicant submits a certificate signing request (CSR) and undergoes verification and validation. The CSR is an encoded document that requests digital certificates from CA. It contains details of the entity, domain name, subdomain names, contact information, and the applicant’s private and public key.

This digital certificate is a form of authentication and can come in various forms, from SSL/TLS certificates to email and object signing certificates.

Maintain Certificate Revocation Lists (CRLs)

In addition to issuing digital certificates, certificate authorities are also responsible for maintaining and revoking them. They achieve this by frequently maintaining a list of un-trustworthy digital certificates called the certificate revocation list (CRL), which consists of revoked and invalidated digital certificates.

Digital certificates can become invalid for various reasons, such as the certificate’s private key being compromised or the certificate’s expiration. The CRL distributed periodically by CAs includes information about these invalid certificates and serves as a reference for entities to check whether a given certificate is still valid. It is important to know that some CAs have an Online Certificate Status Protocol (OCSP) so anyone can query the server for real-time updates on revoked certificates. This provides more up-to-date information than relying solely on the periodically-published CRL.

How a Certificate Authority Works

When you visit a website like sematext.com, you see a padlock on your browser in the left corner of your search bar. That padlock icon represents the digital certificates (SSL/TLS certificate) and indicates that the connection is secure, encrypted, and private.

If you click on this padlock, you will see information about the certificate, including its validity period and the certificate holder’s identity. In addition to the padlock icon, another indication of a secure connection is using “HTTPS” in the website’s URL instead of “HTTP.”

However, a few key components are needed for this authentication technology to work:

• A digital certificate (for example, an SSL/TLS certificate) verifies the website’s identity and the authenticity of the digital message. It holds evidence of the message’s origin, status, and sender’s identity.
• A trusted certificate authority verifies the entity and issues the SSL/TLS certificates.
• A public key that your browser or anyone wanting to access the digital message encrypts data sent to the website.
• A private key is used to decrypt the data sent to the website. It is only known by the person it belongs to, and it’s never shared with anyone, including the CA.

Now to establish a secure and encrypted data exchange and connection between the client and the web server using SSL/TLS, these happen:

1. The client initiates the secure connection by simply visiting the website. This prompt specifies which cryptographic algorithms the client supports and sends a “Client Hello” message to the web server.
2. The server responds to the prompt by selecting the highest SSL/TLS version and cryptographic algorithm supported by both. This is called the “Server Hello”. The server also sends its SSL/TLS certificate to the client for certificate verification.
3. During the certificate verification, the digital signature on the server’s SSL/TLS certificate is certified against the public key and the CRLs of the CA that issued the certificate. The domain name is checked as well.
4. The server and client initiate a shared secret key exchange session using the selected asymmetric cryptographic algorithm. Using the private and public keys, SSL/TLS handshake, an encrypted communication involves data exchange, HTTP requests, and responses take place.
5. A “close Notify” message is sent by either or both entities—client and server— to indicate the termination of the session and that the secret session key is over. This connection must be ended to avoid a truncation attack. A truncation attack aims to intercept and decrypt the encrypted data exchanged by tearing down the SSL/TLS handshake.

Chain of Trust

The chain of trust, or SSL certificate chain, is a process that explains how an applicant’s certificate originates from a trusted source. This is important because, for a digital certificate to be authenticated and trusted, it needs to be traceable to the CA and its sign-off source.

The chain of trust is a hierarchical model made out of three types of certificates. To establish privacy, security, and trust, each certificate is signed by the private key of the next certificate:

• the root certificate is self-signed and represents the highest level of trust
• the intermediate certificate is validated by the root
• the end-entity certificate is signed by the intermediate certificate, and cannot issue additional certificates.

It is important to know that these certificates all have a validity period.

1. Root Certificates

Root certificates are self-signed digital certificates belonging to and protected by the issuing certificate authority. They are the trust anchor of all other certificates and are stored in a trust store, a repository of digital certificates used to establish trust in all security contexts. Thus, the CA keeps the private key used to sign this certificate a secret, while the public key used is distributed to sign off the intermediate CA certificate.

It is vital to know that root certificates are not used to sign end-entity CAs directly, as this will compromise the security and trust of the entire chain. Also, root certificates are pre-installed in web browsers and thus used to enable secure online communication.

2. Intermediate Certificates

Intermediate certificates are middle-level certificates that link the root and end-entity certificates issued to clients. These certificates are:

• Issued by the root and used to sign the end-entity digital certificates for the website and other secure communication systems that need digital certificates.
• Every certificate chain needs at least one intermediate certificate as it is needed to trace the root of a certificate.
• However some chains have multiple intermediate certificates. This serves as a backup in case one of the intermediate certificates becomes compromised or experiences an issue. While this might seem redundant, this ensures that the SSL chain of trust is intact, even in the event of a problem with one of the intermediate certificates.

The intermediate certificates make it possible for root certificates to be stored offline in secure storage, such as a hardware security module (HSM) or a USB drive stored in a safe or vault. This is because, as they are issued by CAs using single root certificates, thus they can be made publicly accessible. Therefore, there is no need for a client to see the root certificate with the chain of trust explained above.

3. End-Entity Certificate

End-entity certificates (also known as server or leaf certificates) are the final link in the chain of trust. They are digital certificates for authentication and enabling secure and private
connection between a client and the web server. These certificates are issued to a specific domain for encrypting online communication during the SSL/TLS handshake process. SSL connections will fail if this certificate is not verified and signed.

Although these certificates provide security and ensure compliance with CA standards, they don’t guarantee that the server is trustworthy and reputable. They only authenticate the identity of web servers and enable secure communication using SSL/TLS protocol.

How Does the Chain of Trust Work?

Similar to the SSL/TLS handshake highlighted earlier.

During SSL/TLS handshake certificate, the client verifies the server’s SSL/TLS certificate by checking the certificate’s digital signature against the public key and CRLs of the CA that issued the certificate. It also tries to trace the server’s SSL/TLS certificate back to its root by following the chain to the intermediate certificate installed until it arrives at a trusted root.

If the chain cannot be traced back to a trusted root, the SSL/TLS handshake will be terminated, or you will receive an SSL certificate error as a message in your browser warning that the connection is not private or secure. However, if a trusted root can be found, the SSL/TLS handshake will continue by establishing an encrypted connection for a secure and private data exchange.

Types of Digital Certificates CAs Issues

CAs issue various types of certificates with different use cases.

SSL/TLS Certificates

SSL certificates and TLS certificates are website security digital certificates and what actually comes to mind when digital certificates are mentioned, thus what we’ve discussed until now.

These certificates secure the communication between the web server, online services, and the client’s browser. They also protect sensitive digital information such as passwords and credit card details from man-in-the-middle attacks. SSL stands for Secure Sockets Layer, while TLS stands for Transport Layer Security, and they both use cryptographic protocols to provide secure communication. SSL/TLS helps secure online communication and verify the authenticity of websites, particularly in the context of HTTP and HTTPS.

For context, HTTP (Hypertext Transfer Protocol) is the data communication foundation of the World Wide Web. However, HTTP provides no encryption or security for the transmitted data. HTTPS (HTTP Secure) is a secure version of HTTP that uses SSL/TLS encryption.

SSL/TLS certificates can be identified by the padlock icon in your web browser’s search bar. They are categorized depending on validation levels and functionalities.

Based on validation level:

• Domain Validation (DV) verifies just the ownership of the domain. Thus, it doesn’t identify organizational information and cannot be used for commercial purposes.
• Organization Validation (OV) verifies the domain and the information provided by the organization against the Government hosted business registry databases. Thus, it is needed and used by organizations and public-facing websites.
• Extended Validation (EV) goes ahead of the Organization validation and verifies information like the organization’s rights to use a domain and its legal, operational, and physical existence. It is the highest level of authentication and verification.

Based on functionalities:

• Single-domain SSL/TLS certificates are issued just for a single domain or subdomain. An example is sematext.com. Yet, it is not unusual for a single SSL/TLS certificate to be used to secure an alternative subject alternative name (SAN). However, these certificates only cover the “www” version or the non-“www” version of a domain name, but not both.
• Multi-domain SSL/TLS certificates allow secure communication across multiple domains and SANs under a single certificate. For example, this certificate will permit secure communication for sematext.com and sematext.net
• Wildcard SSL/TLS certificates secure communication across a domain name and all of its subdomains under a single certificate. For example, it will allow secure communication for subdomains such as apps.sematext.com and test.sematext.com.
• Multi-domain Wildcard SSL/TLS certificates secure communication across unlimited domains and their subdomains under a single certificate. It is a combination of the Multi-Domain and Wildcard certificates. For example, it will allow secure communication for domains and subdomains such as apps.sematext.com, test.sematext.com, apps.sematext.net, and test.sematext.net.

Code Signing Certificates

Software companies use these certificates to digitally sign their software’s codes and programs to ensure their authenticity and integrity. This adds an extra layer of security and trusts for end-users as this provides a means for validating software before downloading it from the vendor.

They are often embedded as digital signatures and can tell end-users if the code has been tampered with since it was originally signed.

Email Signing Certificates

These are used to authenticate individuals and clients to web servers and to sign and encrypt email messages using the Secure/Multipurpose Internet Mail Extensions protocol (S/MIME). Thus, they are also known as S/MIME certificates, personal and client authentication emails.

This protocol verifies the sender’s identity, checks for phished links, and the integrity of the email. These certificates are important and almost compulsory for industries like finance and the government sector, where secure and confidential communication is critical.

Various email clients, like Microsoft Outlook and Mozilla Thunderbird, support these certificates.

Object Signing Certificates

These certificates are very similar to code signing certificates. The difference is that object signing certificates are used not just for codes but also to sign and authenticate any software object. By software objects, we mean codes or executable software from applications to plugins, macros, libraries, and scripts.

User/Client Signing Certificates

These certificates help individuals authenticate and validate electronic documents, their sender, and the document’s integrity. They are used when users need to sign electronic documents and emails with their digital signatures, providing an additional layer of security and trust.

Device Certificates

These certificates establish secure and private communications between Internet of Things (IoT) devices, servers, and the Internet, minimizing the risk of unauthorized access or data breaches. They can be used in many IoT applications, such as smart homes and industrial automation.

Public CA vs. Private CA

There are two types of certificate authorities—public and private CA—which provide certificate-issuing services for different organizational needs.

Public certificate authorities provide CA services to the general public and are not associated with the certificate recipient. They are also called trusted CA and commercial CA. They emit trusted digital certificates that meet the basic requirements outlined by the CA/Browser (CA/B).

On the other hand, private certificate authorities provide self-hosted CA services just internally. For example, a university issuing digital certificates to their private domains and internal entities. Thus their services have a limited scope and are rarely trusted by users outside the organization. However, this is okay since they’re not used to interfacing with outside networks.

In terms of security and trust, it’s not that easy to say which one is more secure. Web browsers and software trust public CAs by default because external entities can monitor them. Thus, anyone can determine if they comply with industry standards and security best practices. In contrast, private CAs can’t be monitored by external parties. However, they provide a higher sense of security as they have fewer failure points and issue certificates to specific and limited entities for internal use only.

From an economical standpoint, public CA can be more cost-effective to some extent for organizations because the CA handles the infrastructure needed to issue certificates. They are also considered cost-effective and economical if you (an organization) need to buy a limited number of certificates. On the other hand, private CAs require a significant financial commitment as you have to set up, run, and manage the infrastructure yourself. Hence, they are mostly used by big organizations. Note that public-facing organizations need at least one public CA.

So, how do you choose between public and private CAs? In short,

• Public CAs are generally suitable for enabling user authentication for public-facing sites and securing communication systems such as websites, email servers, and other secure communication channels. They are also suitable for digitally signing codes for organizational software and encrypting emails.
• Private CAs are mostly suitable for enabling user authentication for internal systems and securing internal resources, including DevOps build servers and testing environments.

Certificate Monitoring and Management

Digital certificates have a validity period, typically one to three years, depending on the organization’s policies and the certificate’s type. After this period, these certificates become invalid, expire, and can no longer be recognized during the SSL/TLS handshake. For website processing payments or sensitive information (such as credit card details), an invalid certificate leads to HTTPS encryption failure and compliance violations, leading to legal issues. For software, this leads to code check failure and security vulnerability.

Thus, your certificates must be renewed before expiring to ensure continuous secure communication.

What Happens When an SSL/TLS Certificate Expires?

When your SSL/TSL certificate expires, any clients that visit your client encounter the “your connection is not private” or “not secure” warning messages. This is because all benefits of authentication and HTTPS are lost. Also, any third-party APIs your website calls result in 401 or Mixed Content errors.

This is particularly bad, especially for your user-facing APIs and public-facing websites. It can result in losing clients’ trust, traffic drop-offs, and damage the brand’s reputation.

How to Prevent Your SSL/TLS Certificates From Expiring?

Monitoring your certificates with a certificate monitoring tool to monitor SSL certificate expiry, validity, and change is the simplest way to keep track of them. However, even with these tools, Organizations still need help with certificate management and monitoring for several reasons:

• Numerous certificates; an organization can have multiple SSL/TLS certificates, codes, emails, and object signing certificates.
• Keeping track can be challenging because their digital certificates have different renewal cycles.
• The whole process is manual, so it is easy to miss a few.
• Their tool doesn’t provide detailed monitoring information.

Hence, your certificate management SaaS solution should be able to alert you when the expiry date is close so that you can renew them in time. One such solution is Sematext Synthetics.

Certificate Monitoring with Sematext

Sematext Synthetics, an integral part of Sematext’s monitoring suite, provides advanced capabilities for monitoring digital certificates. It helps you maintain a secure and reliable online presence by ensuring the integrity, validity and proper functioning of your certificates.

Synthetics performs comprehensive SSL certificate checks on all certificates in the chain, including the leaf, intermediate, and root certificates. By leveraging an actual Google Chrome browser that lets you simulate how your users actually experience your websites’ page loading times, the tool conducts real-time certificate validation. This proactive approach enables you to catch errors and vulnerabilities before they impact your end-users. It allows to make sure that your certificates are valid and trusted so that you can provide a seamless browsing experience for your customers.

Additionally, Sematext Synthetics excels in monitoring certificate expiry dates. It regularly checks the expiration status of your certificates and sends timely alerts at configurable intervals, such as 28, 14, 7, and 3 days before they are due to become invalid. This way you to take necessary actions, such as certificate renewal or replacement, well in advance, preventing any service disruptions caused by expired certificates.

Sematext Synthetics goes further by monitoring any changes to your certificates. It performs frequent checks every 10 minutes, detecting and alerting you to any modifications or updates made to your certificates. With detailed change reports, you can quickly identify and investigate any unauthorized or unexpected changes, ensuring the security and compliance of your certificate infrastructure.

Experience the power of Sematext Synthetics and its Certificate Monitoring capabilities by starting your 14-day free trial.