The Certificate Authority

28.0 What this chapter gives you#

1. You will be able to say in one sentence what a certificate authority actually sells, and why the answer is not “encryption”.
2. You will be able to distinguish domain, organization and extended validation, and name the policy number each one writes into a certificate.
3. You will be able to name the ten permitted methods of domain control validation the industry settled on in 2017, say which survive in August 2026, and say what killed each of the rest.
4. You will be able to explain the three ACME challenges, http-01, dns-01 and tls-alpn-01, well enough to choose one for a machine with no web server.
5. You will be able to compute an ACME key authorization by hand and predict the exact string that must appear in a DNS record.
6. You will be able to describe what it takes to get a root certificate into the Mozilla, Apple, Chrome and Microsoft programmes, and to be thrown out.
7. You will be able to say what a WebTrust or ETSI audit does and does not test, and read an audit report for the four facts that matter.
8. You will be able to explain how a CA/Browser Forum ballot passes, who votes on it, and why a document nobody signed can close a business.
9. You will be able to recite the certificate lifetime schedule with dates, from sixty months to forty-seven days, and say which step is in force.
10. You will be able to write a CAA record for your own domain and say exactly what it does and does not prevent.

A certificate authority does not sell cryptography. This is the most useful sentence in this chapter, and almost every explanation of the web’s security gets it wrong. The mathematics inside a certificate is free. Anyone can generate a key pair in a fraction of a second and sign a statement with it, using published, unpatented algorithms implemented in every operating system on earth. If cryptography were the product, a certificate would cost nothing, because it costs nothing.

What a certificate authority sells is a claim: we checked something, and we are staking our continued existence on having checked it properly. The certificate is the receipt for that check. When your browser accepts a certificate it is not admiring the mathematics. It is accepting, at second hand and without asking, a stranger’s assurance that a procedure was carried out correctly some days ago by a person or a program you will never meet, working for a company you have never heard of. The whole of web security stands on that, and it is worth understanding exactly how thin the claim is.

This chapter is about the checking. Chapter 26 covered what is inside a single certificate and chapter 27 covered how a verifier assembles a chain back to a root. Here we look at the organisation that signs one: what it verifies, who tells it what to verify, who checks that it did, and what happens when it does not. Along the way we name the permitted validation methods, work an ACME challenge through with real computed values, look up real CAA records, and read the lifetime schedule out of the document that sets it.

One boundary, stated once. This chapter is not about what happens when a certificate authority is caught misbehaving; that is chapter 35, “When a Certificate Authority Fails”. Nor is it about the public logs that record every certificate issued, which is chapter 31, or how a certificate is withdrawn once issued, which is chapter 30. We stay on the issuing side of the counter.

The plain version#

The address office#

Imagine a small office on the main road in Kochi. It is called the Address Office, and it does exactly one job. It writes out cards that say: the person who answers at 14 Market Road is the person who asked us for this card. It seals each card so the words cannot be changed afterwards, and it hands the card to whoever asked.

Meera runs a bakery at 14 Market Road. She wants a card, because the big shopping centres in town will only let a shop take orders through their customer desks if the shop can produce a sealed card for its address.

Now here is the thing to hold on to. The Address Office has never met Meera. It has no photograph of her. It cannot telephone the real owner of 14 Market Road to ask, because who the real owner is happens to be the very question. It cannot visit for every card, because it writes ten million cards a day. So it does the only thing it can, which is to test the address itself.

A clerk writes a long meaningless number on a slip of paper and posts it through the letterbox at 14 Market Road. If the person who asked for the card telephones back and reads out that exact number, the clerk writes the card and seals it.

What has been established: whoever asked for this card can get at the post delivered to 14 Market Road. That is a real fact about the world, and it is worth having.

What has not been established: that her name is Meera, that she owns the building, that she pays rent, that she bakes anything, that she is not laundering money, that the bread is good. The office knows none of this and has claimed none of it. The card says one thing about an address, and it is not a character reference.

This is the whole business of a certificate authority in the plain case. It sends a number to an address, and if the number comes back it writes a card. The address is a domain name rather than a street and the slip is a random string rather than five digits, but the shape of the test is identical, and so is the shape of what it proves.

Three ways to send the slip#

There is more than one way to deliver a number to an address and see it come back, and the differences matter, because different people control different parts of a building.

The first way is the window. The clerk says: write this number on a card and pin it inside your front window, where anybody walking past can read it. The clerk walks past and reads it. This works if you have keys to the shop. It does not work if you have keys to the office upstairs but not the shopfront.

The second way is the town directory. The clerk says: get this number added to your entry in the town’s address directory, the big book everyone consults to find out where things are. The clerk looks it up. This works if you can reach the directory entry, which is a different thing from having keys to the shop: a landlord who keeps the entries can do it for a tenant who cannot get into the window.

The third way is the special knock. The clerk says: somebody will knock in the next hour using a rhythm nobody uses for anything else; when they do, answer holding this number. This works if you control who answers the door, which is different again from controlling the window or the directory.

Three tests, three different things being proved, three different people who can pass them. Almost everything difficult about certificate authorities comes from the fact that “control of an address” is not one thing.

The people who decide which offices count#

The Address Office is not a government body. Anybody may open one. What stops a crooked office writing cards for other people’s addresses is not law, and it is not policing in any ordinary sense.

It is the shopping centres.

There are four very large shopping centres in the region, and between them they carry nearly all the trade. Each keeps a list at every entrance of which Address Offices’ cards its door staff will honour. On the list, your cards work everywhere and your business exists. Off it, your cards are decorative.

Getting on to a list is slow and expensive, and the shopping centres charge nothing for it. They want something else. They want your working rules written down and published, so anyone can read what you claim to do. They want an approved inspector to visit every year and write a public report on whether you actually do it. They want to know where your safe is and who has keys. They want every mistake you make published within days. And they want to be able to strike you off at any time, without explaining themselves.

That last clause is not a slip of the pen. It is the whole enforcement mechanism. A certificate authority is a business whose licence to exist can be revoked by four software companies acting independently, with no appeal and no notice period. Everything an authority does is shaped by that.

The committee where the rules are written#

If four shopping centres each wrote their own rules, an Address Office would have to satisfy four incompatible rulebooks. So the offices and the shopping centres sit in a committee together and write one rulebook.

The committee is unusual. The offices outnumber the shopping centres many times over, and yet cannot pass a rule the shopping centres refuse. Any change needs a large majority of the offices and a majority of the shopping centres, and at least one of each. Either side can block anything.

What the committee produces is, on paper, only guidelines. Nobody signs a contract agreeing to follow them. What makes them binding is that each shopping centre has separately announced that anyone who breaks them comes off its list. The rulebook has force because four organisations act on it.

And when the committee cannot agree, a shopping centre simply acts alone. That has happened, and we will come to it, because it produced the biggest change in this business in twenty years.

The notice on your own door#

Meera has a worry. She uses the Ernakulam Address Office and is happy with it, but there are dozens of offices and any of them could write a card for 14 Market Road if somebody fooled them. She would like to say, once and publicly, that only the Ernakulam office may write cards for her address.

