Certificates, Authorities, and Management (Domain 1)

In this episode, we will explore the world of digital certificates, certificate authorities, and the infrastructure of trust that secures much of the internet. From verifying websites to encrypting messages and establishing secure connections, digital certificates serve as a foundation for cryptographic trust. Understanding how certificates are created, validated, revoked, and managed is critical knowledge for anyone pursuing the Security Plus certification.
Let’s start with certificate authorities. A certificate authority is a trusted organization responsible for issuing digital certificates. These certificates bind a public key to an entity—such as a person, website, or company—and serve as proof of identity in the digital world. When your browser connects to a secure website, it checks the site’s certificate to confirm that it was issued by a known and trusted certificate authority. This verification is what enables secure web traffic and prevents impersonation.
The certificate authority is responsible for verifying the identity of the certificate requester before issuing a certificate. This may involve checking domain ownership, organization details, or legal documents, depending on the type of certificate. Once verified, the certificate authority uses its private key to sign the requester’s public key and generate a certificate. This digital signature proves that the certificate is legitimate and has not been tampered with.
However, the trust placed in certificate authorities also makes them a potential target. If a certificate authority is compromised or issues certificates improperly, attackers could use forged certificates to impersonate trusted websites or intercept secure communications. For this reason, certificate authorities are required to follow strict security practices, and their behavior is closely monitored by browsers and operating systems.
Next, let’s talk about certificate revocation and real-time validation. Sometimes, a certificate must be revoked before it expires. This can happen if the private key is compromised, the certificate was issued in error, or the certificate owner is no longer trusted. To manage this, organizations use certificate revocation lists and the Online Certificate Status Protocol.
A certificate revocation list is a published list of revoked certificates maintained by the certificate authority. Systems can download the list and check whether a given certificate is still valid. While effective, this approach can introduce delays, especially if the list grows large or is updated infrequently.
The Online Certificate Status Protocol provides a faster and more efficient way to check certificate validity. Instead of downloading an entire list, the system sends a real-time query to the issuing certificate authority’s server and receives a response confirming whether the certificate is valid, revoked, or unknown. This allows for quicker decisions and supports more dynamic trust models.
Now let’s discuss different types of certificates. A self-signed certificate is one that is created and signed by the entity itself, rather than by a trusted certificate authority. These are often used for internal systems, development environments, or testing purposes. The advantage is that they are free and easy to generate. The drawback is that they are not trusted by default, and users must manually accept them or install them into their system’s trust store.
Third-party certificates, issued by recognized certificate authorities, are used for public-facing services and applications. They provide trusted verification and reduce the likelihood of users encountering warnings or errors when connecting. These certificates are a key part of commercial websites, online banking, and secure email systems.
Another option is wildcard certificates. These certificates can secure multiple subdomains under the same root domain. For example, a wildcard certificate for “star dot example dot com” could secure “mail dot example dot com,” “store dot example dot com,” and “support dot example dot com.” Wildcard certificates simplify deployment by reducing the number of individual certificates needed.
However, they come with trade-offs. If the wildcard certificate’s private key is compromised, all subdomains are at risk. Organizations must weigh the convenience of wildcard certificates against the broader attack surface they create. For large environments with shared administration, using separate certificates per service may offer better compartmentalization.
Next, we turn to the root of trust and certificate signing requests. The root of trust is the foundation of a secure cryptographic hierarchy. It is typically a root certificate, issued and signed by a trusted certificate authority. All other certificates are derived from this root, forming a chain of trust. If the root certificate is trusted, then certificates signed by it—or by intermediate authorities beneath it—are also trusted.
When an organization wants to obtain a certificate from a certificate authority, it creates a certificate signing request. This is a file that includes the entity’s public key and identifying information, such as domain name or organization name. The certificate signing request is submitted to the certificate authority, which verifies the details, signs the request using its private key, and returns a completed certificate.
Tools for generating certificate signing requests include OpenSSL, Windows Certificate Services, and certificate management platforms provided by cloud providers or security vendors. The process typically involves generating a key pair, preparing the signing request, and securely transmitting it to the certificate authority. Once signed, the certificate is installed on the server or application and used to establish secure connections.
As you prepare for the Security Plus exam, be ready to explain the roles and responsibilities of certificate authorities, the difference between certificate revocation lists and the Online Certificate Status Protocol, and the trade-offs between self-signed, third-party, and wildcard certificates. You should also understand how the root of trust supports digital validation, and be familiar with the process of creating and submitting a certificate signing request.

Certificates, Authorities, and Management (Domain 1)
Broadcast by