When you’re browsing the web, there’s a little lock in the address bar. It means the website’s identity has been verified. Verification relies on digital certificates issued by certificate authorities. Think of it this way: a certificate authority gives a website an ID card and stamps it with a seal whose design is a string of numbers.
One certificate authority had 8 seals with these designs: 4, 56, 66, 115, 155, 156, 230, 237.
The number should normally be more than a hundred digits long. In reality, it’s no more than three digits.
So anyone with a copy of a public certificate could try all 256 possibilities, one by one, and copy the seal in less than a second.
The seal wasn’t stolen. It stayed right where it was; nobody touched the server. The design was just too short.
The person who discovered this used each of the 8 seals to stamp a message and sent it to several browser companies: “We have a problem here—Wayne.” Firefox blocked them three hours later, Google did so that same day, and Apple and Microsoft followed within a couple of days.
These 8 seals were made in April 2025, 18 months apart.
When verifying a certificate, the system only checks whether “the seal is correct.” It never checks whether “the design is long enough and random enough.”
So a seal with a design of 4 gets the same verification result as a genuinely random, long seal: valid.
And there’s no record saying, “This certificate was stamped with a weak seal.” For 18 months, every system showed everything as normal. Debian had the same kind of problem in 2008: something went wrong during generation, and the validation step failed to catch it.
A larger authority also vouched for these 8 seals, doubling the total to 16.
If someone used them to impersonate an exchange or wallet website you use, the lock in your browser would still be green, and the web address would still look right. You wouldn’t know what a person in the middle saw or changed, and nothing would be recorded.
The good news is that these 8 seals haven’t been used to sign certificates for specific websites, and there are no public reports of misuse.
The bad news is that your Docker images, old servers, cameras, and software that doesn’t check whether a certificate has been revoked won’t update themselves. They’ll still trust all 16.
I’m inclined to see this as a systemic problem, not a case of one company slipping up. The audit didn’t catch it because it checked the process.
Will the next person to discover something like this also just happen to be someone who ran the numbers?
One certificate authority had 8 seals with these designs: 4, 56, 66, 115, 155, 156, 230, 237.
The number should normally be more than a hundred digits long. In reality, it’s no more than three digits.
So anyone with a copy of a public certificate could try all 256 possibilities, one by one, and copy the seal in less than a second.
The seal wasn’t stolen. It stayed right where it was; nobody touched the server. The design was just too short.
The person who discovered this used each of the 8 seals to stamp a message and sent it to several browser companies: “We have a problem here—Wayne.” Firefox blocked them three hours later, Google did so that same day, and Apple and Microsoft followed within a couple of days.
These 8 seals were made in April 2025, 18 months apart.
When verifying a certificate, the system only checks whether “the seal is correct.” It never checks whether “the design is long enough and random enough.”
So a seal with a design of 4 gets the same verification result as a genuinely random, long seal: valid.
And there’s no record saying, “This certificate was stamped with a weak seal.” For 18 months, every system showed everything as normal. Debian had the same kind of problem in 2008: something went wrong during generation, and the validation step failed to catch it.
A larger authority also vouched for these 8 seals, doubling the total to 16.
If someone used them to impersonate an exchange or wallet website you use, the lock in your browser would still be green, and the web address would still look right. You wouldn’t know what a person in the middle saw or changed, and nothing would be recorded.
The good news is that these 8 seals haven’t been used to sign certificates for specific websites, and there are no public reports of misuse.
The bad news is that your Docker images, old servers, cameras, and software that doesn’t check whether a certificate has been revoked won’t update themselves. They’ll still trust all 16.
I’m inclined to see this as a systemic problem, not a case of one company slipping up. The audit didn’t catch it because it checked the process.
Will the next person to discover something like this also just happen to be someone who ran the numbers?