She can. She adds a line to her entry in the town directory that reads, in effect, “for this address, only Ernakulam”. Every office in the region is required by the rulebook to read that line before writing a card, and to refuse if its own name is not on it.

This is a genuinely good protection and it is nearly free. It is also weaker than it looks, in a way we will be precise about shortly: it is a notice, not a lock. It stops honest offices making mistakes. It does not stop a dishonest one, and it does not un-write a card already written.

How long the card is good for#

In the early years, the Address Office wrote cards that were good for five years. It was convenient. Nobody had to think about their card very often.

Then it became obvious that a five-year card is a five-year problem. If the shop changes hands the old card still works. If the key is copied the copy still works. If the office made a mistake it persists for five years. And when the rulebook improves, old cards do not improve with it.

So the cards got shorter. Five years became a bit over three, then just over two, then a bit over one. In March 2026 it became about six and a half months, and it is scheduled to become about three months in 2027 and about six and a half weeks in 2029. The real dates are in the technical half; the point here is the direction and the reason. A short card is a card a machine replaces, and a card a machine replaces can be replaced with a better one whenever the rules improve.

Nobody could shorten the cards while a human being had to fetch each one. The shortening and the automation are the same event.

The factory that runs its own office#

One last piece. A large factory on the edge of town has two hundred internal doors, all of which need cards. It does not want to pay the Address Office and it does not need to: none of these doors face the public street.

So it runs its own address office inside the factory, and instructs its own door staff to honour cards from it. The machinery is identical: the same kind of card, the same seal, the same number posted through a letterbox. What differs is the list at the door. The factory’s cards work at the factory’s doors and nowhere else, and the four shopping centres have never heard of it.

This is a private certificate authority, and there are far more of them in the world than public ones. Everything in this chapter about issuance applies to them. Almost nothing about audits, root programmes and ballots does, because those exist to make strangers trust you, and a factory does not need that.

Where the plain version stops being true#

The card says nothing about who you are, and everyone reads it as if it did#

The Address Office tested an address. It did not test a person. In the plain version this was stated clearly, and in the real world it is stated clearly in the specification, and it is still the most common misunderstanding in computing.

A domain-validated certificate contains a domain name and a public key. It carries no company, person, country or trading address, and since a 2021 rule change no organizational unit either. A padlock means somebody proved control of that domain name to somebody on the list. It does not mean the site is run by the company whose logo is on the page. A phishing site with a domain of its own gets the same padlock as a bank, and this is not a bug.

The honest version: the padlock is a statement about the connection, not about the counterparty. It means “you are talking to whoever controls this name, and nobody in between is reading it”. Whether that person deserves your money is a question no certificate has ever answered.

Control today is not ownership ever#

The address test asks a present-tense question: can you, right now, make a change at this address. Many people can, and not all of them are the owner.

A web hosting company can, for every domain it hosts. A content delivery network can. A DNS provider can, for every zone it serves. An employee with access to the DNS console can, until they leave and often afterwards. Somebody who has taken over an abandoned subdomain still pointing at a cloud account can. A registrar can, because it controls the directory entry itself.

None of these is an attack. They are the ordinary structure of the internet, and they are why the methods have been repeatedly tightened and why the permitted reuse period for a completed validation has fallen from over two years to two hundred days, heading for ten. A validation is a photograph of a moment, and the industry’s answer has been to insist the photograph be recent.

The slip can be intercepted in transit#

In the plain version the post is reliable. On the internet it is not. The path packets take is decided by routing announcements that any sufficiently placed network can make, and an attacker who can attract traffic for a domain for a few minutes can answer the challenge and obtain a real certificate from a real authority following its rules correctly.

This is not theoretical, and the answer is structural: since 2025 the rules require the authority to run the same check from several widely separated vantage points at once and compare the answers, so that an attacker must hijack the traffic as seen from all of them. The mechanism is called multi-perspective issuance corroboration.

The honest version: domain validation has never been a proof of ownership. It is a proof that, from where the authority was standing, the address answered correctly. Multiple perspectives make “where the authority was standing” a harder thing to control, not an irrelevant one.

An audit is an opinion, not an inspection of every card#

The plain version said an inspector visits every year and writes a report. True. But an audit is not a re-examination of the authority’s work. It is a professional opinion, given by a firm the authority selects and pays, about whether a described set of controls was suitably designed and operating effectively over a stated period, tested against stated criteria, on a sample.

An audit can be clean while individual certificates are wrong. Authorities are separately required to sample their own issuance every quarter, and the self-audit sample is the greater of one certificate or three per cent of what they issued. Three per cent is a real sample and it is not everything.

The honest version: an audit tells you that an organisation has a functioning control environment and takes its obligations seriously. It does not tell you that every certificate it issued last Tuesday was correct. The mechanism that tells you about individual certificates is the public log, and that is chapter 31.

The four shopping centres are not one shopping centre#

“Trusted” sounds like a property of a certificate. It is not. It is a property of a relationship between a certificate and one piece of software on one machine on one day.

Mozilla, Apple, Google and Microsoft each maintain their own root programme, each with its own policy document, version number, effective dates and list. The lists overlap heavily and are not identical, and the policies disagree in detail. A certificate can be perfectly trusted in Chrome and rejected on an old Android handset, and both machines are behaving correctly.

Add the trust stores you do not control at all: the one compiled into your Java runtime, the one in your Linux distribution, the one your employer installs on your laptop. On the machine this chapter was written on, the system store held 152 root certificates, and five came from no root programme at all.

The notice on your door is advice, not a lock#

CAA, the notice in the directory, is checked by authorities that follow the rules, at the moment of issuance, and the check has three limits people routinely miss.

It is checked by the authority, not by the browser. Nothing in a browser consults CAA. A certificate issued against your CAA record is still valid and every relying party will accept it. The record is enforced only by the honesty of the party it is meant to constrain.

It is checked at issuance, not afterwards. Adding a record today does nothing to certificates issued yesterday, which will be honoured until they expire.

And it constrains authorities, not people. A record saying “only this authority” does not stop your own hosting provider obtaining a certificate from that authority for your domain. It narrows the set of issuers, not the set of applicants. The extensions that begin to narrow applicants, by binding a record to a specific account, become mandatory in 2027.

There is often no single “the CA”#

The name in the issuer field of a certificate is one organisation. The work behind that certificate may have been done by several.

The rules allow an authority to delegate parts of the process to a third party, and separately allow an organisation to run its own registration function for its own domains. They allow one authority’s root to sign another organisation’s intermediate. They allow resellers who never touch validation but own the customer relationship, so the company you paid, the company that validated your domain and the company that signed can be three companies.

The rules push back steadily. Domain and IP validation may no longer be delegated to a third party at all, and delegated parties must be audited or covered by the authority’s own quarterly review. But when you see a familiar brand in an issuer field, do not assume that brand did the checking.

The plain story leaves out everything after issuance#

Finally, the plain version ends when the card is written, and the real story does not. Every publicly trusted certificate is recorded in append-only public logs, so a domain owner can discover one they never asked for, which is chapter 31. Certificates can be withdrawn before they expire, by mechanisms that work less well than people assume, which is chapter 30. Issuance is one third of the life of a certificate.

