DEV Community: Dionisio Cortés Fernández

Eight CA Keys Between 1 and 255: What the eMudhra Incident Means for Your Code

Dionisio Cortés Fernández — Sun, 25 Oct 2026 22:53:55 +0000

Up to date as of 25 October 2026. The fixes are still changing: on 24 October Oracle shipped a second Java fix (CVE-2026-114820), so guidance written before then calls Java builds fixed that aren't. For anything newer, check the incident site's list of patches.

On 17 October 2026 someone signed the sentence "We have a problem here - Wayne" with the private keys of eight intermediate certificate authorities: six trusted for TLS by Chrome, Firefox, Safari and Windows, and two trusted by Windows for code signing. Nobody stole those keys. Nobody had to. Each one was an integer between 1 and 255, so anyone could compute it from the public certificate in less time than it takes to read this sentence.

Chrome and Firefox were protected within hours, Windows and Apple devices within days. Your backend probably wasn't, and the reason says something uncomfortable about TLS outside the browser: trust doesn't live in the protocol, it lives in a file of root certificates that every runtime picks for itself. Patch the OS and you've fixed curl. You haven't fixed Node, a Go binary built last month, or the certifi inside a virtualenv.

Question	Short answer
What was compromised?	8 eMudhra intermediate CAs (6 TLS, 2 code signing) and their 8 Sectigo cross-signs (the same keys, also signed by Sectigo)
What can an attacker do?	Issue a valid certificate for any hostname
What else does the attacker need?	A position on the network path between your client and the server
Who was exposed?	Clients that trust the roots and check neither revocation nor Certificate Transparency: most non-browser TLS
What's the fix?	Update the runtime and its trust store, then rebuild everything that embeds them

One chain runs through the whole article, the real one served by the incident's test host dv-g3b-emudhra.we-have-a-problem.com. We'll look at what a certificate proves, what went wrong with these, what an attacker needs to use them, the before and after on that chain, and how to fix the four runtimes you're most likely to ship: Java, Go, Node.js and Python.

What a Certificate Actually Proves

Definition. A certificate binds a public key to a name, and a signature from someone else backs that binding. That "someone else" is a certificate authority, whose own certificate is signed by another CA, until you reach a root: a certificate nobody signs, which your client trusts because it's in a file called a trust store. The server's own certificate, the one with the hostname in it, is the leaf. The CAs between the leaf and the root are intermediates.

You can print the chain the test host serves:

openssl s_client -connect dv-g3b-emudhra.we-have-a-problem.com:443 -showcerts </dev/null 2>/dev/null | grep -E ' s:| i:'

 0 s:CN=dv-g3b-emudhra.we-have-a-problem.com
   i:C=NL, O=eMudhra BV, CN=EM DV TLS CA - G3B
 1 s:C=NL, O=eMudhra BV, CN=EM DV TLS CA - G3B
   i:C=IN, O=eMudhra Technologies Limited, CN=emSign Root TLS CA - G3
 2 s:C=IN, O=eMudhra Technologies Limited, CN=emSign Root TLS CA - G3
   i:C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign ECC Root CA - G3

s: is who each certificate speaks for and i: is who signed it. The server doesn't send the root; the client has to find it in its own trust store. Drawn as a tree:

dv-g3b-emudhra.we-have-a-problem.com           leaf: "this key speaks for this hostname"
└─ signed by EM DV TLS CA - G3B                intermediate: one of the eight weak keys
   └─ signed by emSign Root TLS CA - G3        intermediate
      └─ signed by emSign ECC Root CA - G3     root: the one in your trust store

During the handshake the server sends the chain, and the client checks three things: every signature verifies with the issuer's public key, every certificate is in date and allowed to do what it's doing, and the chain ends at a root in the client's own trust store. The last check is the only place where trust enters the system. Everything else is arithmetic.

An intermediate's certificate shows how much power it holds. The incident's proof folder has all eight; download one and print its limits:

curl -sSLO https://raw.githubusercontent.com/galadran/we-have-a-problem.com/main/proof/EM-OV-TLS-CA-G3C.crt.pem
openssl x509 -in EM-OV-TLS-CA-G3C.crt.pem -noout -subject -ext basicConstraints,extendedKeyUsage

subject=C=US, O=eMudhra Inc, CN=EM OV TLS CA - G3C
X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
    CA:TRUE, pathlen:0

CA:TRUE, pathlen:0 means it may sign leaves but not further CAs. There's no nameConstraints extension, so nothing limits which hostnames it can back. Whoever holds its private key can sign a certificate for api.your-bank.com, and your client has no way to tell it from a real one. That's why CA keys live in hardware security modules (HSMs: tamper-resistant devices that never let the key out) and why key ceremonies have witnesses.

After the fact, two mechanisms can still save a client:

Revocation. The CA publishes "stop trusting this one" through CRLs (lists of revoked certificates the CA publishes) or OCSP (a service the client asks about one certificate). It works only if the client checks, and most non-browser clients don't by default.
Certificate Transparency (CT). Public, append-only logs where CAs record every certificate they issue, so anyone can see what was issued for a domain. Browsers reject a leaf that hasn't been logged, so a forged certificate either becomes public or gets rejected. Almost nothing outside the browser checks this.

If you remember one thing: a certificate is only as trustworthy as the private key of every CA above it, and the trust store is a file your client chooses, not a property of the internet.

What Went Wrong at eMudhra

A P-384 private key is a random 384-bit number k. The public key is k·G, the curve's base point added to itself k times. Going forward is cheap; going back is the problem P-384's security rests on. Mozilla's analysis in the incident report found that the eight keys were all integers less than 256: 48 bytes, all zero except the last. With 255 candidates, "going back" means computing 255 points and comparing them with the certificate. One write-up measured 28.7 milliseconds for the full table.

You don't need to brute-force anything to check it. One of the keys is already public: the key of EM OV TLS CA - G3C is 4. Using the certificate you downloaded above:

from cryptography import x509
from cryptography.hazmat.primitives.asymmetric import ec

cert = x509.load_pem_x509_certificate(open("EM-OV-TLS-CA-G3C.crt.pem", "rb").read())
four = ec.derive_private_key(4, ec.SECP384R1())   # the private key "4"

print(cert.public_key().public_numbers() == four.public_key().public_numbers())
# True

P-384 isn't broken. A key of 4 is a valid key: it parses, it signs, signatures verify. Every format check and every sign-and-verify test passes, which is exactly why nothing caught it for almost eighteen months.

How it happened, according to eMudhra's preliminary explanation in the report: the keys were generated on Utimaco HSMs during a ceremony on 30 April 2025. An approved deviation added a test of key wrap/unwrap (exporting a key encrypted and importing it back), a flaw in that test code created a second, weaker key pair inside the HSM, and because the labels were similar the weak pair was used for the CSRs (certificate signing requests: the public key and name a CA is asked to sign). The root signed them and Sectigo cross-signed them. Other participants in the report point out that an HSM's certified key generation doesn't produce a scalar below 256 on its own, so how that material got there is still an open question. eMudhra hasn't answered yet; it says its full report will come within the 14 days the rules allow.

What was affected: eight intermediates from that ceremony.

Six sign HTTPS certificates: EM DV TLS CA, EM OV TLS CA and EM EV TLS CA, each in a G3B and a G3C version. All six chain to emSign ECC Root CA - G3.
Two sign code: EM OV CS CA - G3B and EM OV CS CA - G3C. Only Microsoft trusted them.

The names follow a pattern:

DV, OV and EV say how much the CA checks about a customer before issuing. Domain Validated checks only that they control the domain, Organization Validated also checks that their company exists, and Extended Validation adds stricter legal checks.
G3B and G3C are two copies of each CA, issued to two eMudhra companies: every G3B to eMudhra BV in the Netherlands, every G3C to eMudhra Inc in the US.

