PKI

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 / 6 min read

OCSP Stapling Carries Certificate Status Inside TLS

Certificate validation answers more than one question. A client can verify the issuer chain, names, signatures, and validity dates, yet still need current information about whether a certificate has been revoked before its scheduled expiration. The Online Certificate Status Protocol (OCSP), specified by RFC 6960, provides signed status information for a certificate. A direct OCSP design has the client contact a responder operated by, or delegated for, the certificate issuer. OCSP stapling changes the delivery path: the TLS endpoint obtains an OCSP response and sends that response to the client inside the TLS handshake.

Cybersecurity TLS

Cybersecurity / 24 Sep 2026 / 5 min read

Certificate Transparency Separates Log Promises from Inclusion Proofs

A TLS certificate can be valid under normal chain validation and still deserve public scrutiny. Certificate Transparency (CT) adds that visibility by placing certificates or precertificates in public logs designed for auditing. The security model is more precise than a simple claim that a certificate has been logged: CT separates a log’s signed promise from later evidence that the promised entry actually reached the log’s Merkle tree. RFC 9162 describes CT version 2.0. A conforming log is an append-only Merkle tree. When it accepts a certificate or precertificate submission, it returns a Signed Certificate Timestamp (SCT). That SCT is a signed commitment associated with the accepted submission and a timestamp. It is not, by itself, a Merkle inclusion proof.

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 / 24 Sep 2026 / 6 min read

CAA Records Constrain Public Certificate Issuance

A public certificate authority does more than validate control of a DNS name. Before issuing a certificate, a CA that follows the CAA specification also checks DNS for a Certification Authority Authorization policy relevant to each requested name. That policy can narrow the set of issuers permitted to create certificates for the domain. CAA is an issuance control, not a replacement for domain-control validation. An authorized CA still has to apply its normal validation and issuance requirements. The record adds another decision: even after validation succeeds, is this issuer permitted by the domain’s published CAA policy?

Cybersecurity CAA

Cybersecurity / 24 Sep 2026 / 4 min read

CAA Narrows Certificate Issuance to Authorized CAs

Public certificate authorities validate control of a domain name before issuing a certificate, but domain control is not the only policy a domain operator can publish. Certificate Authority Authorization (CAA), specified in RFC 8659, adds a DNS-based signal that states which CAs are permitted to issue for a name. CAA does not replace domain-control validation. It adds another decision point before issuance: a conforming CA checks the applicable CAA policy and proceeds only when that policy permits the CA to issue the requested certificate.

Cybersecurity CAA

Cybersecurity / 23 Sep 2026 / 5 min read

TLS Must-Staple Makes OCSP Status Mandatory

TLS Must-Staple Makes OCSP Status Mandatory OCSP stapling lets a TLS server carry certificate-status evidence inside the handshake. The client can validate that response without making a separate request to the certificate authority’s OCSP responder. Ordinary stapling, however, does not by itself make a missing response conclusive: absence can mean that the server did not provide one. RFC 7633 defines the X.509v3 TLS Feature extension. A certificate can use that extension to state that a TLS feature is required. The feature commonly called Must-Staple identifies status_request, binding use of the certificate to delivery of certificate-status information for clients that implement the extension.

Cybersecurity TLS

Cybersecurity / 23 Sep 2026 / 6 min read

OpenSSH Host Certificates Replace Per-Host Key Pinning

OpenSSH Host Certificates Replace Per-Host Key Pinning SSH host authentication protects a client from silently accepting a different server key for a name it intended to reach. The familiar known_hosts model can pin a key directly to a host. That model is simple, but operating it across a large fleet creates a distribution problem: new hosts need trusted entries, planned key rotation changes pins, and stale entries can survive after infrastructure changes.

Cybersecurity OpenSSH

Cybersecurity / 23 Sep 2026 / 4 min read

CAA Records Restrict Certificate Authority Issuance

CAA Records Restrict Certificate Authority Issuance A public certificate authority can issue a certificate only after satisfying its validation and policy requirements. DNS Certification Authority Authorization adds another control: the domain holder can publish a CAA resource record set that states which issuers are authorized for a name. CAA is an issuance constraint, not a replacement for domain-control validation. An authorized CA still has to perform the validation required by its certificate policy. Conversely, successful domain validation does not permit a compliant CA to disregard an applicable CAA restriction.

Cybersecurity PKI

Cybersecurity / 22 Sep 2026 / 6 min read