The technical version#

What a certification authority actually is#

In the vocabulary of the CA/Browser Forum’s Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.2.9, dated 6 August 2026, a certification authority is an organisation that holds private keys corresponding to certificates in software vendors’ trust stores, and uses them to sign certificates for others after performing prescribed verification.

Strip that down and there are three assets. Key material in a hardware security module in a locked room. A set of published documents, the Certificate Policy and the Certification Practice Statement, stating what the authority will do before it signs. And presence in the trust stores of Mozilla, Apple, Google and Microsoft. The first two can be bought in a week. The third takes years and can be withdrawn in an afternoon.

The chain of obligation runs like this, and it is worth drawing because the usual mental picture has it upside down.

Four root programmes, each independently:
  "comply with the Baseline Requirements and our own
   policy, or we remove your root"
                |
                v
CA/Browser Forum Baseline Requirements, v2.2.9,
6 Aug 2026  --  a document that nobody signs and that
binds nobody by contract
                |
                v
The CA's own CP/CPS  --  its public, versioned promise
of exactly which procedures it follows
                |
                v
An annual audit report, public, naming every root and
intermediate in scope by SHA-256 fingerprint
                |
                v
One certificate, valid for at most 200 days

Notice that the pressure travels downward from the software vendors, not upward from any regulator. The Baseline Requirements say so themselves: the requirements “are not mandatory for Certification Authorities unless and until they become adopted and enforced by relying-party Application Software Suppliers”. That is a standard describing its own lack of force. It works anyway, because all four suppliers have adopted it.

Domain, organization and extended validation#

There are three levels of verification in the public web PKI, and each writes a different policy identifier into the certificate’s certificatePolicies extension. Those identifiers are the only machine-readable statement of how much checking was done, and they are reserved in Baseline Requirements section 7.1.6.1.

Domain validation is the base case and the subject of most of this chapter. The authority confirms control of every fully qualified domain name that will appear in the certificate and puts nothing about the applicant into the subject. It is the only level performable entirely by machine, and it is the overwhelming majority of the public web PKI by volume.

Organization validation adds subject identity information: an organisation name, a locality, a country. Under section 3.2.2.1 the authority must verify the identity and address of the organisation using a government agency in the jurisdiction of its legal creation, a periodically updated reliable data source, a site visit, or an attestation letter. Section 3.2.2.3 separately governs the country code.

Extended validation is a different document. The Guidelines for the Issuance and Management of Extended Validation Certificates, version 2.0.3, dated 6 July 2026, are genuinely demanding. For a private organisation, section 3.2.2.2 requires verification of legal existence with the incorporating agency, of the exact registered name, of the registration number or date of formation, and of the registered agent. Section 3.2.2.4 requires a physical place of business that is not a mail drop or a post office box. Section 3.2.2.6 requires operational existence, proved by three years on the register, a listing in a qualified independent information source, or authenticated evidence of an active demand deposit account at a regulated financial institution. Sections 3.2.2.8 to 3.2.2.10 require the authority to verify the name, title and authority of the person who signs the contract and the person who approves the request, through a method of communication established independently of the applicant. For an unregistered business entity, section 3.2.2.2.1 requires face-to-face validation of a principal individual before an employee of the authority, a notary, a lawyer or an accountant. That is a serious identity check, and it is why extended validation costs what it costs.

Extended validation was created to put a company name in the browser’s address bar, in green, next to the padlock, and it worked as a product for about a decade. Then in December 2017 the researcher Ian Carroll incorporated a company in Kentucky under the name “Stripe, Inc”, which is also the name of a large payments company, and obtained a perfectly valid extended validation certificate for a domain of his own. Every check had been performed correctly and the name in the green box was true. It was simply not the company a user would assume. Google removed the indicator in Chrome 77 in September 2019, and Mozilla removed it from Firefox 70 in October 2019.

The honest version: extended validation still verifies real facts about a real legal entity, and those facts are still readable by software that wants them. What it lost was the thing it was sold for, a visual signal in a browser, and it lost it because a name in a box is not an identity when names are not unique across jurisdictions.

The ten blessed methods, and what is left of them#

Before 2016 the Baseline Requirements let an authority confirm domain control by “any other method of confirmation” that satisfied it. That clause is the worst sentence ever written in web security: it made the rulebook unenforceable, because no issuance could be non-compliant if the authority could invent the test afterwards.

Ballot 169, “Revised Validation Requirements”, adopted 5 August 2016 and effective 1 March 2017, replaced it with a closed, numbered list. Ballot 181, “Removal of some validation methods listed in Section 3.2.2.4”, adopted and effective 7 January 2017, retired the residual eleventh entry, “Any Other Method”, which left exactly ten. Practitioners have called them “the ten blessed methods” ever since. The phrase is a nickname, not a term in the specification, and here they are.

Eight of the ten are gone. Methods 1 and 5, which relied on registry paperwork that could not be checked automatically, went by ballot 218, adopted 5 February 2018. Method 9, “Test Certificate”, went by ballot SC015, adopted 5 February 2019. Methods 2 and 3, which read a contact out of WHOIS, were sunset by ballot SC080, adopted 7 November 2024, with reliance prohibited from 15 July 2025. Method 6 was superseded when ballot SC025 defined tightened HTTP methods on 31 January 2020. Method 8 could no longer be relied on from 15 March 2026.

Method 10 is the one worth dwelling on. “TLS Using a Random Value” was implemented in ACME as tls-sni-01, and asked the applicant to serve a specially named certificate in response to a particular Server Name Indication value. On 9 January 2018 Frans Rosen of Detectify reported that on shared hosting platforms, where many customers are served by one front end and may upload certificates for arbitrary names, one customer could satisfy the challenge for another’s domain. Let’s Encrypt disabled it the same day. A validation method must test something only the domain’s operator controls, and on shared infrastructure that is a smaller set of things than it looks.

Baseline Requirements version 2.2.9 permits twelve methods, plus a separate appendix procedure for onion domain names. Here they are with the names an engineer will actually meet.

Two details in that table matter.

First, there is no method called dns-01. The ACME dns-01 challenge is performed under method 3.2.2.4.7, “DNS Change”, which is broader than dns-01 and predates it. Only http-01, tls-alpn-01 and dns-account-01 have dedicated numbered methods, in sections 3.2.2.4.19, 3.2.2.4.20 and 3.2.2.4.21.

Second, the list is shrinking on a published timetable. Section 1.2.2 says the two telephone methods may not be relied on from 15 March 2027, and the three email methods may not be relied on from 15 March 2028; method 4 is already marked SHOULD NOT as of 15 March 2026. By 2028 the only permitted ways to prove control of a domain will be to change a DNS record, to serve a file, to answer a TLS handshake, or to be the registrar. Every method that depends on a human being reading an email or answering a telephone is being deliberately removed.

Two current details matter in practice. Method 3.2.2.4.22, “DNS TXT Record with Persistent Value”, added by ballot SC088 on 9 October 2025, lets a domain publish a standing record at the label _validation-persist naming both the authority and the account permitted to request certificates, with an optional persistUntil expiry; validations under it may be reused for at most ten days. And since ballot SC085 of 19 June 2025, DNSSEC validation of the validation queries is required from 15 March 2026, and a DNSSEC failure such as SERVFAIL must not be treated as permission to issue.