None of it matters for this incident. The checks are a promise the CA makes, not something the key enforces, so whoever holds any of the six keys can sign for any hostname.

Sectigo's AAA Certificate Services root had cross-signed the same eight public keys (signed them too, so they also chain to Sectigo's root), and a cross-sign with the same key is the same compromise. eMudhra itself issued no end-entity certificates (leaves) from them. Whether anyone else did in the eighteen months before the report, nobody can prove either way for clients that don't check CT.

eMudhra has since announced that it is leaving the public TLS business, and some trust stores now drop more than the one root behind these keys. Java's second update removes all three eMudhra roots the JDK carried, and certifi 2026.10.23 drops two more (eMudhra Inc's emSign Root CA - C1 and emSign ECC Root CA - C3). If a server you call still uses an eMudhra certificate, expect it to fail once you update.

The incident site keeps the authoritative list of who has patched.

If you remember one thing: the keys weren't stolen, they were computable, from public data, by anyone, for almost eighteen months. Treat every client that trusted these roots as if the keys had been public all along, because they effectively were.

Why It's Exploitable, and What an Attacker Still Needs

With an intermediate key, an attacker signs a leaf for whatever hostname your service calls. The chain validates. But a certificate alone does nothing: the attacker has to receive your connection to present it. That means a position on the path:

