On the morning of August 14, 2026, the page you check to find out whether Claude is up would not load. Not traffic, not a bad deploy. Its TLS certificate was invalid, so browsers refused to connect to status.claude.com and threw a full-screen warning instead. The one page whose whole job is to stay reachable when everything else is on fire was taken down by the exact problem it exists to report. Anthropic marked it resolved at 10:53 UTC.
It is easy to laugh at from the outside, and the wrong lesson is that someone was careless. This is a company last valued near a trillion dollars, with deep infrastructure teams and every reason to get the boring things right. It still served a bad certificate on a public hostname where the whole internet could see it. If it can happen there, the useful question is not how they let it happen, but what makes you think it can't happen to you.
A Certificate Fails Closed
TLS has no soft failure. When a certificate is expired, issued for the wrong name, or chains to an issuer the client does not trust, the connection does not degrade or drop back to plain HTTP. It stops.
Your connection is not private
Attackers might be trying to steal your information from
status.claude.com (for example, passwords, messages or credit cards).
NET::ERR_CERT_COMMON_NAME_INVALID
The code at the bottom is specific. NET::ERR_CERT_COMMON_NAME_INVALID is not an expiry. The name on the certificate did not match status.claude.com, which is what you get when a host is served a certificate cut for another name, or a provider's default. And because the site sends HSTS, Chrome offered no click-through: there was no proceed-anyway. For everyone who went looking that morning, the status page was simply gone.
Now put that behind the URL people open precisely when they suspect an outage. A slow API is annoying. A red "attackers might be trying to steal your information" warning on your status page is a different kind of bad, because it lands the moment users are already anxious and looking for reassurance.
Why a Company This Sophisticated Still Missed It
Anthropic did not say how the wrong certificate landed on that host, so treat the root cause as unknown. What is knowable is how a mature operation serves a wrong-name certificate at all, because the same gaps show up everywhere:
| How it happens | Why the main renewal automation misses it |
|---|---|
| A status page runs on separate or third-party infrastructure | It sits outside the pipeline that renews the primary domains, on its own clock |
| A subdomain provisioned once, by hand | Nobody wired it into the automated renewal, so it quietly counts down |
| A wildcard that does not cover the host | *.example.com does not match status.example.com on some stacks |
| Renewal succeeded, but a node kept the old file | A load balancer or one backend serves a stale cert the deploy never reloaded |
| The cert has no owner | The team that stood it up moved on; the alert, if any, goes to a dead inbox |
Notice what is missing from that list: incompetence. Certificates rotate on 90-day cycles, soon shorter, and every host, subdomain, internal service, and appliance carries its own. The count that must renew on time keeps climbing while the window shrinks. Getting 99 percent right still leaves the one on a forgotten subdomain, and that is the one your users find. Coverage is the problem, and coverage scales with your footprint.
It Fails in Public
Most outages are invisible until someone measures them. A certificate failure is not. It renders right in the user's browser, in a full-page warning with your hostname sitting in a sentence about attackers and stolen passwords. So it gets screenshotted, it lands on X, DownDetector spikes, and the framing writes itself: this company cannot even keep its own certificate valid. The fix is usually trivial, one cert on one host. The reputational read is "sloppy with security," which is the last thing an infrastructure vendor wants.
The internal story is worse. The failure is client-side, so your servers report healthy the whole time: clean logs, backend up, nothing in your telemetry red. The first real signal is a user's screenshot, which means the internet is your monitoring, and it is not on your side.
Catching It Before the Screenshot
The only reliable check connects from outside and validates the certificate exactly as a browser would. You can spot-check one host in a line:
$ echo | openssl s_client -connect status.example.com:443 \
-servername status.example.com 2>/dev/null \
| openssl x509 -noout -subject -dates -checkend 0 \
&& echo "valid" || echo "EXPIRED or unreachable"
The Mr.DNS SSL certificate checker does the same from a browser after a change. But a manual check only covers the moment you run it, and certificates fail on their own schedule, usually on the host you were not thinking about.
That is the job Generator Labs certificate monitoring does. It connects to every endpoint you list, resolves every IP behind each hostname, and runs a real OpenSSL verification on each: expiration against configurable thresholds, full chain and trust, hostname and SAN matching, revocation, and weak-crypto flagging. It covers HTTPS along with SMTPS, IMAPS, and the STARTTLS variants, so mail and internal endpoints are watched too. When a renewal misses one backend, or a fingerprint changes unexpectedly, the alert reaches your inbox, Slack, or a webhook instead of reaching your users first.
For what an expired certificate actually breaks and how to recover, see what an expired SSL certificate breaks and how to fix it. A near-trillion-dollar company got caught by a certificate on a public host this month, and the only difference between them and everyone else is that theirs made the news. Start monitoring your certificates and let the alert find it before the screenshot does.