ACME, the protocol that turned issuance into a scheduled job#

Until about 2016, obtaining a certificate meant a human generating a signing request, pasting it into a web form, paying, waiting, receiving an email and installing a file. That workflow is why certificates were long: nobody was going to do it every quarter.

The Automatic Certificate Management Environment removed the human. The Internet Security Research Group, incorporated in May 2013, developed it for its Let’s Encrypt authority; the IETF chartered a working group in February 2015; Let’s Encrypt opened to the public in December 2015 on a pre-standard version; and the standard appeared as RFC 8555 on 12 March 2019.

ACME is a JSON-over-HTTPS protocol with a small object model. Every request after the first is a JSON Web Signature signed by the client’s account key, carrying a server-issued nonce so that requests cannot be replayed. The objects are these.

An account is the client’s identity at the authority, a URL bound to a public key. An order is a request for a certificate covering a set of identifiers. An authorization is the server’s record of whether control of one identifier has been proved, and carries an expiry. A challenge is one offered way of proving it.

Everything starts from a directory document, which is the only URL a client needs to know. Here is the live directory of the largest public authority in the world, retrieved in August 2026, with the host factored out so it fits the page.

base = https://acme-v02.api.letsencrypt.org

{
  "newNonce":    base + "/acme/new-nonce",
  "newAccount":  base + "/acme/new-acct",
  "newOrder":    base + "/acme/new-order",
  "revokeCert":  base + "/acme/revoke-cert",
  "keyChange":   base + "/acme/key-change",
  "renewalInfo": base + "/acme/renewal-info",
  "meta": {
    "caaIdentities": [ "letsencrypt.org" ],
    "profiles": {
      "classic":    "90-day certificates",
      "tlsserver":  "45-day certificates",
      "shortlived": "160-hour certificates"
    }
  }
}

The caaIdentities field is the authority telling you, in machine-readable form, which name to put in a CAA record to authorize it. The profiles object is newer than RFC 8555 and lets a client ask for a particular certificate shape; the three names and lifetimes above are one authority’s own, documented on 14 July 2026, and are an implementation detail rather than a standard.

The order flow, in the order the messages go:

GET  directory        -> URLs for everything else
HEAD newNonce         -> a nonce in a Replay-Nonce header
POST newAccount       -> account URL (the "kid")
POST newOrder         -> order object + authorization URLs
POST-as-GET authz     -> the challenges offered
   ... client does the work for one challenge ...
POST challenge        -> "I am ready, check me"
   ... server validates, from several perspectives ...
POST-as-GET order     -> status: ready
POST finalize (CSR)   -> status: processing, then valid
POST-as-GET cert URL  -> the PEM chain

Two properties of that flow matter. The certificate signing request is submitted at the end, at finalize, not at the start, so proof of domain control and proof of key possession are separate steps. And a satisfied authorization can be reused by later orders until it expires, which is why the Baseline Requirements control the reuse period so carefully.

The three challenges, worked with real values#

All three challenges are built on one string, defined in RFC 8555 section 8.1 and called the key authorization. It is the challenge token, a dot, and the base64url encoding of the SHA-256 thumbprint of the account key, computed as in RFC 7638 over the key’s canonical JSON form.

Here is a real one, computed while writing this chapter with a freshly generated P-256 account key. Every value below follows from the one above it, and the last two follow from the first two by hashing.

account key JWK, canonical form (one line, wrapped):
{"crv":"P-256","kty":"EC",
 "x":"WFuIukUGAbfBmqe4C9yMuy0J3INsT8hobCV368X8djs",
 "y":"LC6sfACvzeANZDneEZAo48J2KYx1hqTe_39sZyXr8Xs"}

thumbprint = base64url(SHA-256(that JSON)):
  ICGn01CNmk1aeoF0tliEI0Qo9_Rqwe2bA-O6roTirhU

token (from the server, 256 bits of entropy):
  ygHZRHgFtdVXmEwqF4wkhBCI6T-p2lmVtD1pVGskaiI

key authorization = token + "." + thumbprint:
  ygHZRHgFtdVXmEwqF4wkhBCI6T-p2lmVtD1pVGskaiI
  .ICGn01CNmk1aeoF0tliEI0Qo9_Rqwe2bA-O6roTirhU

base64url(SHA-256(key authorization)):
  emA3DAedFAzplzq5eSPrxqrfr-5qRPOCbYHryjb41j4

Now the three challenges, for the domain kedbyte.com.

http-01, defined in RFC 8555 section 8.3 and permitted as Baseline Requirements method 3.2.2.4.19. The client serves the key authorization as the body of a file whose path is the token. The request line below is wrapped to fit the page:

GET /.well-known/acme-challenge/ygHZRHgFtdVXmEwqF4wkh
    BCI6T-p2lmVtD1pVGskaiI HTTP/1.1
Host: kedbyte.com

HTTP/1.1 200 OK
Content-Type: application/octet-stream

ygHZRHgFtdVXmEwqF4wkhBCI6T-p2lmVtD1pVGskaiI.ICGn01CN
mk1aeoF0tliEI0Qo9_Rqwe2bA-O6roTirhU

The request goes over plain HTTP on port 80 by default, which is deliberate: the challenge exists partly to bootstrap a server with no working certificate yet. Section 3.2.2.4.19 adds requirements on top of the RFC. The response must carry a 2xx status. Redirects, if followed, must be HTTP-layer 301, 302, 307 or 308 responses to http or https URLs on an authorized port, and the authorized ports are exactly 80, 443, 25 and 22. The token may not be used for more than thirty days.

The practical consequence: http-01 needs a public web server on port 80 for that hostname, and it cannot issue wildcard certificates, because there is no single hostname at which to serve the file. The Baseline Requirements table in section 3.2.2.4 marks methods 18, 19 and 20 as unavailable for wildcards.

dns-01, defined in RFC 8555 section 8.4 and performed under Baseline Requirements method 3.2.2.4.7, “DNS Change”. The client publishes a TXT record at the label _acme-challenge prepended to the domain, whose value is the base64url SHA-256 digest of the key authorization, not the key authorization itself:

_acme-challenge.kedbyte.com. 60 IN TXT
  "emA3DAedFAzplzq5eSPrxqrfr-5qRPOCbYHryjb41j4"

dns-01 is the only challenge that can issue a wildcard certificate, because DNS is the one place where a statement about *.kedbyte.com can be made without a server existing. It is also the only one that works for a host with no public address, which is why it is the right answer for internal load balancers, mail servers and appliances. Its cost is that the client needs credentials to change your DNS zone. The usual mitigation is a CNAME from _acme-challenge.kedbyte.com into a separate, disposable zone.

tls-alpn-01, defined not in RFC 8555 but in RFC 8737, February 2020, and permitted as Baseline Requirements method 3.2.2.4.20. The client answers a TLS connection on port 443 in which the peer offers the Application-Layer Protocol Negotiation identifier acme-tls/1, presenting a self-signed certificate for the domain that carries a critical extension, id-pe-acmeIdentifier, with the object identifier 1.3.6.1.5.5.7.1.31, containing a 32-byte ASN.1 OCTET STRING holding the SHA-256 digest of the key authorization:

extension : 1.3.6.1.5.5.7.1.31  (critical)
value     : OCTET STRING, 32 bytes
  7a60370c079d140ce9973ab97923ebc6
  aadfafee6a44f3826d81ebca36f8d63e

The extension must be critical so the certificate is useless for anything else: any ordinary TLS client meeting an unrecognised critical extension must reject it. tls-alpn-01 is the answer when port 80 is closed and you do not want to give an automated client your DNS credentials, and it is the only challenge answerable entirely inside the TLS terminator.

Corroborating the answer from several places at once#

Every challenge above has the same structural weakness: the authority asks a question over the internet and believes the answer that comes back. An adversary who can make that traffic arrive at a machine of their choosing, for the minute the check takes, obtains a genuine certificate.

Ballot SC067, “Require Multi-Perspective Issuance Corroboration”, adopted 2 August 2024 and effective 6 September 2024, with mandatory compliance from 15 March 2025, made this structural. Under Baseline Requirements section 3.2.2.9, an authority using the DNS, website or ALPN methods must repeat the check, and the CAA lookup, from remote network perspectives and compare the results.

The rules are specific in a way that shows the threat model. Perspectives count as distinct only if the straight-line distance between them is at least 500 kilometres. A perspective may use a resolver that is not co-located, but that resolver must be in the same regional internet registry service region, and any two resolvers used in one attempt must be 500 kilometres apart. Results may not be cached or shared between perspectives.

The corroborating perspective must observe the same challenge value as the primary one, not merely succeed. Retrying is permitted without limit, but a retry may not reuse corroborations from a previous attempt.

The honest version: this raises the cost of a routing attack from hijacking one path to hijacking most paths at once, which is a large practical difference and not a proof of anything. Domain validation remains a network measurement, and network measurements can be lied to.

CAA: how a domain names its own authorities#

Certification Authority Authorization is a DNS record type, number 257, by which the operator of a domain publishes which certification authorities may issue for it. It was first specified in RFC 6844 in January 2013 and is now specified in RFC 8659, “DNS Certification Authority Authorization (CAA) Resource Record”, November 2019, which obsoletes it.

A CAA record has three parts: a one-octet flags field, a property tag, and a property value. The issue tag, section 4.2, names an authority permitted to issue ordinary certificates; issuewild, section 4.3, does the same for wildcards; iodef, section 4.4, gives a mailto or https address for reporting a refused request. If the top bit of the flags octet is set the property is critical, and an authority meeting a critical tag it does not recognise must refuse to issue at all.

Lookups climb. RFC 8659 section 3 states that the search climbs the DNS name tree from the label being validated up to, but not including, the root. A certificate for www.kedbyte.com causes a lookup at www.kedbyte.com, then kedbyte.com, then com, stopping at the first label with a record set of any kind. An empty result is not permission; it is a reason to climb.

Here are real records, looked up in August 2026.

$ dig +short CAA wikipedia.org
0 issue "letsencrypt.org"
0 issue "pki.goog"
0 iodef "mailto:dns-admin@wikimedia.org"

Wikimedia permits exactly two authorities and asks to be emailed about refusals. The next shows the parameter syntax an issue value supports.

$ dig +short CAA cloudflare.com
0 issue "letsencrypt.org"
0 issue "comodoca.com"
0 issue "ssl.com"
0 issue "digicert.com; cansignhttpexchanges=yes"
0 issue "pki.goog; cansignhttpexchanges=yes"
0 issuewild "letsencrypt.org"
0 iodef "mailto:tls-abuse@cloudflare.com"

Everything after a semicolon is a parameter list, and authorities must ignore parameters they do not understand unless the record is critical. The third example is the author’s own domain, which had no CAA record at all when this chapter was written.

$ dig CAA kedbyte.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; QUESTION SECTION:
;kedbyte.com.        IN  CAA
;; AUTHORITY SECTION:
kedbyte.com.  600 IN SOA ns1.dns-parking.com. ...

NOERROR with no answer section and an SOA in the authority section means the name exists and has no CAA record, so every authority in the world may issue for it. Three records change that.

kedbyte.com. 3600 IN CAA 0 issue "letsencrypt.org"
kedbyte.com. 3600 IN CAA 0 issuewild ";"
kedbyte.com. 3600 IN CAA 0 iodef "mailto:security@kedbyte.com"

The middle line is the most useful CAA idiom and the least obvious. A property value of a bare semicolon names no authority, so it forbids everything: this says “no wildcard certificates for this domain, from anybody”. If you do not use wildcards, that one line closes off a whole class of mis-issuance for nothing.

CAA checking became mandatory by ballot 187, adopted 8 March 2017 and effective 8 September 2017, one of the few dates on which the security of the whole web PKI improved overnight. Section 4.2.2.1 sets the current rules: process records for every dNSName, handle issue, issuewild and iodef, respect the critical flag, and issue within the record’s time-to-live or eight hours, whichever is greater. A lookup failure counts as permission only if it is outside the authority’s infrastructure, has been retried, and the domain is confirmed “Insecure” in the DNSSEC sense.

RFC 8657, November 2019, adds the accounturi and validationmethods parameters, which narrow permission from “this authority” to “this authority, only for this account, only by these methods”. Ballot SC098, adopted 13 May 2026, makes processing them mandatory from 15 March 2027. That is the change that turns CAA from a statement about vendors into a statement about accounts, and it is the most valuable line most domain owners are not yet publishing.

The honest version, stated plainly: CAA is a rule the issuer applies to itself. No browser reads it. A compromised or dishonest authority ignores it. It prevents mistakes, misdirected requests and unauthorized purchases by your own staff, and it does not prevent an attack on the authority.

Getting into a root programme#

A root certificate is worth nothing until software ships it. Four programmes decide, and they are separate organisations with separate documents.

All four route their paperwork through the Common CA Database, which Mozilla created and operates and which is, as of 2026, a directed fund of the Linux Foundation. Audit reports, policy documents, incident reports, the full list of intermediates and the applications themselves live there.

Mozilla’s policy is the most readable and the most copied. Section 7.1 states that Mozilla charges no fee for inclusion, then lists what it wants instead: certificate data, the trust bits sought, links to the policy and practice statement, an auditor-witnessed root key generation ceremony report, and continuous period-of-time audits with no gaps from the moment of key generation. The phrase in section 3.1.3 is “cradle-to-grave”: an authority that cannot document what happened to a key in 2014 cannot use that key in 2026.

Three current Mozilla requirements show where the whole industry is going. Automation is a condition of entry: an applicant must demonstrate at least one automated issuance method for each certificate type, serve test certificates from public websites, renew them at least every thirty days, and disclose the URLs. From 1 July 2026 Mozilla will only accept a root whose key pair was generated no more than five years before submission. And section 7.4 puts a hard lifetime on trust itself: the websites trust bit is removed when key material is over fifteen years old, and email at eighteen.