DNS answers they control (poisoning, a compromised resolver, a hijacked record).
A network device in the middle: a proxy, a router, a hostile Wi-Fi, a compromised egress gateway.
A routing attack (BGP hijacking: announcing the destination's IP addresses from a network the attacker controls, so traffic goes there).

This isn't remote code execution, and nobody can scan the internet with it. It turns a network position, which TLS normally makes harmless, into full read-and-write access to the traffic.

So why were browsers safe and your backend not? Because of the two mechanisms above:

Revocation. eMudhra revoked the intermediates on 18 October. Python, Node, curl and Go on Linux don't check revocation by default, and neither does Java's TLS stack unless you set com.sun.net.ssl.checkRevocation=true. (Go on macOS and Windows asks the OS verifier, so it picked up Apple's and Microsoft's blocks.)
Certificate Transparency. No certificate signed by these intermediates appeared in the public CT logs before the block. A browser rejects unlogged certificates, so a forgery would have had to show up in public first. Non-browser clients don't check CT, so for them a forged certificate needs no log entry at all.

Browsers also receive blocklists pushed by the vendor (Chrome's CRLSet, Firefox's OneCRL) without a software update. Your runtime gets nothing until you upgrade it.

Forged certificates stopped being hypothetical on 20 October. Over the next day and a half, people logged 107,107 of them, signed with six of the keys, to public CT logs: 106,050 are proof-of-concept certificates for google.com, and every signature verifies. All but two carry no revocation pointer (the CRL or OCSP address a client would ask), so a client that checks revocation only for the leaf, a common setup, finds nothing to check. Only a client that checks every CA in the chain, receives a pushed blocklist or has dropped the roots rejects them.

What that means for a typical service:

Your code talks to…	Exposure	Why
Internal services, with a trust store holding only your private CA	None	The eMudhra roots are never consulted
Internal services, with the default trust store	Low	The attacker must already be inside your network
External APIs, SaaS, your cloud provider's endpoints	Real, needs a man-in-the-middle	The path crosses networks you don't control
Package registries from CI or laptops	Unlikely, high impact	A forged registry can serve a tampered package into every build
Browsers	None	Pushed blocklists and CT

Note the second row. "We only call internal services" protects you only if the client trusts only internal CAs. Most services keep the default trust store and append their private CA to it, so a forged certificate for orders.internal still validates. It's just much harder to deliver.

If you remember one thing: the key is the weapon and the network position is the trigger. Your risk is how many networks you don't control sit between your clients and the servers they call.

Before and After

The incident site runs test hosts that serve the compromised chains. Run the check from where your code runs, a pod, a container or a CI job, not from your laptop:

curl -sS -o /dev/null -w '%{http_code}\n' https://dv-g3b-emudhra.we-have-a-problem.com/      # eMudhra root
curl -sS -o /dev/null -w '%{http_code}\n' https://dv-g3b-aaa-emudhra.we-have-a-problem.com/  # Sectigo cross-sign

# Before: the client trusts the compromised intermediate
200

# After: trust removed (wording depends on curl's TLS backend; this is OpenSSL)
curl: (60) SSL certificate problem: unable to get local issuer certificate

Two more hosts serve leaves that were never logged to CT:

curl -sS -o /dev/null -w '%{http_code}\n' https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

A 200 here is the worst result: your client trusts the compromised intermediates and doesn't enforce CT, so it could be attacked without anything ever appearing in a public log.

curl only tests curl's trust store. Your service uses its runtime's, so the companion script runs the same request through curl, Python, Node, Java and Go, whichever are installed.

Before you run it at work. Each check opens one HTTPS connection to a test host. The incident site runs them; Oracle and OpenJDK link to it, and its source is on GitHub. The hosts see what any website sees: your public IP, the hostname and the time. curl, Python, Node and Go send a plain GET /, and the Java probe stops after the TLS handshake. A host your client trusts answers with one line of text, which the scripts throw away. On a company network, three things matter:

A connection that presents a certificate from a revoked, compromised CA is exactly what a security proxy or intrusion detection system should flag. Tell your security team before you run it.
If a proxy inspects TLS, your client checks the proxy's certificate instead of the test host's, so the result tells you nothing about your runtime.
Proxies often block newly registered domains. That shows up as ERROR, which proves nothing either way.

If you can't make the call, the offline check below and Probe --roots in the Java section need no connection to the test hosts.

Offline, with no network at all. The site also publishes every chain as PEM (the text format that starts with -----BEGIN CERTIFICATE-----), so you can check a trust store file directly. Here is the same chain against certifi before and after the fix:

$ openssl verify -CAfile certifi-2026.7.22.pem -untrusted chain.pem chain.pem
chain.pem: OK

$ openssl verify -CAfile certifi-2026.10.19.pem -untrusted chain.pem chain.pem
C = IN, O = eMudhra Technologies Limited, CN = emSign Root TLS CA - G3
error 20 at 2 depth lookup: unable to get local issuer certificate
error chain.pem: verification failed

OK means the bundle still trusts the compromised intermediate. Error 20 at depth 2 means the chain now dead-ends one step before the root: emSign ECC Root CA - G3 is gone from the bundle. The Sectigo chain (dv-g3b-aaa) fails against both versions, because certifi doesn't carry AAA Certificate Services at all. That cross-sign path matters for stores that do: Windows, the /etc/ssl/cert.pem macOS ships, and the Linux stores the incident site gives workarounds for.

If you remember one thing: test with the runtime your service uses, from where it runs. A green curl on your laptop says nothing about a Node container in production.

Why Every Runtime Needs Its Own Fix

Each runtime answers "which roots do I trust?" differently, so each one got a different fix:

Runtime	Where its roots come from	What the fix does	Fixed in	CVE
Java	The JDK's `lib/security/cacerts`; distro packages link it to the OS store	Distrusts the intermediates through `blocked.certs`, then removes four roots from `cacerts`	24 Oct updates	CVE-2026-91403, CVE-2026-114820
Go	The OS store on Linux; the OS verifier on macOS and Windows	A hardcoded blocklist in `crypto/x509`, compiled into your binary	1.26.10, 1.27.3	CVE-2026-111943
Node.js	Mozilla's bundle, compiled into the `node` binary	NSS 3.131.1 roots, and rejects chains with the blocked public keys	22.23.4, 24.22.1, 26.12.1	none
Python (`ssl`, `urllib`)	The OS store	Whatever your distro's `ca-certificates` does	Your distro's package	none
Python (`requests`, pip, many libs)	`certifi`, a bundle inside each virtualenv	Drops `emSign ECC Root CA - G3`	certifi 2026.10.19, pip 26.2.2, uv 0.13.5	none
curl, git, OpenSSL	The OS store	Drops the root	e.g. Ubuntu `20260816ubuntu0.24.04.1`	none

Go's fix is a list of the eight compromised public keys (their SHA-256 hashes) in crypto/x509, and Verify rejects any chain that contains one of them. Blocking by public key rather than by certificate is the right call: the eMudhra certificate and the Sectigo cross-sign carry the same key, so one entry covers both. And because the list is part of the standard library, it ends up inside every binary you build. Upgrading the Go installed on a server changes nothing for a binary that's already compiled: you have to rebuild it with 1.26.10 or 1.27.3.

Two consequences are easy to miss:

"Update the OS" is not a fix for Node or certifi. Neither reads the OS store by default. For Go on Linux it helps, because it drops the root, but the blocklist only arrives with a rebuild.
Your CVE scanner won't flag Node or Python. Neither fix has a CVE, so a scanner that matches CVEs to versions reports them clean. Check those two by version. For Java, make sure the scanner knows CVE-2026-114820: against the first CVE alone, the 21 October builds look fixed.

If you remember one thing: ask of every process, "where does this get its roots, and who updates that file?" The answer is different for each runtime, and sometimes it's "a file compiled into a binary you built last month."

Fixing It, Runtime by Runtime

Java

Oracle shipped two fixes three days apart, and only the second one is enough. Both score 9.1 and cover Java SE 8, 11, 17, 21, 25 and 27, GraalVM for JDK 17 and 21, and GraalVM Enterprise Edition 21.3.

CVE-2026-91403, 21 October: distrusts the eight intermediates and their eight Sectigo cross-signs through blocked.certs. Oracle's builds 11.0.33.0.2, 17.0.21.0.2, 21.0.13.0.2, 25.0.5.0.2, 27.0.1.0.2 and 8u511 b32.
CVE-2026-114820, 24 October: also removes four roots from cacerts: emSign ECC Root CA - G3, emSign Root CA - G1, emSign Root CA - G2 and Sectigo's AAA Certificate Services. It lists the 21 October builds as affected. Oracle's fixed builds are 11.0.33.0.3, 17.0.21.0.3, 21.0.13.0.3, 25.0.5.0.3, 27.0.1.0.3 and 8u511 b33. Java 8 keeps the update number and bumps the build, so java -version has to say 1.8.0_511-b33.

Only the first and the last of those roots are behind the compromised chains; the JDK drops eMudhra's other two as well.

Update the JDK in every place it lives: Docker base images, setup-java in CI, self-hosted runners, laptops. For Docker, rebuild your own image with docker build --pull so it starts from the updated base. Redeploying an image you already built, or giving it a new tag, keeps the old JDK inside it. Other vendors (Temurin, Corretto, Zulu and the rest) number their builds differently. OpenJDK's eMudhra page, last updated on 24 October, says to look for JDK-8395690 / CVE-2026-114820 in your vendor's release notes, "even if you have updated your runtime in the past few days". It also publishes CheckCerts.java, which prints BAD ROOT for each of the four roots a runtime still trusts.
Base images lag behind vendor releases. On 25 October, three days after Temurin's October builds came out, the official eclipse-temurin:21-jre, 21-jre-alpine and 25-jre-alpine images still shipped 21.0.12.1 and 25.0.4.1, and Probe (below) still saw them trust the test hosts. Until the image you build on is updated, --pull changes nothing: check the result, don't assume it.
If your vendor hasn't shipped the fix yet, remove the four roots yourself, then restart the JVM. OpenJDK's page deletes them by alias, but alias names differ between vendors (Temurin calls the first one cn_emsign_ecc_root_ca__g3,o_emudhra_technologies_limited,ou_emsign_pki,c_in [jdk]), so find them by subject instead:

  keytool -list -v -cacerts -storepass changeit \
    | awk '/^Alias name: /{a=substr($0,13)} /^Owner: .*CN=(emSign Root CA - G[12]|emSign ECC Root CA - G3|AAA Certificate Services)(,|$)/{print a}' \
    | while IFS= read -r a; do keytool -delete -cacerts -storepass changeit -alias "$a"; done

It prints nothing when it works, and nothing when there's nothing to delete. To see what it will remove, run the first two lines on their own: they print the aliases that match. On eclipse-temurin:21-jre:

  cn_emsign_ecc_root_ca__g3,o_emudhra_technologies_limited,ou_emsign_pki,c_in [jdk]
  cn_emsign_root_ca__g1,o_emudhra_technologies_limited,ou_emsign_pki,c_in [jdk]

Run them again afterwards: no output means the roots are gone. Deleting needs write access to cacerts, so a system JDK needs sudo; without it, keytool stops with Permission denied.

changeit is the default password of the JDK's cacerts. Java 8's keytool has no -cacerts option, so replace it with -keystore and the file: $JAVA_HOME/jre/lib/security/cacerts in a JDK, $JAVA_HOME/lib/security/cacerts in a JRE. A vendor's cacerts doesn't always hold all four (Temurin's has emSign Root CA - G1 and emSign ECC Root CA - G3 only), and the command deletes whichever it finds. Whether you update or remove them by hand, servers that chain to AAA Certificate Services or to eMudhra's other roots stop working, so test the hosts you call before rolling it out.

In a Docker image, the keystore is baked into the image, so the removal goes in your Dockerfile, after the FROM:

  FROM eclipse-temurin:21-jre
  RUN keytool -list -v -cacerts -storepass changeit \
      | awk '/^Alias name: /{a=substr($0,13)} /^Owner: .*CN=(emSign Root CA - G[12]|emSign ECC Root CA - G3|AAA Certificate Services)(,|$)/{print a}' \
      | while IFS= read -r a; do keytool -delete -cacerts -storepass changeit -alias "$a"; done

To check an image on your machine, ask the Java inside it. The companion's Probe.java connects to the test hosts through the JVM's own TLS stack, so it sees what your application sees: the image's cacerts, the blocked.certs fix and any trust store the image configures. The version string can't tell you that, least of all for a company's own JDK build. Compile it once with javac --release 8 Probe.java, then run it with the image's Java (8 or later; a JRE is enough):

  docker run --rm --entrypoint java -v "$PWD:/probe:ro" my-image -cp /probe Probe

Any TRUSTED line means the image is still exposed. --entrypoint makes this work even when the image starts your application by default, and settings in its ENV, such as JAVA_TOOL_OPTIONS, still apply. If the start script passes -Djavax.net.ssl.trustStore=… instead, add the same flags after my-image. On your laptop, java -cp . Probe does the same for your own JDK.

Company images: only your CAs, or the public roots too? The answer tells you which row of the exposure table above you're in. Probe --roots lists every root the image's Java trusts, and it needs no network:

  docker run --rm --entrypoint java -v "$PWD:/probe:ro" my-image -cp /probe Probe --roots

  /opt/java/openjdk 21.0.12.1+1-LTS, trustStore=/opt/corp/truststore.p12
       CN=ACME Corp Root CA,O=ACME
  1 trusted roots: 0 BAD (behind the compromised chains), 0 DROP (also removed by the 24 October fix)

That image trusts one private root and nothing else. The stock eclipse-temurin:21-jre lists 118 roots, including:

  BAD  CN=emSign ECC Root CA - G3,O=eMudhra Technologies Limited,OU=emSign PKI,C=IN
  DROP CN=emSign Root CA - G1,O=eMudhra Technologies Limited,OU=emSign PKI,C=IN

BAD marks a root behind the compromised chains. DROP marks eMudhra's other two roots: they aren't compromised, but the 24 October fix removes them too, and OpenJDK's CheckCerts flags them as well. Either label makes Probe exit with 1. On a fixed JDK no line is labelled, the summary reads 0 BAD …, 0 DROP …, and Probe exits with 0; the number of roots varies by vendor and doesn't matter. Ask Java rather than reading the trust store file with keytool: a PKCS12 file (the standard keystore format, Java's default since 9) protected by a password lists no entries without that password, so it looks empty when it isn't. Java gets the password from the image's own settings.

This covers Java only. curl, git, Python's ssl module and Go read the OS bundle (/etc/ssl/certs/ca-certificates.crt on Debian, Ubuntu and Alpine), and company images often add their CA to it rather than replace it. docker create lets you copy it out without starting anything:

  id=$(docker create my-image) && docker cp -L "$id":/etc/ssl/certs/ca-certificates.crt . ; docker rm "$id"
  openssl crl2pkcs7 -nocrl -certfile ca-certificates.crt | openssl pkcs7 -print_certs -noout | grep '^subject'

Know which cacerts you use. readlink -f "$JAVA_HOME/lib/security/cacerts" tells you. JDK packages on Fedora, RHEL, Arch, Gentoo and Oracle Linux read the OS store, so updating ca-certificates is likely enough there. Homebrew's and FreeBSD's OpenJDK carry their own cacerts, so upgrade the JDK package itself: brew upgrade openjdk, not brew update, which only refreshes Homebrew's list of packages. On 25 October only Homebrew's openjdk (27.0.1.0.3) had the 24 October fix. openjdk@21 (21.0.13.0.2) still trusted all four roots, and the other versioned packages were at the same or older builds, so remove the roots by hand there. On Debian and Ubuntu, cacerts points to /etc/ssl/certs/java/cacerts, and a long-standing bug means updating ca-certificates doesn't reach it. Regenerate it as root:

  rm -f /etc/ssl/certs/java/cacerts
  update-ca-certificates --fresh

Embedded JREs. Jenkins, Kafka, Elasticsearch, IDEs and many vendor appliances ship their own Java. Updating the system JDK doesn't touch them, so update the product.
Revocation checking instead of removing the roots. OpenJDK and Oracle both accept -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true as the alternative. Java checks every certificate in the chain, not just the leaf, so it also rejects the forged certificates that carry no revocation pointer: with those two flags after my-image, Probe rejects all four test hosts even on an unpatched eclipse-temurin:21-jre. It costs you a CRL fetch on new chains and can fail handshakes when a CRL endpoint is unreachable. eMudhra's CRL and OCSP servers have also been refusing curl's, Wget's and Python's User-Agents (Java's got through on 25 October), so test it before rolling it out. For signed JARs, JDK 17 and later can check revocation with jarsigner -verify -revcheck -strict app.jar.
If you can't update yet, Oracle also publishes a replacement blocked.certs for lib/security/ (on Java 8 the file is blacklisted.certs). It covers only the first CVE, so remove the roots as well.

Go

See what a binary was built with, not what's installed: go version ./bin/my-service prints the toolchain embedded in the file.
Rebuild with 1.26.10 or 1.27.3 and redeploy. Pin it where your build reads it: a toolchain go1.26.10 line in go.mod, go-version in setup-go, the golang: builder image. Go 1.25 and older get no fix.
Rebuild the runtime image too. On Linux, Go still reads the OS store, so a distroless or alpine base from last month keeps the old roots until you pull a new one.

Node.js

Check what your node trusts, from the container that runs it:

  node -e "const {X509Certificate}=require('crypto');
    const hit=require('tls').rootCertificates.some(p=>new X509Certificate(p).subject.includes('emSign ECC Root CA - G3'));
    console.log(process.version, hit ? 'STILL TRUSTS emSign ECC Root CA - G3' : 'root removed')"
  # v22.22.0 STILL TRUSTS emSign ECC Root CA - G3

Upgrade to 22.23.4, 24.22.1 or 26.12.1 everywhere you pin a version: .nvmrc, engines, setup-node, the node: base image, Lambda runtimes. These releases also fix other CVEs, including a Brotli out-of-bounds write (CVE-2026-111497), so they're worth taking anyway.
Node 20 and older get nothing. Node 20 reached end of life in April 2026.
Mind the flags. NODE_EXTRA_CA_CERTS only adds roots, it never removes one. --use-system-ca and --use-openssl-ca switch Node to the OS store, which makes the OS package part of your fix.
Electron, Bun and Deno bundle their own roots and released their own fixes.

Python

Check every environment, not the interpreter: python -c "import certifi; print(certifi.__version__)" inside each virtualenv, image and lambda.
Pin certifi>=2026.10.19 and regenerate your lockfile so the pin actually lands. Upgrade pip to 26.2.2 or later and uv to 0.13.5 or later. uv ships its own roots, so it needed its own fix: 0.13.4 removed the root and 0.13.5 also rejects chains that carry the compromised keys.
New Python releases don't fix old virtualenvs. 3.15.1, 3.14.9 and 3.13.17 bundle a newer pip for new installs. Existing environments keep whatever certifi they had.
Look for vendored bundles. Some libraries ship a .pem inside the package and ignore both the OS and certifi: find .venv -path '*site-packages*' -name '*.pem' lists them.
Code that uses ssl or urllib directly follows the OS store, so it's fixed by ca-certificates.

The OS and Your Images

Update ca-certificates on hosts and in images. Patched versions include Debian 20250419~deb12u2 / 20250419+deb13u1, Ubuntu 20260816ubuntu0.24.04.1 (and its 22.04, 26.04 and 26.10 equivalents), Alpine 20261020-r0 and Fedora 2026.2.92_v9.0.319.
Rebuild, don't just redeploy. An image keeps the trust store it was built with. Images pinned by digest or built from a cached layer never pick up the fix. docker build --pull and check: docker run --rm my-image dpkg -l ca-certificates (or apk info -v ca-certificates on Alpine).
macOS has no ca-certificates package. Safari, Mail and apps built on Apple's frameworks already block these certificates: Apple pushes that change to devices without an OS update. The command-line tools that ship with macOS (curl, git, python3, ruby, perl, openssl) read /etc/ssl/cert.pem instead, which keeps the root until a future macOS update. Apple's note and the incident site give the commands to remove it yourself; a macOS update may put it back. The built-in pip3 uses its own, older copy of the roots, and the incident site shows how to point it at the fixed file. Tools installed with Homebrew use Homebrew's own bundle: brew upgrade ca-certificates.

CI/CD and Your Dependencies

The CI risk is a forged registry serving a tampered package. TLS was the only thing standing between your build and that package, unless something else checks the content:

Ecosystem	Content check that survives a broken TLS
Go	`go.sum` plus the checksum database, whose signing key ships inside `go` itself
npm	`integrity` hashes in `package-lock.json`, when installing with `npm ci`
Python	`pip install --require-hashes`, or `uv.lock`
Gradle	Dependency verification metadata (`--write-verification-metadata sha256`)
Maven	Checksums travel over the same connection and PGP isn't checked by default, so nothing, out of the box

A job that resolves dependencies from scratch, without a lockfile, trusts TLS and nothing else.

Managed Runtimes

On AWS Lambda, a function on a managed runtime in Auto update mode gets the patched runtime once AWS publishes one, rolled out in phases. Function update mode only updates when you deploy the function, container images need a rebuild, and anything still on nodejs20.x won't be patched at all. The INIT_START line in the function's logs shows the runtime version it started with.

The Checklist

Inventory every runtime and version per service: Dockerfiles, CI workflows, go.mod, .nvmrc, requirements*.txt, lockfiles, Lambda configs.
Java: JDK at a 24 October build (release notes list JDK-8395690) in images, CI, runners, laptops and embedded JREs, or the four roots removed (or revocation checking on), and Probe rejecting all four test hosts.
Go: every deployed binary rebuilt with 1.26.10 or 1.27.3 (go version ./binary).
Node.js: 22.23.4, 24.22.1 or 26.12.1 everywhere; nothing left on Node 20.
Python: certifi>=2026.10.19 in every environment, pip ≥ 26.2.2, uv ≥ 0.13.5, lockfiles regenerated, vendored .pem files reviewed.
OS: ca-certificates updated on hosts and in base images; images rebuilt with --pull; on macOS, /etc/ssl/cert.pem fixed by hand until Apple's update.
Custom trust stores: any -Djavax.net.ssl.trustStore, REQUESTS_CA_BUNDLE, SSL_CERT_FILE or bundled .pem checked for emSign ECC Root CA - G3.
Third-party software: agents, appliances, backup tools and anything else that makes its own TLS connections, checked against its vendor's notice.
CI: dependency verification on (lockfiles with hashes, Gradle verification metadata).
Verify from where the code runs: the test hosts reject, including the noct ones.
Don't stop at the scanner: Node and Python have no CVE for this.

Trust Is a File You Ship

Here's the whole article as two questions to ask of any process that opens a TLS connection:

"Where does this get its roots?" The OS store, a bundle inside the runtime, a package in the virtualenv, a list compiled into the binary. If the answer is "I don't know", that's the finding.
"Who updates that file, and when do I pick it up?" Your distro, your runtime's release, your lockfile, your next build. Anything that answers "the next build" is only fixed once you build.

None of this is new. DigiNotar in 2011 and the Symantec distrust in 2018 taught the same lesson, and browsers answered it with pushed blocklists and Certificate Transparency. Most server-side clients got neither. Until they do, the trust store is a dependency like any other: it has versions, it goes stale, and it ships inside your artifacts whether you think about it or not.

The check script lives in the companion folder: it sends the same request to the four test hosts through curl, Python (ssl and certifi), Node, Java and Go, whichever are installed, and prints which ones still trust the compromised chains. The chains and the proof certificates used above come from the incident site's repository.

SOLID Without the Acronym: It's Just Cohesion and Coupling

Dionisio Cortés Fernández — Mon, 14 Sep 2026 20:15:56 +0000

SOLID isn't really five independent principles. It's mostly two long-standing design ideas, wearing five names.

High cohesion — keep the things that change together, together.
Low coupling — depend on stable abstractions, not volatile details.

Four of the five letters are named consequences of those two forces, and the fifth comes with an asterisk. Here's the first cut:

Force	Principles
Cohesion	SRP, ISP
Coupling	OCP, LSP, DIP

It's only a first cut. ISP is contested: the textbook files it under coupling, and its section shows why both readings are right. LSP is the asterisk. It sits under coupling because callers couple to the base contract, never to your subtype, but it isn't a dial you can turn too far. It's a correctness constraint, which makes it a detector rather than a design choice.

Once you see the two forces, you stop memorizing and start deriving, including when not to apply each letter. Every one of them has a cost, and SOLID applied without judgment produces its own kind of unmaintainable code.

Every example lives in one system, the checkout slice of a payments product: CheckoutService.checkout(cart) prices the cart, charges a payment method through a gateway, records the order and returns a result. The domain forces each principle, and you'll watch them repair each other. For each one: what it means, where it shows up, and what over-applying it costs.

S — Single Responsibility

Definition. A class should have one reason to change. The version that actually helps: one reason to change means one actor, one group of people who can ask for that change.

Here the broken version is a CheckoutManager with total() and renderReceipt(). It feels like one thing ("checkout"), but total() answers to Finance, which runs a 10% loyalty discount, and renderReceipt() answers to Marketing, which runs a points program and prints the lines that earned points. Both programs cover the same lines today, so they share one helper. Two actors, two reasons to change, one class: that's the smell.

class CheckoutManager(private val cart: Cart) {

    fun total(): Money =                             // answers to Finance
        cart.items.sum() - loyaltyDiscount()

    fun renderReceipt(): LoyaltyReceipt =            // answers to Marketing
        LoyaltyReceipt(cart.id.value, total(), rewarded = rewardedItems())  // "points earned on…"

    private fun loyaltyDiscount(): Money =           // Finance's discount...
        rewardedItems().sum() / 10                   // 10% back on rewarded items

    private fun rewardedItems(): List<Line> = ...    // ...and Marketing's points: one list, the trap
}

Here's how it goes wrong. Finance asks you to stop discounting gift wrap. A developer edits rewardedItems(), the obvious place, and Marketing's receipt silently stops listing gift wrap under "points earned on," which nobody in Marketing asked for. The total moves exactly as Finance wanted (a smaller discount, every item still charged), so the diff looks correct. Review misses it: the class has one name and one obvious topic, but that private helper couples two departments.

The fix is a split you already know. In a layered app the controller changes with the API shape, the service with a business rule, the repository with storage: three reasons, three classes. Here the same instinct fires inside the service layer: PriceCalculator for Finance, ReceiptFormatter for Marketing, CheckoutService for the flow.

Each class gets its own copy of "which lines count": Finance's skips gift wrap, Marketing's doesn't. DRY says merge them, but they're two actors' rules that merely agreed for a while, and merging them is what caused the bug. Martin calls this accidental duplication: code that looks the same but changes for different reasons isn't really duplicated. SrpTest pins both behaviors: the smell's one edit moving discount and receipt, and the split's two rules disagreeing. Whenever "who asks for changes to this?" gets two answers, you're looking at two classes wearing one name.

The trade-off. Fowler's Refactoring names both failure modes as smells. Under-apply SRP and you get the god class and its symptom, divergent change: one class edited for many unrelated reasons. Over-apply it and you get shotgun surgery: one logical change spread across ten tiny files, because you scattered things that change together. The dial is cohesion. Split by "these change for different reasons," never by "this method feels different."

If you remember one thing: SRP is the cohesion force. Too little separation and you get the god class; too much and you get shotgun surgery. The question is never "how small can this class be," it's "do these parts change for the same reason?"

O — Open/Closed

Definition. A class should be open for extension, closed for modification: you add behavior by adding a class, not by editing an existing, tested one. The enemy is the if/else that grows a branch with every new payment method:

// Every new payment method = reopen this function and risk the branches already here.
fun charge(type: String, amount: Money): PaymentResult {
    if (type == "card") {
        ...
    } else if (type == "paypal") {
        ...
    } else if (type == "bizum") {
        ...
    }   // <- edit working code, again
    ...
}

Polymorphism buys you OCP: depend on an abstraction, and add an implementation instead of a branch.

interface PaymentMethod {
    fun charge(order: OrderId, amount: Money): PaymentResult
}   // closed

class CardPayment : PaymentMethod { ... }
class PaypalPayment : PaymentMethod { ... }
class BizumPayment : PaymentMethod { ... }        // adding one = a NEW file

New behavior is now a new file, almost. Something still maps "bizum" to BizumPayment, and you'll add that line; here it's PaymentMethodRegistry, wired in the composition root at the end. OCP doesn't delete the choice, it concentrates it: out of tested business logic, into one registration line with no logic to break. Closed for modification never meant "zero edits anywhere," only "no edits where the behavior lives."

That pays off because the axis of variation was known: you expected new payment methods. Where the opposite holds, you want the opposite tool.

The inverse case: closed variation. PaymentResult is what checkout() and every PaymentMethod.charge() return:

sealed interface PaymentResult
data class Approved(val txn: TxnId, val amount: Money) : PaymentResult
data class Declined(val reason: String)               : PaymentResult
data object Timeout                                   : PaymentResult
data class Conflict(val reason: String)               : PaymentResult   // paid already, other terms

fun record(result: PaymentResult) = when (result) {
    is Approved -> ...
    is Declined -> ...
    Timeout     -> ...
    is Conflict -> ...  // add a variant → this 'when' stops compiling
}

OCP wants a new variant to touch nothing. A sealed type wants a new variant to break every exhaustive when at compile time, because for a closed set you own, like an order's states or a payment's outcomes, a silently unhandled case is the bug. Only an exhaustive when gets that protection: an else branch opts out, and so does an if (result is Approved). That's why CheckoutService, which decides whether an outcome leaves an order behind, decides with a when. (Java has the same pair: sealed types in 17, JEP 409, and the exhaustive pattern switch in 21, JEP 441.)

Payment methods are an open set anyone may extend: OCP and a registry. Payment results are a closed set you define: a sealed type. One domain, both answers; choosing per axis is the judgment. The trade even has a name, the expression problem (Philip Wadler, 1998): an open interface makes a new variant cheap and a new operation expensive, because every implementation has to grow the method, and a sealed type flips both. The LSP section shows the expensive direction, when refund gets bolted onto every PaymentMethod.

The trade-off. OCP up front is indirection on a guess: premature abstraction (YAGNI). You get an interface with one implementation forever, a plugin system for plugins that never arrive, and readers chasing the interface to find where the work happens. Wait for the second case: that's when OCP starts paying for the indirection instead of just charging you for it.

If you remember one thing: OCP is a coupling principle. It decouples what varies (the implementations) from what's stable (the code that uses them). Add a class, don't edit one. But don't add the interface before the second thing needs it, and when the set is closed, invert the whole idea and let a sealed type break every exhaustive when on purpose.

L — Liskov Substitution

Definition. A subtype must be usable anywhere its base type is expected, through a base reference, with no surprises (Liskov & Wing's behavioral subtyping, 1994). The reframing that matters: extends isn't a code-sharing mechanism, it's a published claim, "every promise the parent makes, I keep."

The expensive promises aren't in method signatures. They're properties that hold for an object's whole lifetime, like "balance is never negative" or "the captured amount never exceeds the authorized amount." Callers assume them without checking, which is their whole value and why breaking one costs so much. Broken promises come in two forms, and they fail in opposite ways.

Form 1 — the silent wrong answer. Our system can issue store credit (it's where gift-card refunds land, as you'll see):

open class StoreCredit {
    protected var credit: Money = Money(0)   // the promise: credit >= Money(0), always
    fun balance(): Money = credit            // the promise, observable by every caller
    fun topUp(amount: Money) {
        require(amount >= Money(0))          // every way in guards the promise
        credit += amount
    }
    open fun redeem(amount: Money) {
        require(amount >= Money(0))
        if (amount > credit) throw InsufficientCreditException()
        credit -= amount
    }
}

class VipStoreCredit : StoreCredit() {       // "let VIPs spend past their balance"
    override fun redeem(amount: Money) {
        require(amount >= Money(0))          // same guard as the parent...
        credit -= amount                     // ...but the promise is gone: no exception, just debt
    }
}

Callers written against StoreCredit assume balance() never goes negative, after any sequence of calls: reconciliation, the balance the app shows, the liability line Finance reports. Hand them a VipStoreCredit and they're all wrong at once, with no exception, no crash, and not one changed line of their code. Quietly incorrect is the expensive kind of wrong.

The guards matter too. topUp and redeem refuse negative amounts, and Money throws on overflow instead of wrapping. Without them, a plain StoreCredit could go negative by itself, and the example would blame inheritance for the parent's own bug. The subclass keeps the guard, so breaking the balance promise is the only thing it does wrong.

Form 2 — the loud refusal. Checkout grows refunds, and in this product gift cards can't take them (a business rule of this example, not of payments in general). The obvious move widens the strategy for everyone:

interface PaymentMethod {
    fun charge(order: OrderId, amount: Money): PaymentResult
    fun refund(txn: TxnId)                    // widened for everyone
}

class GiftCardPayment : PaymentMethod {
    override fun charge(order: OrderId, amount: Money): PaymentResult {
        ...
    }   // fine
    override fun refund(txn: TxnId) =
        throw UnsupportedOperationException("gift cards cannot take refunds")
}

val method: PaymentMethod = registry.resolve("giftcard")
method.refund(txn)                            // boom — at runtime, in prod, on refund day

The type promises something the object refuses to do, and the refusal arrives at runtime instead of compile time. At least it announces itself. Throwing isn't the violation on its own: a contract that allows refusal is kept by refusing. This one promised refunds to every caller, so the refusal breaks it. The fix is to stop claiming the contract:

interface PaymentMethod {
    fun charge(order: OrderId, amount: Money): PaymentResult
}
interface RefundableMethod : PaymentMethod {
    fun refund(txn: TxnId)
}

RefundableMethod extends PaymentMethod in the only safe direction: a method that can also refund keeps every promise a charge-only view makes, never the reverse. Gift cards implement only PaymentMethod, so there's no refund on them to call and nothing to throw.

In the repo, that fix carries real weight:

Refunds enter by order. The order knows which method took the money and which transaction to reverse, so nobody can pair a card's refund with a gift card's charge.
The capability is asked, not assumed. Methods arrive by name, so one question stays at runtime: can this one refund? PaymentMethod.refundable() promises only an answer, and null keeps that promise; RefundableMethod answers with itself. That names a contract, not a class, unlike the is GiftCardPayment patch below, so a new refundable method touches nothing.
It survives wrappers. An as? RefundableMethod stops at a PaymentMethod by inner wrapper, quietly turning every card refund into store credit. by forwards the question to the card inside.
Gift cards settle in store credit. A gift-card order comes back NotRefundable, and SupportCreditFlow issues store credit instead: the class whose promise you just watched a subclass break.
Each order settles once. The order records its settlement, so a second press of the refund button answers AlreadySettled and moves no money.

What repaired the broken contract was segregating the interface, which happens to be the next letter. The principles aren't five separate rules; they repair each other.

The trade-off. LSP isn't a dial: nothing is "too substitutable," and it can only be kept or broken. Keeping it has a price, and the price lives in the contract. You can weaken the base contract until every subtype can keep it, as java.util.Collection does: its Javadoc marks add and remove as optional operations that may throw UnsupportedOperationException, so an unmodifiable list keeps the contract by refusing, and every caller handles a refusal the type allows. Or you keep the contract strong and split it, as RefundableMethod did, and pay in interfaces: ISP's explosion. Weaker promises or more types: that's the real dial.

What LSP rules out is the third option, patching the caller. if (method is GiftCardPayment) skipRefund() fixes the wrong answer by breaking OCP, so now two principles are broken instead of one. That's LSP's real job in your toolbox: it detects bad inheritance. When a tempting IS-A can't honor the full contract, stop inheriting. Narrow the contract until every implementation can keep it, or hold the object in a field instead of extending it.

If you remember one thing: LSP is a coupling principle. Callers couple to the base contract, and every subtype must be safe behind it. No surprises through a base reference. It's not a dial, it's a detector: when IS-A can't keep the contract, don't inherit. The dial it leaves you is in the contract itself: weaker promises or more types.

I — Interface Segregation

Definition. No client should be forced to depend on methods it doesn't use. The key word is client: you segregate by role, one interface per kind of caller, not by chopping an interface into pieces. Ask "who calls this, and which slice do they actually need?", never "how many methods is too many?"

// One implementation may serve every role...
class StripePaymentGateway : PaymentGateway, PaymentReader { ... }

// ...but each client sees only the contract its role needs.
interface PaymentGateway {                        // the role that moves money
    fun charge(req: ChargeRequest): PaymentResult
    fun refund(txn: TxnId)
}
interface PaymentReader {                         // the role that looks at it
    fun transactions(range: DateRange): List<Txn>
}

class StatementsScreen(private val payments: PaymentReader) { ... }                // can't move money
class CardPayment(private val gateway: PaymentGateway) : RefundableMethod { ... }  // can't read statements

The implementation didn't split; the view of it did, and the benefits are concrete:

The statements screen has no charge or refund in scope, so it can't move money by accident. That narrows access rather than proving it (a cast could still reach the other role of the same object), but least privilege by default is what a payments audit asks for.
A change to a charging signature no longer touches any read-only client.
The test double for StatementsScreen stubs one query method instead of a whole PSP (payment service provider).

The system has now segregated twice, on two different questions: RefundableMethod by what an implementation can truly promise, this split by the role a client plays. They compose. RefundFlow decides a refund is allowed (capability, on the domain method), then CardPayment carries it out through PaymentGateway.refund (mechanism, on the port). No client gets the raw port: RefundHandler, the support desk's refund button, holds RefundFlow. Handed PaymentGateway instead, it could refund any transaction, gift cards included, without asking.

The symptom to look for. An adapter full of no-ops means the interface above it was never cut by role. The repo has a quiet version: the checkout tests' fake gateways only ever charge, yet each one stubs refund as a no-op. One stub per fake is the cheap end of the dial, and splitting PaymentGateway over it would be the explosion described next. When the fakes stub three or four methods, cut.

The trade-off. Over-apply ISP and you get interface explosion: a hundred one-method interfaces, every call site holding a different name for the same object, and nobody able to say what the thing is anymore. That's SRP's failure pair one level up: the fat interface is the god class of contracts, and fragmentation is their shotgun surgery. ISP is SRP applied to interfaces, with the same dial: segregate by the client roles that actually exist, not by method count. Two roles mean two interfaces. Five methods don't mean five interfaces.

The textbook files ISP under coupling, and Robert C. Martin's own formulation backs it: "clients should not be forced to depend upon interfaces that they do not use" (The C++ Report, 1996), because forcing them "results in an inadvertent coupling between all the clients." Both framings are right; they answer different questions. What segregation buys is decoupling. What tells you where to cut is cohesion: the roles whose methods change together.

If you remember one thing: ISP is the cohesion force applied to contracts. Split by caller, not by method. Too few cuts and you get the fat interface; too many and you get interface explosion; the dial is the roles that actually exist.

D — Dependency Inversion

Definition. The original formulation has two halves: high-level modules should not depend on low-level modules — both should depend on abstractions; and abstractions should not depend on details — details should depend on abstractions. What gets inverted isn't "now there's an interface." It's ownership: the high-level policy owns the abstraction, and the low-level detail implements it. The test is a single question: which module declares the interface?

// module: domain — the high-level policy OWNS the ports.
// (PaymentGateway and PaymentReader from the last section live here too.)
interface OrderRepository {                      // written in the domain's vocabulary,
    fun find(id: OrderId): Order?                // living in the domain's module
    fun save(order: Order)
}
fun interface Clock {
    fun now(): Instant
}

class CheckoutService(
    private val prices: PriceCalculator,
    private val methods: PaymentMethodRegistry,
    private val orders: OrderRepository,
    private val clock: Clock,
) {
    fun checkout(cart: Cart): PaymentResult {
        ...
    }   // business rules; zero infra imports
}

// module: infrastructure — depends on domain; domain has never heard of it
class StripePaymentGateway(private val client: StripeClient) : PaymentGateway, PaymentReader { ... }
class DynamoOrderRepository(private val db: DynamoDbClient) : OrderRepository { ... }

Follow the compile-time arrow: infrastructure imports domain, so the domain compiles alone, with no Stripe SDK and no AWS on its classpath. That inward arrow is the dependency rule of hexagonal architecture (ports and adapters): the domain owns the port, and infrastructure provides the adapter. Hexagonal adds more than the arrow, such as an explicit application boundary and adapters on both the driving and the driven side, but the arrow itself is DIP at the module boundary. Here it is as the repo's actual layout:

checkout/
  domain/            # no infra imports; a test enforces it
    Money  Cart  Order  Receipt  PaymentResult (sealed)  RefundResult (sealed)
    PaymentGateway  PaymentReader  OrderRepository  Clock      <- ports
    PaymentMethod / RefundableMethod (Card, Paypal, Bizum; GiftCard is charge-only)
    PaymentMethodRegistry  RefundFlow  PriceCalculator  ReceiptFormatter  CheckoutService
    StoreCredit  SupportCreditFlow                             <- where gift-card refunds land
  infrastructure/    # depends on domain; domain has never heard of it
    StripePaymentGateway  StripeClient  InMemoryOrderRepository  Meter  KeyStore
    RetryingGateway  MeteredGateway  IdempotentGateway         <- decorators ('by')
  clients/           # also depends on domain: the callers, not the adapters
    StatementsScreen                                           <- ISP's read-only role view
    RefundHandler                                              <- holds RefundFlow, never the port
  smells/            # the broken examples, compiling, each pinned by a test
    CheckoutManager  VipStoreCredit
  app/
    Main.kt          # the composition root: wires everything; DIP with no framework

Two honest caveats. First, so main runs anywhere with zero credentials, the adapters are an InMemoryOrderRepository and a no-network StripeClient stand-in, not the real Dynamo and Stripe SDKs. The ports can't tell the difference, and that a database can become a map in one line of wiring is DIP's whole claim.

Second, domain and infrastructure are packages in one Gradle project, so the compiler alone wouldn't stop a domain file from importing an adapter. ArchitectureTest does, with two checks:

Imports. A domain/ file may import, or name in full, only the domain, Kotlin, and the JDK's java.time and java.util. The JDK allowance is narrow on purpose: java.sql and java.net.http ship with the JDK too, and they're infrastructure.
Ambient reads. java.lang needs no import, and allowing java.time for Instant also allows Instant.now(), exactly the read the Clock port exists to replace. This check fails on the system clock, System, Runtime, Thread or ProcessBuilder anywhere in domain code.

Both are text scans: a tripwire, not a proof. In a production codebase, make them Gradle subprojects and the build enforces the arrow for you.

The gotcha: DI != DIP. Dependency injection is a mechanism: someone hands objects their collaborators. Dependency inversion is a principle about who owns the abstraction, and you can have either without the other. @Autowired StripePaymentGateway, the concrete class, is DI with zero DIP: a framework injecting your coupling for you. Hand-wiring in main is DI in its purest form, and DIP too, because the domain owns the interfaces being wired. Depend on an interface your own module owns and you have DIP, container or not.

The payoff. Testability, with cause and effect in the right order. You can hand CheckoutService a fake gateway and an in-memory OrderRepository because it depends on abstractions the domain owns. The mock isn't the point; it's the evidence. If you can't test a class without booting the database, DIP is telling you an arrow points the wrong way.

The trade-off. The degenerate form is interface-for-everything: FooService/FooServiceImpl pairs that exist because "we always do it that way," OCP's premature abstraction moved up a layer. Abstract at true frontiers, the I/O boundaries (the database, HTTP, queues, the clock, someone else's SDK) where a second implementation genuinely exists: the real one and the test fake, at minimum. An interface between two classes in the same package that always change together isn't low coupling; it's low cohesion disguised as low coupling.

Every port here sits on such a frontier, Clock included. It's deliberately narrower than java.time.Clock, which is abstract, carries a time zone the domain never reads, and no lambda can implement. The JDK's java.time.InstantSource (Java 17) has the right shape (one method, no zone, lambda-friendly) and would do; the domain declares its own anyway, like every other port, so the policy states its need in its own words. Three lines is the whole price.

If you remember one thing: DIP is the coupling principle at architecture scale. The domain owns the interface, details implement it, arrows point inward. DI is a mechanism; DIP is a direction. Abstract at real frontiers, not everywhere.

The Composition Root

Every abstraction has to become an object somewhere, and in this system exactly one place gets to do it: Main.kt, the file where all five principles stop being prose.

// app/Main.kt
fun main() {
    val meter = Meter()
    val clock = Clock { Instant.now() }   // the domain's own port; java.time.Clock never leaks inward

    // ISP: one Stripe adapter, two roles. The money-moving role gets the decorator stack below;
    // the read-only role gets the adapter itself, since a statement needs no retries and no keys.
    val stripe = StripePaymentGateway(StripeClient(clock))

    // Composition: cross-cutting concerns as a decorator stack. The ORDER is a
    // decision, and it lives here, in wiring, not in a class hierarchy.
    val gateway: PaymentGateway =
        MeteredGateway(
            RetryingGateway(
                IdempotentGateway(stripe, KeyStore()),
            ),
            meter,
        )

    // OCP's real cost, concentrated: one plain line per payment method.
    val methods = PaymentMethodRegistry(
        "card" to { CardPayment(gateway) },
        "paypal" to { PaypalPayment(gateway) },
        "bizum" to { BizumPayment(gateway) },
        "giftcard" to { GiftCardPayment(gateway) },   // claims no refund capability
    )

    // DIP: details handed to a domain that has never heard of them.
    val orders = InMemoryOrderRepository()   // prod: DynamoOrderRepository, same port, one line
    val checkout = CheckoutService(
        PriceCalculator(),                   // SRP: Finance's class, alone
        methods,
        orders,
        clock,                               // the same clock the PSP stand-in stamps with
    )

    // The clients, each holding only the role it plays.
    val statements = StatementsScreen(stripe)                     // ISP: reads, can't move money
    val refundDesk = RefundHandler(RefundFlow(orders, methods))   // LSP: refunds only through the gate
    val storeCredit = SupportCreditFlow(StoreCredit())            // where a gift card's refund lands

    // …then a short demo script plays a customer and the support desk: a card order and a
    // gift-card order, the statement, both refunds, and the card's refund button pressed twice.
    demo(checkout, orders, statements, refundDesk, storeCredit)
    println("logical charges metered: ${meter.count("charges")}")
}

Read it as a checklist:

Composition. The gateway is wrapped three times: IdempotentGateway so an approved order isn't charged again, RetryingGateway so a timed-out call gets another try, and MeteredGateway so someone can count what happened. Each wrapper holds the port, not a concrete class, which is why they stack at all.
Order. Where each wrapper sits is a decision made here. MeteredGateway(RetryingGateway(…)) counts logical charges; RetryingGateway(MeteredGateway(…)) counts attempts. Neither is wrong; they're different metrics, a one-line diff apart. Neither counts PSP calls, though: in both, idempotency sits inside the meter, so a double-click the cache answers still gets metered. To count PSP calls, wrap the Stripe adapter itself.
OCP. The registry: the one registration line the OCP section promised you.
ISP. One Stripe adapter, two roles: CardPayment sees a decorated PaymentGateway, StatementsScreen an undecorated PaymentReader, since a statement needs no retries or keys. Cross-cutting concerns attach per role.
LSP. Details arrive typed as ports (PaymentGateway, not StripePaymentGateway), and refunds reach money only through RefundFlow, which asks each method for the capability.
DIP. No framework in sight: DI in its purest form, down to one clock shared by the domain and the PSP stand-in.
SRP. main holds no business logic, so its single reason to change is "the wiring changed." The demo script lives in a function of its own.

The decorators forward with Kotlin's by inner: delegate the whole port to the wrapped object, then override only what you care about. That's black-box reuse with no fragile base class, at one cost: by forwards whatever it isn't told about. refund already passes through all three layers unmetered, unretried and without a key, and a method added to PaymentGateway tomorrow would slip through the same way, silently. It's the open default, the opposite of a sealed when that makes you decide.

What the idempotency layer can't do. It's a local memory of approvals for calls made one at a time. If the PSP approves but its response never arrives, or two calls race past the cache, only the key sent to the PSP protects you, which is why the Stripe adapter forwards it. Both layers also check what a key is reused for:

Same request: the original answer.
Same order, another amount or method: Conflict, the way Stripe refuses a key reused with different parameters. Otherwise a cart edited after payment would come back "approved" at a total nobody charged.
Why not Declined: a decline means no money moved, and here some may have. If the PSP charged the first attempt but its response never arrived, a charge exists that no order records, and "declined" would tell a customer who paid to pay again. Finding that charge by its key is reconciliation, out of scope here.
Same price, other lines: the PSP only sees amount and method, so swapping size M for L replays cleanly through both layers. Only the domain knows the lines, so CheckoutService compares them with the recorded order and answers Conflict too.

Keying the order has one more price: a real PSP replays the first answer for a key, declines included, so paying another way after a decline needs a new key (order plus attempt number), which the sample leaves out.

What the retry layer won't do. It retries only Timeout, through an exhaustive when: a decline is an answer, not a failure, and asking again only asks the same question. It also retries only a request that carries a key. A Timeout means nobody knows whether the PSP charged, so a keyed retry is safe (the PSP dedupes it) and a keyless one could charge twice. The wired flow always has a key, because an OrderId can't be blank. Add another PaymentResult and that when stops compiling until someone decides whether the new outcome is worth retrying.

Throw Away the Acronym

Here's the whole article as two questions, the two to actually ask in code review:

"Do these things change for the same reason?" — the cohesion question. If yes, keep them together; if no, separate them. SRP asks it about classes, ISP about interfaces.
"If this changes, what else is forced to move?" — the coupling question. OCP asks it about new features (nothing should move: add a class), LSP about subtypes (callers of the base must never notice), DIP about architecture (details move; policy doesn't).

The two feed each other: group what changes together and fewer changes cross a module line, so coupling falls; cut a dependency and each side comes out more focused, so cohesion rises.

One bounded context was enough for all five letters, because the domain forced each one: pricing and receipt copy answer to different departments, new payment methods keep arriving, gift cards can't refund, a statements screen has no business moving money, and checkout has to be testable without a PSP. Here is every dial in one place:

Principle	Under-applied	Over-applied	The dial
SRP	God class	Shotgun surgery	One actor per class
OCP	Growing `if/else`	Speculative interfaces	Wait for the second case; seal what you own
LSP	Broken: `is`-check patches in callers	— (constraint, not a dial)	Can't keep the contract → don't inherit
ISP	Fat interface	Interface explosion	One interface per role
DIP	Domain imports infrastructure	`FooServiceImpl` everywhere	Abstract at true frontiers only

The LSP row reads differently on purpose: a constraint isn't under-applied, it's broken, and the is-check patches are the symptom you see in callers.

Cohesion and coupling aren't SOLID's children; they're its grandparents. Stevens, Myers, and Constantine named the pair in "Structured Design" (IBM Systems Journal, 1974); Parnas nailed the underlying idea as information hiding in 1972; the acronym arrived three decades later. The letters are the most successful marketing campaign those two ideas ever had, though LSP also carries a correctness rule that neither force gives you on its own. Useful as mnemonics, dangerous as a checklist: a checklist tells you to add an interface, and the forces tell you whether the interface bought you anything.

Everything in this article lives in the companion repo: one Gradle project holding the clean slices and the smells package side by side, with a test pinning each claim (the VIP balance really goes negative, the same cart really charges the PSP once, a gift-card order really can't take a refund, the decorator order really changes the metric) and a main() you can run.