Certificates and PKI

A certificate binds a public key to an identity, purpose, and validity period, and is signed by the issuer. For a client to accept a certificate, it must also have a trusted path and perform application-level identity validation; the TLS handshake further proves that the peer possesses the corresponding private key. Being able to read a certificate, or even verify its self-signature, does not mean you already know who the other party is.

Using https://api.example.com:8443/orders as a running example: the connection destination address comes from resolution, the reference identity comes from the application's access target, and the certificate provides a verifiable identity claim. Which IP the DNS returned and which name the server sent do not determine for the client whom it should trust.

Distinguish Four Objects First

Certificates are often encoded in DER binary, while PEM is a text wrapper with boundary markers. A file named .pem is insufficient to determine whether it contains a certificate, a private key, or multiple certificates; read the actual object. The certificate's own signature algorithm is used by the issuer, while SubjectPublicKeyInfo describes the holder's public key algorithm; these two need not be the same.

Service Identity: Determine Who to Access First, Then Compare SAN

For the HTTPS scenario in this article, match the dNSName or iPAddress in the SAN. Do not fall back to using the Subject CN to impersonate DNS identity. Domain names handle case sensitivity and internationalized names according to applicable rules; wildcards can only occupy the leftmost complete label and cover only one level.

SNI helps the server select the virtual host certificate but does not perform name validation for the client. A DNS CNAME pointing to a hoster does not mean you can use the hoster's arbitrary name to replace the original service identity. Here is the name matching result; final authentication also depends on the chain and other checks. RFC 9525: Service Identity

Trust Path: Valid Signature is Only One Condition

A typical server sends the leaf certificate and necessary intermediate certificates, usually without sending the root. The client builds candidate paths using local trust material, then verifies signatures, validity periods, critical extensions, and constraints. Do not skip signature verification just because the Issuer text equals another certificate's Subject; AKI/SKI can help select candidates but are not independent sources of trust.

An intermediate CA with pathLenConstraint=0 can still issue leaf certificates; it does not mean "cannot sign any certificate." Root certificates are often self-signed, but trust comes from external configuration, not from circularly validating their own signatures. Cross-signing creates multiple candidates for path construction, so a client working on one machine might fail on another due to differences in anchors, path building capabilities, or policies. RFC 5280: Certificates and Paths

For example, if the server only sends the leaf certificate: the browser might have the intermediate certificate cached and the connection succeeds, but a new container fails. You should complete the service chain; do not use "this browser can open it" as proof of a complete chain. The trust scope of the public Web PKI and a self-built enterprise PKI also differs; installing an enterprise root expands the sources of issuance that client can accept.

The chain connects, so why still reject?

First, input the bare domain example.com or multi-level v2.api.example.com to observe that wildcards cannot cover them. After restoring the name, pathLen=0 still allows direct signing of leaf certificates; only inserting another CA triggers this constraint. Other checks remain independent.

ACME: Prove Domain Control, Then Issue for Applied Public Key

The ACME account key is used to authenticate account requests, while the certificate key is used for service handshakes; they bear different responsibilities. The order describes identifiers, authorization/challenge records prove control verification, and the CSR submits the public key for signing. After the order is ready, finalize it; only after processing completes to valid can you download the certificate; a single successful POST does not mean all steps are finished.

Let keyAuthorization = token + "." + accountKeyThumbprint, where the thumbprint is the canonical fingerprint of the account public key JWK. The two basic challenges are carried as follows:

When applying for *.example.com, DNS verification uses _acme-challenge.example.com. Multiple challenge TXTs may exist with the same name; automation should maintain them according to their respective values to avoid concurrent orders overwriting each other. After publication, confirm the authoritative response and verification visibility; do not treat a local recursive cache hit as global readiness. RFC 8555: Orders and Challenges

TLS-ALPN-01 uses port 443 and negotiates acme-tls/1; the proof material is placed in the dedicated self-signed certificate's critical acmeIdentifier extension, which is the SHA256 digest of keyAuthorization. The ALPN string itself does not carry the challenge value. This dedicated certificate also requires a corresponding single DNS SAN and cannot be directly replaced by a regular service certificate. RFC 8737

Runnable Example: Verify Challenge Bytes Instead of Guessing TXT

Below, using a teaching token and given fingerprint, demonstrate the differences in the three carriers; this does not implement JWK canonicalization, signed requests, or real CA verification.

import base64
import hashlib

def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b'=').decode('ascii')

