Certificates

Cybersecurity / 24 Sep 2026 / 6 min read

TLS Delegated Credentials Limit Certificate Key Exposure

Large TLS deployments often need signing capability on many serving machines. Copying the certificate private key to every endpoint expands the set of systems whose compromise can expose a long-lived credential. Keeping that key in one tightly controlled location reduces exposure, but remote signing for every handshake can add an operational dependency to the serving path. Delegated Credentials for TLS, standardized in RFC 9345, provide a narrower option for TLS 1.3. A certificate holder can use its certificate private key to authorize another public key for a limited period. The endpoint receives the corresponding delegated private key and can authenticate TLS handshakes without holding the certificate private key itself.

Cybersecurity TLS

Cybersecurity / 24 Sep 2026 / 6 min read

OCSP Stapling Delivers Certificate Status in the TLS Handshake

Certificate validation answers more than one question. A client checks that a certificate chains to a trusted root, matches the intended identity, falls inside its validity interval, and satisfies applicable policy. Revocation status is a separate signal: a certificate can still be inside its notBefore and notAfter interval after the issuer has revoked it. The Online Certificate Status Protocol (OCSP), specified in RFC 6960, gives clients a mechanism to query certificate status. A direct query, however, adds a network dependency to connection setup and exposes the queried certificate identity to the responder. OCSP stapling moves retrieval to the TLS server. The server periodically obtains a signed OCSP response and sends that response to clients as part of the TLS handshake.

Cybersecurity TLS

Cybersecurity / 24 Sep 2026 / 4 min read

Certificate Transparency Logs Expose Public Certificate Issuance

A publicly trusted certificate can be syntactically valid, correctly signed, and still be unexpected. A certificate authority might issue one for the wrong subject, an account might be compromised, or an authorization process might fail. Certificate Transparency (CT) adds public observability to certificate issuance so that such certificates do not have to remain invisible to the affected domain operator. RFC 9162 specifies Certificate Transparency Version 2.0. Its central mechanism is an append-only public log backed by a Merkle tree. Certificate authorities and other submitters can send certificates or precertificates to a log, and monitors can inspect logged entries for certificates relevant to domains they watch.

Cybersecurity PKI

Cybersecurity / 22 Sep 2026 / 6 min read

DNS CAA Narrows Certificate Authority Issuance

DNS CAA Narrows Certificate Authority Issuance Public certificate issuance depends on a certificate authority validating control of the requested domain name. DNS Certification Authority Authorization (CAA) adds a separate policy signal: a domain can publish which certificate authorities are permitted to issue for that name. CAA does not replace domain-control validation, prove that a requester is legitimate, or protect a private key. Its role is narrower. A conforming public certificate authority checks the applicable CAA policy before issuance and must not issue when that policy forbids it.

Cybersecurity PKI

Cybersecurity / 20 Sep 2026 / 6 min read

TLS Hostname Verification Binds a Valid Certificate to the Requested Name

TLS Hostname Verification Binds a Valid Certificate to the Requested Name A TLS certificate can be cryptographically valid and still be wrong for the server a client intended to reach. Chain validation answers whether the certificate can be linked to a configured trust anchor under the applicable PKI rules. Service identity verification answers a separate question: whether that certificate represents the hostname the client requested. Both checks are required for ordinary HTTPS authentication. Accepting a trusted certificate without checking the requested name turns a narrow credential into a credential for unrelated destinations.

Cybersecurity TLS

Cybersecurity / 20 Sep 2026 / 5 min read

SSH User Certificates Bind CA Trust to Principals

SSH User Certificates Bind CA Trust to Principals Managing SSH access with individual public keys is straightforward at small scale. Each server can keep a list of accepted keys in authorized_keys. As the number of people and hosts grows, however, access control also becomes a key-distribution problem: adding, rotating, and removing identities requires changes across the machines that trust them. OpenSSH user certificates provide a different trust model. A server can trust a user certification authority (CA), then accept user certificates signed by that CA when the certificate also satisfies the server’s authentication policy. The CA signature answers only part of the decision. Principals, validity intervals, certificate options, and server configuration determine where and how the signed key may be used.

Cybersecurity OpenSSH

Cybersecurity / 16 Sep 2026 / 7 min read

Certificate Transparency Makes Certificate Issuance Auditable, Not Preventive

A certification authority can issue a syntactically valid TLS certificate for a domain even when the domain operator did not request it. Traditional certificate validation can still succeed if the issuing chain reaches a trusted root and the certificate satisfies the client’s other checks. The missing signal is accountability: the domain operator needs a reliable way to see that the certificate exists. Certificate Transparency, or CT, moves that problem into public, cryptographically auditable logs. A log does not decide whether a certification authority was entitled to issue a certificate. It records certificates and precertificates, signs commitments about accepted submissions, and exposes an append-only history that monitors can inspect.

Cybersecurity Certificate Transparency

Cybersecurity / 14 Sep 2026 / 6 min read

OCSP Stapling Moves Revocation Evidence Closer to the TLS Handshake

OCSP Stapling Moves Revocation Evidence Closer to the TLS Handshake A browser can receive a valid certificate chain, verify every signature, confirm the hostname, and still face one more question: has the issuing certificate authority revoked the leaf certificate since it was issued? That question is awkward because the certificate itself cannot carry a fresh answer. Its signed validity interval is fixed at issuance, while revocation is an event that can happen later.

Cybersecurity TLS