Chrome runs the same way with different numbers. Version 1.8 requires at least one complete audit covering a minimum of 180 days before submission, root key material generated within five years of application, a fifteen-year term limit, and, from 15 March 2027, that every subordinate CA certificate support an automated issuance solution, demonstrated by test certificates renewed every thirty calendar days. Subordinate CAs disclosed on or after 15 June 2025 must assert only the id-kp-serverAuth extended key usage.

Apple’s policy, version 2.0, prefers WebTrust and accepts ETSI “on a case-by-case basis”, a small phrase with large consequences for European authorities. It requires RSA of at least 4096 bits or ECDSA of at least 384 bits for root inclusion requests, requires roots dedicated to a single trust purpose, and names the validation methods an authority must support: at least one of 3.2.2.4.7, 3.2.2.4.18, 3.2.2.4.19 or 3.2.2.4.20. From 1 July 2027 each policy document must be a Markdown file scoped to a single trust purpose, the first time a root programme has specified a file format.

Microsoft requires a qualifying audit before commercial operation and annually after, requires the full hierarchy to be disclosed annually, sets new root validity between eight and twenty-five years, and states plainly that authorities may not enrol roots primarily intended to be trusted internally. Mozilla’s section 7.5 adds that roots accepted after 15 March 2025 carry either the websites bit or the email bit but not both, with existing dual-purpose roots transitioning before 31 December 2028.

The audit, and what it does and does not cover#

Baseline Requirements section 8.4 accepts two schemes, plus a narrow exception for government authorities with their own mandated internal scheme.

WebTrust is the older of the two. The AICPA/CICA WebTrust Program for Certification Authorities version 1.0 was issued on 25 August 2000, and the programme is now managed by the Chartered Professional Accountants of Canada; an authority audited under it must engage a firm enrolled by CPA Canada as a WebTrust practitioner.

The ETSI route is the European one. ETSI EN 319 411-1 sets policy and security requirements for trust service providers issuing certificates, and part 2 covers EU qualified certificates. The audit is performed by a conformity assessment body accredited under ISO/IEC 17065 applying ETSI EN 319 403, and reports follow a template published by the Accredited Conformity Assessment Bodies’ Council. They state which policy identifiers were assessed, and those matter: for the websites trust bit Mozilla requires LCP with DVCP or OVCP, or NCP with EVCP, or the qualified web policy QCP-w.

Under section 8.2 the auditor must be independent, competent in public key infrastructure and information security, accredited or licensed as above, bound by law or a professional code of ethics, and insured for professional liability of at least one million US dollars.

Under section 8.6 the report must be public within three months of the end of the audit period and must carry ten specified items. Four of them hold almost all the information: the criteria and version numbers actually applied, since an audit against last year’s criteria is not an audit against this year’s rules; the period start and end, since section 8.1 requires an unbroken sequence and a gap is a finding in itself; the SHA-256 fingerprints of every root and subordinate in scope, since a certificate from a subordinate that was not in scope is covered by nothing; and whether the opinion is qualified, and what the qualification says.

Now the limits. An audit is a period-of-time assurance engagement about the design and operating effectiveness of controls, not a re-performance of every validation. The quarterly self-audit under section 8.7 samples the greater of one certificate or three per cent of issuance. The control that inspects every certificate is pre-issuance linting, mandatory since 15 March 2025 under section 4.3.1.2.

Two programmes now want more than an opinion. Mozilla section 3.1.5 requires, for each annual audit period beginning on or after 1 July 2027, a Detailed Controls Report describing system boundaries, the mapping of controls to criteria, the auditor’s tests including their nature, timing and extent, and the evidence used. It need not be published, but it must reach Mozilla within thirty days of request. Apple imposes an equivalent requirement from the same date. The direction of travel is from “an opinion that controls were effective” to “show us the test work”.

The CA/Browser Forum: who votes, and what a ballot binds#

The forum began in 2005, when Melih Abdulhayoglu of Comodo convened a first meeting in New York City between certification authorities and browser vendors. Its first product was the Extended Validation Guidelines version 1.0, adopted 7 June 2007. Its second and far more important product was the Baseline Requirements version 1.0, adopted by ballot 62 on 22 November 2011 and effective 1 July 2012, which set a floor under every publicly trusted certificate rather than only the premium ones.

The forum today is organised into chartered working groups: Server Certificate, S/MIME, Code Signing, Network Security, and Definitions and Glossary. This chapter is entirely about the output of the Server Certificate Working Group.

Membership falls into four classes, and only two of them vote.

The arithmetic of a ballot, from the Bylaws version 2.5 effective 20 July 2023, is the most important governance fact in the web PKI. A ballot passes only if two-thirds or more of the votes cast by certificate issuers are in favour, and fifty per cent plus one of the votes cast by certificate consumers are in favour. Abstentions count towards neither fraction. At least one member of each class must vote in favour. A result is valid only if more than half of the currently active voting members took part, and abstentions do count towards that quorum. The discussion period runs at least seven calendar days and the voting period exactly seven, after which a review period of thirty or sixty days runs for patent exclusion notices.

Which raises the question of what a ballot actually binds. Formally, nothing. The Baseline Requirements are guidelines; no authority signs them; there is no contract, no regulator and no court. What makes them binding is that each root programme has separately written “comply with the Baseline Requirements” into its own policy, and each can remove a root unilaterally. The forum is a drafting committee whose output four companies have each chosen to enforce, and when it will not move, a root programme moves without it.

The lifetime schedule: sixty months to forty-seven days#

Here is the whole history of the maximum lifetime of a publicly trusted TLS certificate.

Two rows have stories.

The 2020 row tells you how this industry is actually governed. Ballot SC22, “Reduce Certificate Lifetimes”, proposed by Google, would have cut the maximum to 398 days. Its results were published on 10 September 2019 and it failed. Thirty-three certificate issuers voted: eleven in favour, twenty against, two abstaining, which is thirty-five per cent in favour against a two-thirds threshold. Every certificate consumer that voted was in favour. The authorities had blocked it.

In February 2020 Apple announced, alone, that Safari and Apple operating systems would not trust any TLS certificate issued on or after 1 September 2020 with a validity period over 398 days. There was no ballot and no appeal. Within months the same limit was in the Baseline Requirements by way of ballot SC031, “Browser Alignment”, adopted 16 July 2020. The lesson participants drew is the correct one: the forum is where the industry agrees how to do what the root programmes have already decided.

The 2025 row shows what was learned. Ballot SC081v3 passed on 11 April 2025 with thirty certificate issuers voting, twenty-five in favour, none against and five abstaining, and four certificate consumers all in favour. The body that could not reach thirty-five per cent for a one-year limit in 2019 could not find one vote against forty-seven days six years later. Automated issuance had become normal, and a shorter certificate had stopped being a staffing problem.

Section 6.3.2 states the schedule with a SHOULD NOT one day tighter than each MUST NOT, so that a certificate issued at the exact maximum does not fall foul of leap seconds. A day is 86,400 seconds and any excess counts as a whole additional day. As of August 2026 the maximum in force is 200 days.

Validation data has its own, faster schedule, and this is the part most people miss: it is not only the certificate that expires, it is the proof behind it.

