Skip to content

Certificates↑

Failure to properly manage and validate certificates risks data theft, service outages or impersonation attacks. Certificates are the Achilles’ heel of public-key cryptography, as they bind an identity (for example, a domain name, software provider, or user credential) to a cryptographic key. Without this binding, no security guarantees can be given. Effective certificate management is essential and involves:

  • Securely storing all signing keys.
  • Regularly renewing organizational certificates before they expire.
  • Carefully validating third-party certificates.

Neglecting these practices compromises the security of cryptographic systems.

The role of certificates↑

Consider two of the most fundamental security goals in computing:

  1. Confidentiality: Public-key cryptography is commonly used to establish secure communication between parties who have not previously shared a confidential channel. For example, TLS relies on this protocol whenever a new connection is initiated. To ensure security, the sender must verify that the public key they are using to encrypt messages belongs to the intended recipient. Failure to do so can result in an attacker-in-the-middle attack1 that compromises the communication.

  2. Authenticity: Digital signatures are widely used to verify the authenticity of documents, messages or software. To be able to validate a signature, the receiver must confirm that the signer is who they claim to be.

In both cases, certificates are the standard method for ensuring authenticity. A certificate is a digital signature that binds cryptographic key material (such as encryption or verification keys) to some identity information. For example, a web certificate binds a verification key to a domain name or organization. Certificates are issued by a trusted entity known as a Certification Authority (CA).

Public Key Infrastructure (PKI)↑

Digital signature schemes enable the holder of a private signing key to create signatures that can be verified using a corresponding verification key. This implies, however, that certificates introduce a recursive challenge: they use signatures to validate key material, but verifying these signatures requires confidence in the origin of the verification key to verify the certificate itself.

This challenge is addressed through Public Key Infrastructure (PKI). PKI relies on a hierarchy of trust, starting with root certificates issued by trusted root Certification Authorities (CAs). These root certificates, distributed with major software (such as web browsers), serve as the foundation of trust. Root CAs sign the public verification keys of intermediate CAs, which can further sign other intermediate keys or end-entity certificates, such as those used for websites or applications.

A PKI is essential for ensuring both confidentiality and authentication, whether on the global internet or within corporate networks. By establishing a trusted chain of certificates, a PKI enables secure communication and identity verification.

Potential vulnerabilities↑

Failures in certificate management and validation can introduce several vulnerabilities, including the following:

  • Compromised signing keys. Secret signing keys must be carefully protected, as their compromise gives malicious actors significant power. Certificates include expiration dates to limit the exposure window of a compromised key. Historically, web server certificates had lifetimes measured in years, but shorter durations of 45–90 days are now standard. For long-term use cases, such as root CA certificates or embedded devices, longer lifetimes remain necessary. Regardless of duration, certificates nearing expiration should be replaced promptly, typically around 80% of their validity period.
  • Rogue Certificate Authorities (CAs). Some Certificate Authorities (CAs) have acted maliciously or negligently, issuing certificates that enable malicious third parties to impersonate legitimate entities. To mitigate this risk, certificate transparency logs are used. These secure, append-only databases record information about issued certificates, making it possible to detect and verify potentially rogue certificates.

  • Weak digital signature algorithms. The security of certificates relies on robust digital signature algorithms. This includes:

    • Avoiding key lengths that are too weak to resist known attacks.
    • Using algorithms resistant to attacks by quantum-equipped adversaries when quantum readiness is a security goal.

  • Hash Function Vulnerabilities. Digital signatures on certificates work by signing a digest (hash) of the data being authenticated, such as some key material and an identity. Consequently, the security of hash functions directly impacts certificate security. Key considerations include:

    • Avoid weak hash functions that lack collision resistance, such as MD5 and SHA-1.
    • Avoid truncated hash outputs. These allow “birthday-style” attacks, where an attacker attempts to find two different inputs that produce the same hash. This is because shorter hashes allow for fewer possible values.
  • Self-Signed Certificates. Many technologies require public-key material provided in a certificate. To meet this requirement, developers sometimes use a self-signed certificate—a certificate which validates itself instead of being verified by a trusted CA. However, self-signed certificates provide no authentication assurances and should not be used in production systems, such as public-facing websites, API endpoints, VPNs and remote access services, or code signing. In these and similar scenarios, a self-signed certificate can disrupt functionality, introduce security vulnerabilities, or degrade user experience. Instead, production environments should rely on certificates issued by trusted CAs.

  • Expired or invalid certificates. The most common issues related to certificates include:

    • Expired certificates that have not been replaced before their expiration date. That is, the day of verification is later than the end date of the validity period.
    • Invalid Certificates, such as certificates where the domain name does not match the “Common Name (CN)” field.

Sources↑

  1. Historically, this class of attacks was known as a Man-in-the-Middle (MITM) attack. The term attacker in the middle is more common, although some prefer Machine-in-the-Middle or Mallory-in-the-Middle to retain the well-known acronym MITM. ↩