Vulnerable to Bulletproof: Protect TLS via Certificate Posture Management

You have likely heard members of your IT operations team quip on more than one occasion, “If only we had a way to track all certificates and their expiration dates, our lives would be so much easier!” With countless hostnames, applications, and services, managing provisioned certificates is a daunting task, and the consequences of failing to rotate a certificate can be catastrophic.

To tackle this challenge, Akamai recently introduced Certificate Posture Management, a component of Akamai DNS Posture Management that offers a unified view of all certificate expiration dates across an organization’s domains. 

Beyond visibility, Certificate Posture Management proactively alerts administrators to Transport Layer Security (TLS) vulnerabilities, including weak ciphers, inadequate key sizes, post-quantum noncompliance, and unauthorized issuances.

Key use cases for Certificate Posture Management include certificate lifecycle management, compliance monitoring, and security vulnerability remediation across hybrid infrastructures. The platform's automation capabilities eliminate manual tracking processes, while customizable workflows ensure that the right teams receive timely notifications based on certificate criticality and organizational policies.

During security events, Certificate Posture Management integrates seamlessly with existing incident response procedures, providing real-time certificate status updates and automated remediation recommendations to minimize service disruptions.

By illuminating the entire certificate ecosystem, Certificate Posture Management empowers security teams to ensure compliance, renew certificates promptly, and remediate TLS vulnerabilities efficiently, which reduces security risks and enhances operational resilience across multicloud environments.

Before diving into the specific features of Certificate Posture Management, it is worth outlining how TLS works from a cryptographic perspective. Although this overview does not describe the exact order of the steps involved in the protocol’s handshake, it outlines the necessary exchanges required to achieve: 

• Authentication
• Encryption 
• Integrity of messages

Certificate Authorities (CAs) verify domain ownership and issue digital certificates by signing the server’s public key and associated metadata with a private key. The combination of the hashing function and public key cryptography to generate this signature is called the signature algorithm. Clients verify this signature using the CA’s trusted public key.

In older TLS versions, the server might prove ownership of its private key through a challenge via an encrypted random message that only the server could decrypt. However, modern TLS (1.3) uses ephemeral key exchanges to validate server private key ownership.

The two parties will negotiate a TLS version, which governs how the client and server establish the necessary parameters to achieve encryption and authentication. For example, today’s TLS 1.3 accomplishes this “handshake” to align on the session ID, cipher suite, and key exchange method in one round trip, while prior versions require at least two. 

Specifically, under TLS 1.3, encrypted application data is sent alongside the ServerHello, to avoid an unnecessary client ACK, as both sides will have the necessary information to calculate the session key after this single round trip. 

During this handshake, the client and server will agree on a key exchange algorithm, such as RSA, DH, ECDH, DHE, ECDHE, or PSK. Ephemeral Diffie–Hellman is the current preferred method, as it achieves “perfect forward secrecy” (guaranteed by TLS 1.3) — a standard that ensures that the process to generate the symmetric session key is completely independent of the server’s enduring asymmetric key pair. 

This way, even if the server’s private key was exposed, prior messages could not be decrypted. Instead, both parties arrive at the same session key value independently by exchanging public parameters that are derived from temporary private secrets that both sides generate during the handshake. 

Conversely, the Rivest–Shamir–Adleman (RSA) cryptosystem, which does not adhere to this principle, requires the client to relay an encrypted “pre-master” secret to the server, so both machines can calculate a symmetric session key from this value. However, if the server’s private key was ever compromised, an attacker would be able to decrypt all messages that traversed these connections by executing “man in the middle attack or by revisiting harvested data, since the pre-master secret was encrypted via the enduring asymmetric key pair.

A shared cipher is also established during the handshake. The bulk encryption cipher (e.g., AES-256 in GCM mode) uses the symmetric encryption key to encrypt application data. For example, in AES_256_GCM, the key (256 bits) is passed into the Advanced Encryption Standard (AES) algorithm to transform plaintext into ciphertext.

And, finally, the two parties will choose a hash-based message authentication code (HMAC) hashing function — such as SHA-1, MD5, or RIPEMD-128/60 — to hash an encrypted message with the help of the shared, secret symmetric key. The encrypted message will be sent alongside the corresponding HMAC output of this data. 

This way, the recipient can hash the encrypted message to confirm the values match. Since the HMAC relies on the shared secret key to generate the output, an attacker will not be able to properly hash the corrupted value because the attacker shouldn’t possess the symmetric key.

TLS is susceptible to numerous attack vectors that seek to decrypt messages, impersonate trusted endpoints, or tamper with data in transit. Attackers often exploit weak certificate authority (CA) signature algorithms or target vulnerable TLS configurations between clients and servers. Certificate Posture Management provides clear visibility into these risks and offers actionable insights for administrators to strengthen their TLS security posture.

A weak CA signature algorithm can lead to the exposure of the Certificate Authorities private key, which would allow an attacker to simply sign an illegitimate certificate with this stolen secret and host it on a malicious server with impunity. 