A ten-day reuse period from March 2029 means a validation performed today supports issuance for ten days and must then be repeated. There is no plausible way to do that by hand for an estate of any size. The lifetime schedule and the automation mandates in the root programme policies are one policy seen from two directions.

The market has already moved past the mandate. Let’s Encrypt’s tlsserver profile issues 45-day certificates with a seven-hour authorization reuse period, and its shortlived profile issues certificates valid for 160 hours, under the seven-day threshold at which the Baseline Requirements stop requiring revocation information in a certificate. The same authority announced on 2 December 2025 that its default profile moves to 64-day certificates on 10 February 2027 and to 45-day certificates on 16 February 2028. Those are product decisions, not standards.

For scale, its tenth anniversary post of 9 December 2025 reported issuing roughly ten million certificates a day, having first passed ten million in one day in September 2025, and described itself as closing in on protecting one billion websites. That is what “a machine does it” looks like, and it began with a single certificate on 14 September 2015.

Private certification authorities and internal PKI#

Everything above concerns the public web PKI: certificates that chain to a root in somebody else’s trust store. A private certification authority does the identical technical job for a trust anchor that its operator distributes itself.

The machinery is the same: a key in a hardware module, a self-signed root, intermediates, X.509 certificates with the same extensions and algorithms, often literally the same software. What differs is the last mile. Instead of applying to four root programmes, the operator pushes its root into the trust stores of machines it controls.

The Baseline Requirements do not apply, because they are scoped to publicly trusted certificates and Mozilla’s policy is scoped to certificates chaining to roots in Mozilla’s store. A private authority may issue a ten-year certificate for a name that does not exist in the DNS with a 1024-bit key and break no rule. That is a freedom, and it is also the whole risk, because nothing external will catch the mistake.

Public authorities may not issue for internal names at all. Section 4.2.2 forbids certificates containing internal names or reserved IP addresses, an internal name being anything that cannot be verified as globally unique in the public DNS because it does not end in a top-level domain in the IANA root zone. It was not always so: authorities once sold certificates for names like mail and intranet, valid for every organisation using the same name. The ICANN Security and Stability Advisory Committee documented the hazard in advisory SAC057, and the forum required all such certificates to be revoked by 1 October 2016.

That left a gap. On 29 July 2024 the ICANN Board, by resolution 2024.07.29.06 and following the committee’s advisory SAC113 of 18 September 2020, reserved the top-level domain .internal for private use and undertook never to delegate it. For internal PKI that is the practical answer: name internal services under a domain you own, or under .internal, and never under a name you do not control.

Automation transfers directly. Because ACME is a protocol rather than a service, private authorities implement it and ordinary clients work against them unchanged. Common implementations in 2026 include Microsoft Active Directory Certificate Services, shipped with Windows Server since 2000, the open-source EJBCA and Dogtag, HashiCorp Vault’s PKI secrets engine, smallstep’s step-ca, and the managed private CA services of the large cloud providers.

One hard technical control deserves naming, and chapter 27 covers it properly: name constraints, the X.509 extension in RFC 5280 section 4.2.1.10, which lets a parent restrict a subordinate to a stated set of names. A private root installed on employee laptops without name constraints can issue a valid certificate for any site on the internet, to those laptops.

Which is exactly what happens. The machine this chapter was written on held 152 root certificates. Of those, 147 came from the Mozilla-derived bundle in the distribution’s ca-certificates package, version 20240203, representing 69 distinct organisations. The other five were installed by the operator of the network the machine was on, and their common names included the phrase “TLS Inspection CA”. Those five can mint a certificate for any name in the world and the machine will accept it without complaint.

The one thing a private authority must never become is a publicly trusted one. In February 2012 it emerged that Trustwave, a publicly trusted authority, had issued a subordinate CA certificate to a private company for exactly this kind of traffic inspection. Mozilla published a message to all certification authorities on 17 February 2012 requiring that such certificates be revoked and the hardware modules holding their keys destroyed. The line between a public and a private authority is not technical. It is a rule about whose trust store you are allowed to be in.

The whole thing, end to end, for one domain#

Put every piece together for one certificate for kedbyte.com in August 2026.

1. Owner publishes CAA:
     kedbyte.com. CAA 0 issue "letsencrypt.org"
     kedbyte.com. CAA 0 issuewild ";"
2. ACME client fetches the directory, registers an
   account key, POSTs newOrder for kedbyte.com.
3. Server returns an authorization with challenges.
   Client picks dns-01 (works without a web server).
4. Client computes:
     keyauth = token + "." + thumbprint
     record  = base64url(SHA-256(keyauth))
   and publishes _acme-challenge.kedbyte.com TXT.
5. Client POSTs the challenge: "check me".
6. Server checks CAA and the TXT record from the
   primary perspective and at least two remote
   perspectives over 500 km apart, with DNSSEC.
7. Authorization becomes valid. Reuse limit: 200 days
   (100 from 15 Mar 2027, 10 from 15 Mar 2029).
8. Client POSTs the CSR to finalize; server issues.
9. Certificate: max validity 200 days, policy OID
   2.23.140.1.2.1, logged publicly (chapter 31).
10. Client schedules renewal at roughly one third of
    the remaining lifetime and repeats from step 2.

No human being appears after step 1, and the only judgement in the sequence is at step 6, where a machine decides whether a DNS record it did not write says what it was told to expect. Everything else in this chapter exists to make that one judgement trustworthy enough to build a civilisation’s commerce on.

28.98 Common wrong ideas#

Wrong: A certificate authority provides the encryption that protects your connection. Right: The encryption is negotiated between browser and server using published algorithms that cost nothing; what the authority contributes is a signed assertion that a named key belongs to a named domain, so that the encryption is aimed at the right party rather than an impostor.

Wrong: A padlock means the site belongs to the organisation it appears to belong to. Right: For a domain-validated certificate, which is the overwhelming majority, the only verified fact is that somebody proved control of that exact domain name recently; the certificate carries no organisation name, and a phishing domain gets an identical padlock.

Wrong: There are ten permitted ways to prove domain control. Right: There were ten between 2017 and 2018, which is where the nickname comes from, but section 3.2.2.4 now permits twelve numbered methods plus an appendix for onion names, and five of the twelve are already scheduled for removal in 2027 and 2028.

Wrong: A CAA record stops anyone else getting a certificate for your domain. Right: CAA is checked by the issuing authority at issuance and by nothing else; browsers never read it, it has no effect on certificates already issued, and it constrains which authorities may issue rather than which applicants may ask until the RFC 8657 parameters become mandatory in 2027.

Wrong: An annual audit means every certificate the authority issued was checked. Right: An audit is an opinion about whether described controls were suitably designed and operating effectively over a period, tested on a sample; the control that inspects every certificate is pre-issuance linting, mandatory since 15 March 2025.

Wrong: The CA/Browser Forum regulates certificate authorities. Right: It is a voluntary drafting body whose guidelines bind nobody by contract and work only because Mozilla, Apple, Google and Microsoft each wrote compliance into their own root programme policies, which is why Apple could impose a 398-day limit in 2020 after the forum voted the same proposal down in 2019.