OCSP Stapling Carries Certificate Status in the TLS Handshake

OCSP Stapling Carries Certificate Status in the TLS Handshake Certificate validation has two distinct questions. A client must establish that a certificate chains to a trusted authority and is valid for the intended identity, but it may also need current evidence that the certificate has not been revoked before its scheduled expiration. The Online Certificate Status Protocol, or OCSP, provides signed status responses for certificates. A client can query an OCSP responder directly, but that adds another network dependency to connection setup and can expose the certificate being checked to the responder. OCSP stapling moves a cached response into the TLS exchange: the server obtains status evidence and presents it to clients that request it.

Cybersecurity TLS

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 / 22 Sep 2026 / 6 min read

Certificate Transparency Exposes Certificate Issuance to Public Audit

Certificate Transparency Exposes Certificate Issuance to Public Audit A publicly trusted TLS certificate is an assertion made by a certificate authority. Traditional PKI gives clients a way to validate that assertion against trusted roots, but successful path validation alone does not make certificate issuance publicly visible. Certificate Transparency, commonly abbreviated CT, adds an audit layer. Participating logs accept certificate entries and commit them to append-only data structures. The resulting evidence lets clients, domain operators, and monitors detect certificates that have entered the public Web PKI, including certificates an operator did not expect to exist.

Cybersecurity TLS

Cybersecurity / 22 Sep 2026 / 6 min read

CAA Records Constrain Certificate Authority Issuance

CAA Records Constrain Certificate Authority Issuance A certificate authority can validate control of a domain and still face a separate policy question: is this CA authorized by the domain operator to issue for that name? Certification Authority Authorization, or CAA, gives the DNS namespace a record type for expressing that constraint. CAA operates before certificate issuance. A participating public CA checks the relevant DNS CAA policy and evaluates whether its issuer identity is authorized. The mechanism does not make a certificate trusted, revoke an existing certificate, or tell a browser to reject a certificate after issuance. It narrows the set of issuers that should create new certificates for the domain.

Cybersecurity DNS

Cybersecurity / 21 Sep 2026 / 6 min read

TLS Must-Staple Turns OCSP Stapling into Certificate Policy

TLS Must-Staple Turns OCSP Stapling into Certificate Policy OCSP stapling lets a TLS server deliver certificate-status evidence inside the handshake instead of making each client contact the certificate authority’s OCSP responder. That arrangement reduces an extra network dependency for the client, but ordinary stapling is optional: the absence of a stapled response does not, by itself, prove that the certificate is invalid. The X.509 TLS Feature extension changes that condition when it advertises status_request. Commonly called Must-Staple in this use, the certificate states that the server is expected to provide the corresponding TLS feature. A client that both requests the feature and enforces the certificate extension can reject a connection when the required status response is missing.

Cybersecurity TLS

Cybersecurity / 21 Sep 2026 / 5 min read

TLS Delegated Credentials Limit Front-End Key Exposure

TLS Delegated Credentials Limit Front-End Key Exposure A large TLS deployment often terminates connections on machines far from the system that manages its certificate private key. Copying that long-lived key to every front end simplifies handshakes, but it also enlarges the set of systems whose compromise can expose the certificate key. RFC 9345 defines delegated credentials for TLS and DTLS 1.3. A certificate holder can sign a separate, short-lived credential containing another public key. A compatible endpoint then uses the delegated credential and its private key for handshake authentication while the certificate private key can remain in a more restricted environment.

Cybersecurity TLS 1.3

Cybersecurity / 21 Sep 2026 / 5 min read

OCSP Stapling Delivers Revocation Status in TLS

OCSP Stapling Delivers Revocation Status in TLS Certificate validation answers more than one question. A client can verify signatures, names, validity periods, and trust anchors, yet a certificate that passes those checks may have been revoked after issuance. Revocation status therefore sits beside normal path validation rather than replacing it. The Online Certificate Status Protocol (OCSP) provides signed status responses for certificates. A client can query an OCSP responder directly, but that adds a third party to connection setup. OCSP stapling moves a suitable response into the TLS exchange: the server obtains the response and presents it to clients that request certificate status.

Cybersecurity TLS

Cybersecurity / 21 Sep 2026 / 6 min read

Mutual TLS Authenticates Both Sides of a Connection