To help address this risk, the Certificate Posture Management interface will flag weak CA key sizes that are susceptible to brute-force attacks. A 128-bit symmetric key (like AES) is considered secure because brute-forcing 2¹²⁸ possibilities is computationally impossible. However, a 64-bit key opens the door to an attacker that is relying on software to generate enough combinations to eventually arrive at the secret.

In addition, the dashboard will also indicate whether the CA’s signature algorithm is relying on  deprecated hashing algorithms such as MD5 or SHA-1, which are subject to “collisions,” meaning that it is possible to craft two distinct inputs that result in the same hash output. So, in theory, an attacker could manipulate the signed certificate in transit without the client detecting any malfeasance.

Certificate Posture Management validates if the latest TLS version is supported by the server, as legacy TLS versions frequently involve well-known vulnerabilities that could help attackers reverse-engineer the session symmetric key or decipher plaintext data. Specifically, legacy versions allow weak ciphers and do not guarantee forward secrecy. 

For example, TLS 1.1 and TLS 1.2 permit CBC mode, which requires padding to fill out blocks (AES block size is 16 bytes). If a server responds differently when padding is correct vs. incorrect, an attacker can learn information about the plaintext through a padding oracle attack. These versions also permit RC4, which is susceptible to statistical biases that allow attackers to recover plaintext with enough captured data.

The dashboard also highlights whether the key exchange method is consistent with perfectly forward secrecy (although it is worth reiterating that TLS 1.3 requires this standard). Perfect forward secrecy ensures that past messages will remain encrypted even if the private key of the server is exposed. 

As we’ve discussed, this is because the mechanism to generate the symmetric key responsible for encrypting application data does not involve the server’s asymmetric key pair. 

Long certificate expiration durations are also flagged, as the risk of private key exposure increases the longer the certificate is valid. Therefore, it’s recommended to renew certificates every year at a minimum.

The industry’s anxiety over these types of vulnerabilities has increased with the anticipation of quantum computers. Attackers have begun harvesting encrypted messages, biding their time until quantum computing has the ability to break widely used asymmetric cryptographic schemes that govern key exchanges and digital signatures (symmetric cryptography and hash functions used in TLS are generally more resistant).

Although new fields of physics or computer science need to be discovered before anyone can construct a quantum computer capable of breaking contemporary asymmetric keys, the National Institute of Standards and Technology (NIST) has been leading a global effort since 2016 to standardize post-quantum algorithms. In 2022, they announced the first standardized algorithms, including CRYSTALS-Kyber for key encapsulation and CRYSTALS-Dilithium for digital signatures.

Certificate Posture Management audits both the CA’s and the server’s signature algorithm, along with the key exchange method, to highlight elements that are not compliant with the NIST recommendations. As you might expect, more and more internet services, websites, and providers, including Akamai, are transitioning to a post-quantum world, and Certificate Posture Management offers the necessary visibility to assist administrators in this important journey.

A rogue certificate is a valid, trusted certificate mistakenly issued to an unauthorized actor. When this occurs, an unsuspecting client may unknowingly communicate with a malicious actor without any hint of malfeasance, since the server's key pair was endorsed by a trusted CA. 

DNS Posture Management enables administrators to set up alerts for certificates issued by unfamiliar CAs, and its comprehensive visibility allows users to filter by the latest certificate updates to help organizations verify that all were initiated by authorized individuals or services. Additionally, alerts can be configured to trigger whenever a brand-new certificate is issued, enabling administrators to promptly identify any rogue issuances.

This interface is a component of the DNS Posture Management product, which uses agentless, side-scanning technology to unify visibility across DNS environments and proactively detect misconfigurations.

To onboard a zone onto DNS Posture Management, a user will upload the necessary auth details to access zone information (e.g., if Akamai Edge DNS is where your zone is hosted, you would provide OpenAPI access credentials to read the Edge DNS settings). The platform will then pull all the relevant records and change management history. If you host your zone on-premises and do not support API access, there is a “NoAuth option” to discover the zone’s records via the open internet.

Once zones are onboarded, DNS Posture Management will scan Certificate Transparency (CT) logs that match the domains belonging to the discovered zones. These logs are append-only, tamper-evident records of public TLS certificates, designed to enhance the security and accountability of the certificate ecosystem. 

Certificate Posture Management continually pulls these CT logs to help administrators consume this information in an easily digestible and intuitive dashboard. DNS Posture Management also supports an API that allows users to query CT logs, along with the aforementioned information from Certificate Posture Management.

Certificate Posture Management is a critical security tool for modern cybersecurity operations, providing a centralized solution to monitor and manage TLS certificate lifecycles effectively. Through continuous monitoring and real-time insights, Certificate Posture Management empowers organizations to maintain a robust security posture, helps ensure compliance with industry standards, and prepares organizations for emerging threats like quantum computing.

With its integration into DNS Posture Management and features like Certificate Transparency log scanning, Certificate Posture Management enables administrators to proactively mitigate security incidents, enhance encryption security, protect sensitive data and prevent costly outages, making it an indispensable asset for safeguarding digital ecosystems.