Public Web PKI and internal PKI: two different problems

Public and private certificates share a format, a validation algorithm and a vocabulary, which persuades people they share a rulebook. They do not. The distinguishing question is whether you control the relying parties. If you cannot edit the trust stores that will judge your certificate, somebody else writes the rules; if you can, you write them and you also carry the whole burden of enforcing them.

The Web PKI is defined by who you cannot reach

A certificate for a public site will be evaluated by browsers, mobile operating systems, language runtimes and embedded devices you have never seen. The anchor set is curated by a small number of platform vendors, and no subscriber can add to it. Because the relying parties cannot be coordinated, the constraints are imposed on issuance instead, through the CA/Browser Forum Baseline Requirements, which every publicly trusted CA is audited against.

That document changes on dated schedules, so a number without a date is worthless. As of 26 August 2026 the current version is 2.2.9, dated 6 August 2026, and these limits are in force:

• Maximum subscriber certificate validity is 200 days. That applies to certificates issued on or after 15 March 2026 and before 15 March 2027. The prose sets the recommendation one day lower still, saying such certificates should not exceed 199 days. The ceiling falls to 100 days from 15 March 2027 and to 47 days from 15 March 2029. The older 398-day figure expired in March 2026 and should not be quoted.
• A day is 86,400 seconds, and any excess counts as a whole extra day. For that reason the requirements themselves advise against issuing at the maximum permissible time by default.
• Domain and IP validation data may be reused for 200 days. That drops to 100 days in 2027 and to 10 days in 2029. Subject identity information reuse is a separate clock, currently 398 days.
• A short-lived subscriber certificate now means 7 days or fewer. The definition changed from 10 days on 15 March 2026, and it matters because short-lived certificates are exempt from some profile obligations.
• Only RSA of at least 2048 bits, with a modulus size divisible by 8, or ECDSA on NIST P-256, P-384 or P-521 are permitted. The requirements state that no other algorithms or key sizes are allowed, which rules out Ed25519 for public TLS today.

Identity rules deserve their own note because issuance and verification now say different things. The subject alternative name extension must be present and must contain at least one dNSName or iPAddress entry, and no other name type is permitted there. The Common Name is marked not recommended rather than forbidden, and where a CA does emit one it must be a character-for-character copy of a name that already appears in the SAN. On the verification side RFC 9525 leaves no room at all: the Common Name RDN must not be used to identify a service, and neither may any other RDN in the subject. Clients must ignore it.

An internal PKI trades rules for responsibility

Inside your own estate the position inverts. You own the trust stores, so you can distribute an anchor, and once you have, you can issue anything the verifiers will accept. That freedom is real and it is useful.

• You can constrain the CA itself. Name constraints, restrictive extended key usages and short path lengths let you bound what a CA is allowed to do, which no public CA offers a subscriber.
• You can issue for names that no public CA will touch. Internal hostnames, service mesh identities and device serial numbers are not publicly resolvable, so domain validation cannot be performed on them at all.
• You can pick a lifetime that matches your automation. Nothing external caps it.
• You can use client authentication as a first-class identity. A private CA whose leaves carry clientAuth is a mutual TLS deployment; obtaining the equivalent publicly is awkward and needlessly exposed.

What you give up is enforcement. No auditor checks your profile. No browser rejects a malformed certificate and forces you to notice. There is no transparency log recording what your CA issued, so a mis-issuance leaves no external trace. Every guarantee that the public system buys with regulation, you have to buy with your own controls.

flowchart TD
    A["Who evaluates the certificate?"] --> B{"Can you edit their trust store?"}
    B -- "no" --> C["Web PKI: vendor anchors\nCA/B Forum rules apply"]
    B -- "yes" --> D["Internal PKI: your anchor\nyour policy, your enforcement"]
    C --> E["Public names only\npublished issuance record"]
    D --> F["Any name\nno external record"]

The diagram reduces the whole decision to one question, and that is deliberate. Teams often pick a CA on cost or familiarity when the only question that determines the answer is which population of verifiers has to accept the result.

Borrowing the public numbers is not the same as borrowing the reasoning

The reasoning behind the shrinking public ceiling is sound and it generalises: a certificate lifetime is the upper bound on how long a compromised key stays useful, and that bound is enforceable on every relying party without shipping any code. Short lifetimes are good practice inside an estate for exactly the same reason.

The number, however, does not generalise. A 200-day cap applied to a device fleet that has no automated renewal path does not improve security; it schedules an outage and moves it just far enough away that nobody is watching when it arrives. The order of operations has to be the other way round. Establish renewal and reload as an automated, monitored, regularly exercised process first. Then shorten the lifetime until the process is exercised often enough that a failure is noticed in hours rather than discovered by customers.

There is a useful test for it. If your certificates are short enough that a renewal failure is an incident today rather than a quiet countdown, the lifetime is doing its job. If a renewal failure would go unnoticed for weeks, the lifetime is too long regardless of what the number is.

CERT=app.crt
openssl x509 -in "$CERT" -noout -dates
# Non-zero exit means it expires inside the next 90 days.
openssl x509 -in "$CERT" -noout -checkend 7776000

notBefore=Aug 26 21:19:00 2026 GMT
notAfter=Nov 24 21:19:00 2026 GMT
Certificate will expire

That second command is the whole monitoring primitive: it exits non-zero when the certificate will not survive the supplied number of seconds, so it turns a lifetime policy into something a check can assert rather than something a spreadsheet claims.

Requests a public CA cannot satisfy

Three requests come up repeatedly and each one is a category error rather than a procurement problem.

• A public certificate for an internal-only name. Issuance requires demonstrated control of a publicly resolvable name. If nobody outside can resolve it, no validation method applies.
• A public certificate with a private extension or constraint. The profile is closed. anyExtendedKeyUsage must not appear at all, and the permitted extensions and their criticality are fixed.
• A public certificate for internal topology you would rather not publish. Publicly trusted issuance is logged and monitored, so internal hostnames placed in a public certificate become searchable. That is a feature of the system, not a leak to be worked around.

Production discipline

1. Write down which population of verifiers each certificate serves. That single field decides which rulebook applies and whether the name may be internal.
2. Store the effective date beside every limit you automate. A renewal window computed from a stale ceiling silently issues certificates the CA will reject.
3. Never place an internal hostname in a publicly trusted certificate to make a tool happy. Use the private CA that was built for it.
4. Derive internal lifetimes from your renewal reliability. Shorten only after renewal and reload are automated and monitored, then keep shortening until failures surface fast.

Cross-course references

• Linux for Production Sysadmins - Part LXXI (TLS) covers the server-side configuration that has to be reloaded whenever a shorter lifetime makes renewals frequent.
• Observability for Production Sysadmins - Part LXIV (TLSMonitoring) covers turning the remaining-lifetime measurement into an alert with a threshold, which is what makes a short lifetime safe rather than risky.
• Git, CI/CD & GitOps for Infrastructure Engineers - Part XCIII (CredRotation) covers rotating credentials on a schedule, the same discipline applied to material that is not a certificate.

Quiz