PKI

Publicly trusted certificates are recorded in public append-only Certificate Transparency logs before clients will accept them, so a monitor watching your portal's DNS names reports any certificate issued for them, including one your team never asked for.

A PKCS#10 certification request carries the subject name being asked for, the public key and any requested extensions, all self-signed with the matching private key. The private key is not sent to the authority.

Only the private key matters. An end-entity certificate is handed to every client that connects, so publishing it costs essentially nothing; the private key is the one secret that proves a server is entitled to use that certificate.

Nothing in the certificate changed: the same bytes, the same issuer signature, the same notBefore and notAfter. The issuer publishes the withdrawal separately, as a signed revocation list or a signed responder answer, and a verifier learns of it only by fetching one.

Two links join every hop: the issuer name in one certificate equals the subject name of the certificate above it, and that upper certificate's public key verifies the lower one's signature.

Trust lives in a local anchor list - a file or database of root certificates the client was configured to accept. If the issuer at the top of what a server presents has no entry there, the client rejects it.

The TBSCertificate holds version, serialNumber, signature, issuer, validity as notBefore and notAfter, subject and SubjectPublicKeyInfo, plus v3 extensions. Signed as one unit, it binds that public key to those names for that window.

Each ACME challenge proves control of a different layer for one name: http-01 of the HTTP service on port 80, dns-01 of the zone that answers for the name, tls-alpn-01 of the TLS service on port 443. Only dns-01 satisfies a wildcard.

A signed certificate timestamp is a log's signed promise to append that entry within its published Maximum Merge Delay. It proves submission and a log signature, not that the entry is in the tree — that needs an audit path against a signed tree head.

Domain validation checks only that the applicant can act on the name. Organisation validation adds checks that a named legal entity exists and the applicant is connected to it, and extended validation does that under a stricter procedure with more identifiers in the subject.

Renewal issues a new certificate over the same public key; re-keying generates a new key pair first, so the new certificate carries a different SubjectPublicKeyInfo. A suspected key compromise forces re-keying, because renewal would recertify the compromised key.

Building is a search: it hunts through the certificates a verifier can reach for an ordered run from an end-entity certificate to an anchor it holds. Validating is a check that accepts or rejects one such run.

Several independent anchor lists coexist on one machine - an operating-system anchor store, a language runtime's own keystore file, a separate security-library certificate database, a browser root program's list. Installing the internal CA into one leaves the others untouched.

A server identity belongs in the subjectAltName extension, as a dNSName or iPAddress GeneralName. The common name inside the subject is descriptive text: the CN-ID fallback older rules allowed for identity matching has been removed.

A renewal schedule must run against the served certificate's own notAfter with weeks of headroom, retry with jitter and backoff, and alert on renewal not having succeeded — while there is still runway — rather than on expiry itself.

Because clients soft-fail: when a status check cannot be completed they proceed. An attacker positioned to intercept the connection can also drop the status query, so live checking stops an accident but not an adversary. What closes it is a certificate that demands a stapled answer, pre-distributed revocation data, or short lifetimes.

The account key authenticates the protocol conversation, not the certificate. It identifies which account placed an order, completed an authorization and may revoke, and it lets the certified key stay out of the automation entirely except for the request submitted at finalize.

Embedding the returned timestamps changes the certificate's signed bytes, so the certificate cannot be logged before it exists. The authority logs a precertificate — the same content plus a critical poison extension, OID 1.3.6.1.4.1.11129.2.4.3, that makes it unusable — then issues the real one.

It proves the requester controlled the matching private key at the moment of signing, which stops anyone certifying a public key they cannot use. It proves nothing about entitlement to the requested name, nothing about identity, and nothing about later.

They are two different answers. OCSPResponseStatus reports whether the query itself worked - successful, malformedRequest, internalError, tryLater, sigRequired, unauthorized. Only a successful response carries a signed body with a per-certificate CertStatus of good, revoked or unknown.

The fetch moves off the client's path: the server queries the responder on a schedule and passes the responder-signed answer to the client. That removes a round trip, removes the privacy leak of the client naming the site to a third party, and survives a responder outage. It does not make an absent answer fatal.

Nothing joins the two. An intermediate CA signed the end-entity certificate, not the anchor, so with that intermediate absent no candidate has a subject matching the leaf's issuer and a key that verifies its signature.

Critical means a reader that does not recognise the extension must reject the certificate instead of ignoring it. basicConstraints is critical in a CA certificate because its cA boolean decides whether that certificate may act as an issuer at all.

Three: an SCT list embedded in the certificate as an X.509 extension at OID 1.3.6.1.4.1.11129.2.4.2, the signed_certificate_timestamp TLS extension (type 18) returned by the server, and an SCT list carried inside a stapled certificate status response.

The extensionRequest attribute is an application, not an instruction. The issuing authority applies its own certificate profile, keeping only names it validated, fixing usage extensions to its own values and choosing serial number and validity itself.

It stops the key being copied out, so no attacker can run a duplicate authority you cannot see. It does not stop the key being used: whoever controls the signing service in front of the module obtains genuine certificates for as long as that access lasts.

Three things per hop: basicConstraints present with cA set to TRUE, keyCertSign asserted if a keyUsage extension is present at all, and pathLenConstraint, which caps how many non-self-issued certificates may still follow.

Pin a digest over the DER-encoded SubjectPublicKeyInfo - the public key - not a fingerprint of the whole certificate. A certificate fingerprint changes at every renewal; an SPKI fingerprint survives a renewal that reuses the key pair.

Serial numbers are unique only per issuing authority, so certificates from different CAs collide; the unique key is issuer plus serialNumber. authorityKeyIdentifier is an unverified hint written into the certificate, not evidence of who signed it.