SSL Certificates For Fun and Profit

News broke today (October 20, 2026) that several intermediate certificates have been compromised. To the uninitiated this probably sounds like noise, but frankly this impacts the underpinnings of all communications on the Internet, and directly impacts each and every one of us.

This post is intended to do three things:

1. Introduce the topic of how these certificates work so that anyone can understand the basics
2. Describe the issue and the impact that comes out of it
3. Share real world actions that you can take - as either an individual or an organization - to mitigate the issues that come from this event.

SSL 101: How Signing and Encryption Work

This is a topic we've tackled before, but it bears repeating. On the Internet communication between two entities needs to be set up to ensure safe, secure messaging between them. That starts with first ensuring the identity of both parties, and then on encrypting the traffic so that no other parties can see the traffic as it traverses the public Internet. Decades ago we adopted Asymmetrical Encryption as the standard for doing this. That is built on the concept of a public/private key pair, sometimes referred to as a key and a certificate.

Private Key (Key)

The private key is something you keep secret. You use it to sign your encrypted messages as you send them out to others to validate that they came from you. You also use it to decrypt messages coming from others. In some cases these keys are kept on computers with no network connection for the purpose of making it as difficult as possible to compromise them.

Public Key (Certificate)

This is like a business card, you share it with everyone. When someone wants to encrypt a message to you they actually use your public key to do it, so that only you can decrypt it with your private key. Conversely, when someone wants to validate that a message came from you they use your public key to validate the signature on that message.

By themselves these are a powerful pair of files that support safe and secure online communication, however they don't scale well by themselves. The major difficulty is that because all of this happens electronically it is difficult for you to validate that the public key you got from someone is really theirs.

Certificate Authorities

Because of the need to authenticate that the keys for www.google.com really belongs to Google, a group of certificate authorities were created. The idea is that a few root authorities sign the public keys for intermediate authorities, who then sign for customer-level authorities, who in turn sign the individual public keys/certificates for online systems. In this way a computer, phone, browser, etc. only needs to trust a handful of authoritative signing keys which then vouch for the other keys, yet the risk of "all" keys suddenly being suspect is low because of this tree architecture.

As an analogy, think of a certificate authority like that good friend who introduces you to a bunch of new people at a party. That friend vouches for the people they introduce you to, so you trust that they are who your friend says they are.

By the way, we use these keys not just to ensure that communications with websites online, but also for verifying that updates we download for keeping our software up to date are from the authors of that software and not from a third party trying to fake the update signature to install malware on your device.

What Just Happened

So the big news is that eight of those intermediate keys from a certificate authority have been compromised, meaning we can no longer guarantee that public keys signed by those keys are legitimate. In this particular case it seems that the private key was trivial to guess, which means that the good news is that there likely wasn't a "breach," the bad news is that these could have been compromised for ages without anyone realizing because they're so trivial to reverse engineer.

The good news is that there are procedures for addressing this. The bad news is that those processes may temporarily render some websites, applications, and other systems that relied on those intermediate keys for signing to be unavailable, until new certificates are generated with signatures from other intermediate signing authorities.

Again, to put it in human terms, if you find out that your friend who was introducing you to people at that party was an impostor, you will want to find another person who can verify the identities of the people your friend introduced you to. Until that happens you don't trust that the people you met at the party are who they said they were.

Practical Steps To Take

First step: don't panic!

The good news is that you're not likely to get immediately bonked by this, especially if you don't visit "unknown" websites or use unknown services in the next few days, but that doesn't mean you should be complacent either. This is worth addressing quickly and thoroughly.

As with everything in security, strong security means that some things may not work like they used to after you make security changes. The steps below may mean that a few websites/systems you rely on connecting to via the Internet are unavailable for a a short period of time. Trust that the companies that support them are frantically updating their certificates so that they are able to be trusted again ASAP.

For Individuals

1. Update your browser(s) as soon as possible. On most systems that can be done by opening the browser and going to the "About" menu in the browser and choosing "check for updates."
2. Update your system ASAP. Browsers aren't the only thing on your computer that trusts based on certificates and keys. This includes your phones, tablets, etc.
3. Update all your "IoT" devices as well. That's your TV's, Streaming Sticks, Routers, Firewalls...anything connected to your home network.
4. If you encounter an error message about an "invalid" or "revoked" certificate stop what you're doing. Don't proceed unless you're confident that the source is benign.
5. If you write your own code (by hand, vibecoding, etc.) you should really review your code to make sure you haven't hard-coded any certificate/key handling that would prevent your code from properly using system wide certificate/key utilities. (99% of us don't need to worry about this)

For Organizations

1. Enable and maintain a certificate revocation list solution, which can simplify responding to these events in the future if you don't already have one configured.
2. Update all the things.
3. Educate your users on the importance of not "blindly accepting" invalid or revoked certificate messages.
4. Evaluate your own certificates to be sure yours aren't signed by the newly revoked intermediate keys and if they are update them immediately.
5. Evaluate if you have any Go/Golang built apps because apparently those will require recompiling of source code to address these issues.
6. Evaluate all your code to make sure you didn't hard-code certificate/key handling somewhere that won't properly accept a revocation list, or won't use the system-wide tools that can address this issue without your intervention.