The certificate was valid somewhere.

Two slips of paper lie side by side. The first is a maintenance ticket for a certificate rotation, stamped "rotation complete." The second is a connection receipt from a customer's server, printed the next day, and its last line reads "certificate verify failed." Both slips are reconstructions written for this dispatch, not documents from any company. Each is accurate about what it measured.

On June 8, the analytics company Sigma published a postmortem of a disruption in which a subset of its customers could not authenticate to Sigma or connect to its API endpoints. In Sigma's account, a third-party network services provider automatically rotated its TLS certificates to an updated certificate hierarchy, but bundled them with an expired cross-signed intermediate certificate. Clients running older operating system images, or with "certificate stores not updated since approximately 2021," could no longer establish a secure connection. The provider deployed a corrected bundle on June 1, and Sigma recorded a final customer confirmation of full resolution on June 2.¹ The post's header, summary and timeline mark the start differently, so I will not put a single number on how long it lasted. It is also Sigma's account, not one agreed by every affected organization.

The lesson is not really about certificates. It is that a change is complete only within a stated boundary. Provider-side completion means the change finished on the provider's infrastructure: the new certificates were issued, installed and served. Client-side interoperability means the clients a service supports can still connect, end to end, as they are actually configured. The first can be true while the second is false for some customers, and the ticket will not say so. The answer is not to test everything forever. It is to test the combinations customers actually use, and to say openly which ones are supported.

Trust takes two

A secure web connection works only if two parties agree. The server presents its certificate, plus the intermediate certificates that link it to an authority. The client checks that chain against its own list of trusted roots, its trust store. HTTP's standard says the client must verify the server's identity, and that this requires the client to be configured with a set of trust anchors.² Neither side settles the outcome alone. The same chain can be accepted by a laptop updated last month and rejected by a server image built years ago, because their trust stores differ. When an intermediate in the served chain has expired, one client may still find a valid path to a root it trusts and another may not, depending on what it holds and how it searches.

So "the certificate is valid" is an unfinished sentence. Valid for which client?

Separate the operation from the acceptance

In Sigma's timeline, the scheduled rotation completed on May 30 and the first customer reports arrived the next day. At midnight UTC on June 1, an initial customer resolved its problem on its own and the incident was temporarily closed. That afternoon, widespread reports were confirmed across multiple organizations.¹ The temporary closure was a reasonable call on the evidence at hand. It also shows how much one success can be made to stand for.

A change has an operation and an acceptance criterion. The operation for a rotation is finishing the swap. The acceptance criterion should face the customer: named classes of supported clients connect, end to end, after the change. Writing the criterion down before the change turns "done" from a feeling into a test.

A small matrix, not an endless one

No organization can test every client in the world. It can test a handful of classes that stand for its customers' real risk. Four are a reasonable start: a current managed device; the oldest operating system image still supported; an automated service client, such as an integration that carries its own certificate store inside its runtime or container; and a connection through a corporate proxy, where the proxy's trust store decides. These are my suggested classes, not a description of Sigma's systems.

Where a class cannot reasonably be kept working, the honest response is an end-of-support decision: name the class, set the date, tell the customers. Supporting everything forever is not a realistic promise. Discovering the boundary from customer complaints is worse.

Sigma's own next step points the same way. It says it is implementing automated monitoring that continuously verifies the full certificate chain served to clients.¹ That is a commitment rather than a result, and it is still a check of what the server sends. The fuller version adds probes that behave like the client classes above.

What closes the incident

An incident should close on evidence that matches the acceptance criterion: probes from each supported client class succeed, customers who reported the failure confirm it is gone, and any conditions that remain unsupported are stated in writing. Sigma's timeline records the provider's correction and the final customer confirmation separately, a day apart.¹ Every postmortem should keep that distinction.

One remedy should be ruled out: telling customers to switch off certificate validation. The HTTP standard allows that a client might ignore a server's identity in special cases, but warns that this "leaves a connection open to active attack."² A connection that works because nobody is checking is not a fix.

Objections, considered

Customers should update old systems. They should, under a published support policy. That does not remove the need to know which supported combinations a change can break before it ships.

Testing every client is impossible. Agreed. Choose representative risk classes and state the limits. The alternative to a small matrix is not exhaustive certainty; it is no matrix.

This was a supplier's mistake. In Sigma's account, the faulty bundle came from its provider. That explains a cause. It does not tell a buyer which of its own paths stayed usable, which is the question its users were asking.

Completion at the supplier is evidence about the supplier, not every client.

Before the next certificate change

• Which supported clients does the release check represent? Name them, and name the ones it does not.
• What does an older trust store change? Test the oldest supported image and any client that carries its own certificate store.
• What evidence closes the incident? Probes per client class, customer confirmation, and a written list of what remains unsupported.

Back to the maintenance ticket. Under "rotation complete," add one line: accepted when the supported client classes connect end to end. Until that line is ticked, the certificate is valid somewhere, and the change is not done.