Mutual TLS Authenticates Both Sides of a Connection A conventional HTTPS connection authenticates the server with a certificate while the client usually proves its identity later through an application mechanism such as a session cookie, bearer token, or password. Mutual TLS, commonly shortened to mTLS, adds certificate-based client authentication to the TLS exchange. The result is a transport channel in which each peer can verify a certificate chain and proof of private-key possession from the other side. That changes the authentication boundary, but it does not turn a certificate into an authorization policy. A valid client identity can still be denied access to a resource.

Cybersecurity TLS

Cybersecurity / 21 Sep 2026 / 7 min read

DNSSEC Validates DNS Data Through Signed Delegations

DNSSEC Validates DNS Data Through Signed Delegations DNS normally answers questions about names and resource records without cryptographic proof that the returned data came from the zone operator. DNS Security Extensions (DNSSEC) add signatures and a delegation chain that a validating resolver can check before treating signed DNS data as authentic. The protection is specific. DNSSEC provides data-origin authentication and integrity for DNS data. It does not encrypt queries or responses, hide queried names, or authenticate the application reached after resolution. A valid signed A record can establish that the record is authentic within the DNSSEC chain; it does not establish that the server at that address is safe.

Cybersecurity DNS

Cybersecurity / 21 Sep 2026 / 6 min read

DNSSEC DS Records Link Parent and Child Trust

DNSSEC DS Records Link Parent and Child Trust DNSSEC signs DNS data, but a signature is useful to a validator only when the signing key can be connected to a trusted starting point. That connection has to cross zone boundaries. A resolver validating data below a delegation cannot treat a child zone’s DNSKEY as authentic merely because the child publishes it. The DS resource record supplies the link. It is authoritative data in the parent zone and identifies DNSKEY material in the delegated child. Once the parent side is authenticated, a matching DS can authenticate the corresponding child key, allowing validation to continue into the child zone.

Cybersecurity DNSSEC

Cybersecurity / 21 Sep 2026 / 5 min read

DNS CAA Narrows Which CAs May Issue Certificates

DNS CAA Narrows Which CAs May Issue Certificates A publicly trusted certificate authority can issue a certificate only after completing the validation required by its policy and the applicable ecosystem rules. DNS Certification Authority Authorization (CAA) adds another control: a domain can publish which CAs are authorized to issue certificates for that DNS namespace. CAA does not replace domain-control validation, certificate transparency, or certificate verification by clients. It constrains issuance at the CA side. A CA processing a request checks the relevant CAA policy before issuance and must not issue when the policy forbids it.

Cybersecurity PKI

Cybersecurity / 21 Sep 2026 / 6 min read

Certificate Transparency Makes TLS Certificate Issuance Auditable

Certificate Transparency Makes TLS Certificate Issuance Auditable A publicly trusted TLS certificate can be cryptographically valid and still be a certificate that the domain operator never requested. Certificate validation establishes a chain to a trusted certification authority and checks the certificate against client policy. It does not, by itself, give a domain operator a global record of certificates issued for its names. Certificate Transparency (CT) adds that visibility layer. Public logs accept certificates or precertificates, commit to recording them, and expose an append-only history that monitors can inspect. The mechanism does not stop a certification authority from issuing a bad certificate. It makes issuance observable and gives clients a basis for requiring evidence that a certificate has been submitted to an accepted log.

Cybersecurity TLS

Cybersecurity / 21 Sep 2026 / 6 min read

Certificate Transparency Logs Make Certificate Issuance Auditable

Certificate Transparency Logs Make Certificate Issuance Auditable A publicly trusted TLS certificate can be valid in the PKI sense and still be unexpected by the domain operator. A certificate authority may issue after account compromise, validation error, or another failure in the issuance path. Normal certificate validation checks the chain, hostname, validity period, signatures, and relevant policy. Those checks do not tell an operator that another valid certificate for the same name exists elsewhere.

Cybersecurity TLS

Cybersecurity / 20 Sep 2026 / 6 min read

TLS SPKI Pinning Needs a Rotation Path

TLS SPKI Pinning Needs a Rotation Path Certificate pinning adds a local trust constraint to the certificate checks already performed by a TLS client. Instead of accepting any certificate that satisfies the configured PKI and service-identity rules, a pinned client also requires the connection to present cryptographic material that matches a value already embedded in, provisioned to, or otherwise trusted by the client. That narrower policy can reduce exposure to certificate issuance outside the intended key set. It also creates a new operational dependency: the client must carry a valid path from the key accepted today to a key that can be used after rotation.

Cybersecurity TLS