Wrong: Certificate lifetimes are being shortened to sell more certificates. Right: Certificates from the largest issuer are free, and the shortening is driven by root programmes; revocation does not work reliably, so a short expiry is the only dependable way to retire a compromised or wrongly issued certificate, and the 47-day schedule passed with no votes against.

Wrong: Internal systems can use public certificates for internal names like intranet or server1. Right: Section 4.2.2 forbids issuing for internal names entirely and all such certificates had to be revoked by 1 October 2016; internal systems need a private authority, or public certificates for names under a domain you own, or names under .internal, reserved by ICANN on 29 July 2024.

Wrong: A private certificate authority is less secure than a public one because it is not audited. Right: It answers a different question, which is whether machines under one organisation’s control should trust each other, and for that the operator’s own controls are the right ones; the real hazard is a private root without name constraints, which can mint a valid certificate for any site on the internet.

Wrong: Once a root is in the trust stores the authority is set for decades. Right: Mozilla removes the websites trust bit at fifteen years from key generation and distrusts email at eighteen, Chrome applies a fifteen-year term limit, Mozilla will not accept a root whose key is over five years old at submission, and any programme may remove a root at any time.

28.99 Chapter summary in 20 lines#

1. A certification authority does not sell cryptography, which is free; it sells a checked claim that a named key belongs to a named domain.
2. Domain validation confirms control of a name and nothing else, and writes the policy identifier 2.23.140.1.2.1 into the certificate.
3. Organization validation adds a verified legal entity under Baseline Requirements section 3.2.2.1 and uses 2.23.140.1.2.2.
4. Extended validation applies the EV Guidelines version 2.0.3 and uses 2.23.140.1.1, but lost its browser indicator in Chrome and Firefox in 2019.
5. Ballot 169, effective 1 March 2017, replaced an open-ended “any other method” clause with a closed numbered list, which made auditing possible.
6. The ten methods that list contained are the “ten blessed methods”, and eight have since been retired, each for a specific failure.
7. Twelve numbered methods are permitted in August 2026, and the email and telephone ones are scheduled for removal in 2027 and 2028.
8. ACME, published as RFC 8555 in March 2019, turned issuance into a machine task, and that automation is what made short certificates possible.
9. The key authorization is the challenge token, a dot, and the base64url SHA-256 thumbprint of the account key.
10. http-01 serves that string as a file under /.well-known/acme-challenge on port 80 and cannot issue wildcard certificates.
11. dns-01 publishes the base64url SHA-256 digest of it as a TXT record at _acme-challenge, and is the only challenge that issues wildcards.
12. tls-alpn-01, from RFC 8737, answers a TLS handshake using acme-tls/1 with a critical extension 1.3.6.1.5.5.7.1.31 holding that digest.
13. Since 2025 the same check must be corroborated from network perspectives at least 500 kilometres apart, to raise the cost of a routing attack.
14. CAA, specified in RFC 8659, lets a domain name its permitted issuers, has been mandatory to check since 8 September 2017, and binds only the issuer.
15. Mozilla, Apple, Chrome and Microsoft run separate root programmes, and all four now require automation, young root keys and single-purpose roots.
16. WebTrust and ETSI EN 319 411 audits test control design and operating effectiveness over a period on a sample, not every certificate.
17. A CA/Browser Forum ballot needs two-thirds of certificate issuer votes and fifty per cent plus one of consumer votes, so either side can block it.
18. Maximum lifetimes fell from 60 months in 2012 to 39 months, 825 days, 398 days, and 200 days on 15 March 2026, heading to 47 days on 15 March 2029.
19. Validation data reuse falls on the same schedule to 10 days in 2029, which is the requirement that makes manual issuance impossible.
20. A private authority uses identical machinery with its own trust anchor, sits outside every rule in this chapter, and is the right answer for internal names, which public authorities may not certify.

Chapter sources: CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.2.9, dated 6 August 2026, sections 1.2.1, 1.2.2, 3.2.2.1, 3.2.2.3, 3.2.2.4 with subsections 3.2.2.4.1 to 3.2.2.4.22, 3.2.2.9, 4.2.1, 4.2.2, 4.2.2.1 with 4.2.2.1.1 to 4.2.2.1.3, 4.3.1.2, 6.3.2, 7.1.6.1, 8.1, 8.2, 8.4, 8.6 and 8.7, and the definitions of Authorized Ports, Authorization Domain Name, Internal Name, Random Value, Request Token and Short-lived Subscriber Certificate; CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation Certificates, version 2.0.3, dated 6 July 2026, sections 3.2.2.2, 3.2.2.4, 3.2.2.6, 3.2.2.8 and 3.2.2.14.3; CA/Browser Forum ballots 62, 169, 181, 187, 193, 218, SC015, SC022v2 (failed, results 10 September 2019), SC025, SC031, SC067, SC080, SC081v3, SC085, SC088, SC098 and SC101, with the adoption and effective dates given in Baseline Requirements section 1.2.1; CA/Browser Forum Bylaws version 2.5, effective 20 July 2023, and the Forum’s published membership list as retrieved in August 2026; RFC 8555, “Automatic Certificate Management Environment (ACME)”, Barnes, Hoffman-Andrews, McCarney and Kasten, 12 March 2019, sections 7.1, 8.1, 8.3 and 8.4; RFC 8737, February 2020, section 3; RFC 8659, November 2019, obsoleting RFC 6844 of January 2013, sections 3, 4.2, 4.3 and 4.4; RFC 8657, November 2019; RFC 7638 for JSON Web Key thumbprints; RFC 5280 section 4.2.1.10 for name constraints; Mozilla Root Store Policy version 3.1, effective 1 July 2026, sections 1.1, 2.3, 2.4, 3.1.1 to 3.1.5, 7.1, 7.4 and 7.5; Apple Root Program Policy version 2.0, effective 1 August 2026, sections 1.1, 1.2.3.1, 2.1.3, 2.2 and 4; Chrome Root Program Policy version 1.8, effective 5 February 2026; the Microsoft Trusted Root Program requirements page, revised 28 April 2026; the CCADB Policy and Incident Reporting Guidelines; AICPA/CICA WebTrust Program for Certification Authorities version 1.0, 25 August 2000; ETSI EN 319 411-1 v1.4.1 and v1.5.1, ETSI EN 319 411-2 v2.5.1 and v2.6.1, and ETSI EN 319 403 with ISO/IEC 17065; Apple’s February 2020 announcement of a 398-day maximum; Frans Rosen of Detectify on the TLS-SNI-01 shared hosting exploit, 9 January 2018; Ian Carroll’s “Stripe, Inc” extended validation certificate, December 2017; Mozilla Security Blog, “Message to Certificate Authorities about Subordinate CAs”, 17 February 2012; ICANN SSAC advisories SAC057 and SAC113 of 18 September 2020, with ICANN Board resolution 2024.07.29.06 of 29 July 2024; Let’s Encrypt documentation “Profiles” of 14 July 2026 and its posts of 2 and 9 December 2025. The CAA lookups, trust store counts and key authorization worked example were produced with dig 9.18.39, OpenSSL 3.0.13 and Python 3 on Ubuntu 24.04 in August 2026.