token = 'teaching-token'
thumbprint = b64url(hashlib.sha256(b'teaching-account-key').digest())
key_auth = (token + '.' + thumbprint).encode('ascii')
digest = hashlib.sha256(key_auth).digest()
dns_txt = b64url(digest)
# The inner layer of acmeIdentifier's extnValue is DER OCTET STRING: tag + length + 32 B.
acme_identifier_der = bytes([0x04, 0x20]) + digest
assert len(digest) == 32 and len(dns_txt) == 43
assert base64.urlsafe_b64decode(dns_txt + '=') == digest
assert acme_identifier_der[:2] == bytes([4, 32])
assert dns_txt != key_auth.decode('ascii')
assert hashlib.sha256(key_auth + b' ').digest() != digest
print('HTTP raw, DNS digest encoding, TLS extension inner length:', len(key_auth), len(dns_txt), len(acme_identifier_der))

Validity Period, Revocation, and Status Freshness

A certificate not being expired does not mean the private key has never been leaked. Revocation expresses the withdrawal of recognition after issuance; how clients obtain and enforce status is determined by protocol capabilities and product policies jointly.

OCSP's good/revoked/unknown cannot be simplified to "safe"/"unsafe"/"network anomaly". good at least expresses that it has not been identified as revoked, but does not guarantee that the name, purpose, and chain are valid. Cached responses also have time boundaries: assuming thisUpdate is 10:00 and nextUpdate is 12:00, obtaining it at 11:00 does not mean the status was regenerated at 11:00; 12:30 cannot be taken as definitive evidence of freshness. RFC 6960

Stapling in TLS 1.2 is common in the CertificateStatus message; TLS 1.3 uses extensions in CertificateEntry, so you cannot copy the same message location. Must-Staple is a usage of the TLS Feature extension, not CT for code signing; its actual constraint effect also depends on client support. RFC 7633, TLS 1.3 Certificate Messages

As of September 2026, you can no longer use Let's Encrypt's old OCSP address as a general deployment example: its OCSP service ended in August 2025, shifting to CRL publication. Which status mechanisms a specific CA supports should be read from the current certificate extensions and their policies. Let's Encrypt Announcement

CT: Make Issuance Auditable, Not Replace Domain Verification

Logs return SCTs, promising to incorporate submitted items into the log within a specified period; obtaining an SCT does not mean you have already obtained an inclusion proof. Merkle inclusion proof proves that an item belongs to a specific tree head, while consistency proof is used to prove the log's append-only consistency. Monitors use this to discover anomalous issuances, then proceed with investigation, revocation, or trust policy handling; the log itself does not authorize issuance on behalf of the domain holder. RFC 9162: CT v2

Protocol versions and browser deployment policies must be checked separately. Do not write "all certificates fix two SCTs"; for example, the current Chrome embedded SCT path requires at least two different logs for a lifecycle not exceeding 180 days, and three for over 180 days, with operator diversity and log status conditions; the TLS carrier path has other conditions. Enterprise private trust and public Web PKI cannot directly apply the same conclusion. Chrome CT Policy

CT logs are public information sources; if internal naming from an application enters public certificates, it forms a visible record. It improves discoverability, does not hide domains, and cannot alone prevent malicious certificates from being briefly used.

Renewal is a Publication Loop

Validity period is not a permanently fixed constant in X.509, nor can you write the duration of a specific CA's specific product as a protocol upper limit. As of September 2026, the Baseline Requirements for public TLS Subscriber Certificates stipulate a maximum of 200 days for certificates issued between 2026-03-15 and 2027-03-15; subsequent phases have tightening plans, and specific products can be shorter. Self-built PKIs should not apply this value indiscriminately. CA/B Forum: 6.3.2

Assume a teaching certificate has 20 days remaining, the automated task runs every 24 hours, and normal distribution takes 2 hours. The available recovery window is not "20 definitely successful renewals": the challenge system, issuance rate limiting, DNS permissions, and distribution services may share failures. You should monitor the actual remaining time of service certificates, the most recent successful publication, and consistency across entries, while retaining margin for handling failures.

After material verification passes, atomically replace files, reload users, and then confirm the actual certificate delivered from each entry. Updating the certificate file does not mean the process has loaded it; updating a single node does not mean the entire cluster is complete, and existing connections will not automatically re-handshake. Certificate renewal and private key rotation should be recorded separately to avoid assuming that a new certificate necessarily means a new key.

Continue Reading

• TLS 1.2 Handshake: Division of labor for certificate signatures, key exchange, and Finished.
• TLS 1.3 Handshake: CertificateVerify and phased authentication.
• mTLS and Mutual Authentication: Mapping certificate identity to client permissions.
• DNSSEC: DNS trust chain and DANE boundaries.