TLS

Cybersecurity / 13 Sep 2026 / 8 min read

Certificate Revocation Is a Distributed Freshness Problem

Certificate Revocation Is a Distributed Freshness Problem A private key can be exposed at 10:00, its certificate can be revoked at 10:15, and some clients can still face a harder question at 10:16: do they possess current enough evidence to reject it? That gap is easy to miss when revocation is described as a property attached to a certificate. X.509 certificates are signed objects with validity periods; changing the certificate after issuance would invalidate its signature. Revocation therefore lives outside the certificate itself. A relying party needs separate status information, needs that information to be sufficiently recent, and needs a policy for cases in which status cannot be obtained.

Cybersecurity TLS

Cybersecurity / 12 Sep 2026 / 7 min read

Use Certificate Transparency as a Detection Signal

A TLS certificate can be valid in every cryptographic sense and still be operationally unexpected. A forgotten staging host may receive a certificate through an automated pipeline. A vendor may issue for a delegated subdomain that the central security team did not know existed. More seriously, an attacker who gains control of a DNS validation path or a certificate-authority account may obtain a certificate for a name they should not control.

Cybersecurity TLS

Cybersecurity / 12 Sep 2026 / 6 min read

Certificate Transparency Turns Issuance Into an Observable Event

A public TLS certificate can be perfectly valid and still be operationally alarming. A certificate authority may have followed its validation rules, the signature chain may verify, and browsers may accept the credential without complaint. Yet the organization named in that certificate may never have intended the hostname to exist. That gap matters because certificate issuance is an authorization event with security consequences. Certificate Transparency makes much of that event visible. Publicly trusted certificate authorities submit certificate information to append-only logs, giving domain operators and the wider ecosystem a record that can expose unexpected issuance soon after it occurs.

Cybersecurity Certificate Transparency

Cybersecurity / 11 Sep 2026 / 9 min read

Plan Certificate Revocation Before a Key Is Compromised

A TLS certificate can still be inside its validity period when you need clients to stop trusting it. The private key may have been exposed, an identity may no longer be valid, or an issuing system may have made a serious mistake. Waiting for the certificate to expire leaves a gap between “we know this credential should no longer be trusted” and “clients stop accepting it.” Certificate revocation is the mechanism for communicating that change before normal expiry. The difficult part is operational: revocation information has to reach the relying parties that make trust decisions, and their behaviour when that information is stale or unavailable may differ.

Cybersecurity TLS

Cybersecurity / 11 Sep 2026 / 9 min read

Keep TLS Certificate Verification Enabled

An HTTPS client does more than encrypt bytes. During the TLS handshake, it also checks evidence about the server’s identity. If application code disables those checks, the connection can remain encrypted while being connected to an unintended endpoint. That distinction is central to secure TLS use. Encryption protects data against passive observation, but authenticated encryption to the wrong peer does not establish the identity the application intended to contact. The practical rule is: keep certificate-chain and hostname verification enabled, and repair trust configuration instead of bypassing verification.

Cybersecurity TLS

Cybersecurity / 09 Sep 2026 / 11 min read

Treat Certificate Pinning as a High-Cost Trust Decision

TLS normally lets a client authenticate a server through a certificate chain anchored in a trusted certificate authority. A developer may look at that broad trust model and decide to add certificate pinning: require the server to present not only a normally valid certificate, but also certificate or public-key material that the application already expects. That extra restriction can reduce risk in a narrow threat model. It can also turn an ordinary certificate or key rotation into an outage if the application has no usable replacement pin. For many applications, especially ordinary websites, the operational risk is not justified.

Cybersecurity TLS

Cybersecurity / 08 Sep 2026 / 9 min read

Monitor Certificate Transparency for Unexpected Certificates

A public TLS certificate can make a server appear to belong to your domain. If a certificate is issued when you did not expect one, the cause may be harmless automation, an undocumented service, or a mistake. It may also indicate that someone obtained certificate issuance through a path you did not intend to authorize. Looking only at certificates deployed on your own servers is not enough. An unexpected certificate may never appear on infrastructure you control.

Cybersecurity TLS

Cybersecurity / 03 Sep 2026 / 11 min read

Verify TLS Server Identity Without Bypasses

A client can establish an encrypted TLS connection and still connect to the wrong server if it does not verify the server’s identity correctly. Encryption protects traffic from observation and modification only within the connection that was established. The client must also decide whether the endpoint at the other end is the service it intended to reach. This matters for browsers, API clients, background workers, mobile applications, service-to-service calls, update clients, and any other software that relies on TLS. A tempting workaround such as “disable certificate verification because the internal certificate is inconvenient” can turn a configuration problem into an authentication failure.

Cybersecurity TLS