A dark banner with a faint grid. On the left, orange text reads “CVE-2026-91403”, followed by “CVSS 9.1 · Java JSSE · not RCE”. The headline reads “Java still trusts eMudhra’s broken CAs”, with the subtitle “Root cause, real-world risk, and how to fix it in Oracle Java, Temurin, Corretto and other JDKs”. Three tags below say “blocked.certs”, “Dockerfile” and “48 fingerprints”. On the right, a diagram shows three boxes in a vertical chain: “Root CA, trusted in cacerts” at the top, then “Intermediate CA, private key = 4” outlined in red with a key icon and a red X, and at the bottom “example.com, forged certificate”. The red line from the intermediate to the forged certificate shows how the compromised key leads to a fake certificate.

PSA Java CVE-2026-91403 vulnerability

TL;DR: CVE-2026-91403 (CVSS 9.1) is not a remote code execution bug. Java still trusts eight eMudhra intermediate certificate authorities, and anyone can compute their private keys. An attacker who can sit between your Java application and a server it calls over TLS can impersonate that server. Services that accept client certificates against Java’s default trust store are exposed even without that position. To fix it, update to a patched JDK build. If your vendor hasn’t shipped one yet, add the compromised certificates to blocked.certs and add a second control alongside it. Both are covered below, including a Dockerfile you can adapt. On October 24, Oracle and OpenJDK issued a follow-up, CVE-2026-114820: the first fixed builds (.0.2) are now listed as affected too, and the fix also removes four eMudhra and Sectigo roots.

Last updated: October 30, 2026, 11:47 UTC. This post is updated as vendors ship fixes. See Updates for what changed.

Contents

  1. What happened
  2. What could be exploited, and what can’t
  3. How to fix it in Oracle Java
  4. How to fix it in other Java distributions
  5. The workaround: patching blocked.certs in your image
  6. Why blocked.certs alone isn’t enough
  7. Checklist
  8. Updates (newest first)
  9. Sources
  10. Credits

What happened

In April 2025, the Indian certificate authority eMudhra created eight intermediate CAs with elliptic-curve keys. Because of a bug in its key-generation script, the private keys of those intermediates were tiny integers, small enough that anyone can recover them by brute force from the public key printed in each certificate (Mozilla bug 2083449). Anyone who has an intermediate CA’s private key can issue a valid-looking certificate for any domain.

Browsers reacted within hours. Chrome pushed a CRLSet block the evening the report arrived (Saturday, October 17, 2026), Mozilla blocked the intermediates through OneCRL the same night, and Apple and Microsoft followed on October 19 and 20.

Java is a separate case. Its default TLS stack (JSSE) doesn’t receive any of those browser revocation feeds, has revocation checking switched off by default, and doesn’t require Certificate Transparency. A standalone JDK therefore keeps accepting these chains. Six of the eight intermediates issue TLS certificates and two issue code-signing certificates. They chain up to two roots: eMudhra’s own emSign ECC Root CA – G3 and Sectigo’s AAA Certificate Services. Sectigo had cross-signed the same keys, so the path through the Sectigo root is compromised too.

On October 21, Oracle and OpenJDK published out-of-band advisories. Oracle lists Java SE 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1, GraalVM for JDK 17.0.21 and 21.0.13, and GraalVM Enterprise Edition 21.3.20 as affected, along with all earlier versions. This list includes the scheduled updates released the day before, on October 20.

What could be exploited, and what can’t

The 9.1 score comes from the CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, with JSSE as the affected component. It means network-reachable, no authentication, and high confidentiality and integrity impact. Availability impact is none, and the vector says nothing about code execution. You may see the issue called “RCE” on social media, but neither Oracle nor OpenJDK describes it that way.

A realistic attack requires the attacker to get between your Java process and a server it talks to, for example through a compromised network segment, DNS or BGP hijacking, or a malicious proxy. From there they present a forged certificate for the real hostname, and your application accepts it. They can then read and modify traffic in both directions: API credentials, tokens, payloads and responses. The two code-signing intermediates also matter if you verify signed JARs. One case needs no interception at all: if a Java service accepts client certificates for authentication (mutual TLS) and trusts the JDK’s default cacerts for that, an attacker can create a client certificate with a compromised key and connect directly. If you run such a service, treat this as an emergency, or restrict client-certificate trust to your own private CA.

For comparison, Log4Shell scored 10.0 and could be exploited with one crafted string. This vulnerability needs a privileged network position first. Once an attacker has that position, though, the rest is easy: the private keys are public, common interception tooling already supports them, and forged certificates for well-known domains are circulating. Put it through your fast-track patch process and apply the workaround today rather than waiting for the next release window. Treat it as an emergency if your Java services make outbound TLS calls across networks you don’t control, such as the public internet, shared hosting networks or third-party proxies.

How to fix it in Oracle Java

Oracle has published two alerts for this incident. The first, CVE-2026-91403 on October 21, blocked the compromised intermediates in builds numbered .0.2 (27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.33.0.2 and 8u511-b32). The second, CVE-2026-114820 on October 24, lists those .0.2 builds as affected and provides updates that remove the impacted eMudhra-related root certificates as well. Install the newest build listed in the Java SE patch availability document for both alerts. Oracle’s release notes for the new builds, such as 8u511 b33 and 27.0.1.0.3, say they remove four roots from cacerts: emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 and AAA Certificate Services. According to secondary sources, the fixed builds are 27.0.1.0.3, 25.0.5.0.3, 21.0.13.0.3, 17.0.21.0.3, 11.0.33.0.3 and 8u511 b33. Confirm the exact versions in Oracle’s document before you rely on them.

If you can’t upgrade immediately, Oracle offers a replacement blocked.certs file, with one version for Windows and one for other platforms. Back up the current $JAVA_HOME/lib/security/blocked.certs, copy over any entries you added to it yourself, then swap in Oracle’s file. On Java 8 the file is called blacklisted.certs and lives in the same directory.

Oracle’s guidance also accepts revocation checking instead: add -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true to the command line of applications that use TLS. Every handshake then needs to reach the CAs’ CRL endpoints, so check that your network allows it. If you verify signed JARs, use jarsigner -verify -revcheck -strict on JDK 17 and later, since two of the compromised intermediates issued code-signing certificates.

How to fix it in other Java distributions

How you fix it depends on where your JDK gets its trusted roots:

How Java was installedWhere trust comes fromWhat to do
Standalone builds: Temurin, Liberica, Zulu, Corretto, tarballs, installers, official Docker imagesThe JDK’s own cacerts and blocked.certsUpdate to your vendor’s fixed build (Azul Zulu has one, and so do Corretto 21 and Corretto 25). Until yours ships, use the workaround below.
Linux distro packages (Debian, Ubuntu, Fedora, RHEL and similar)Usually the OS certificate storeUpdate the ca-certificates package. On RHEL and UBI, where no fixed package was available on October 22, apply the workaround in Red Hat’s bulletin until one ships.
Homebrew and FreeBSDBundled with the Java packageUpdate the Java package itself.

Two traps to watch for with standalone builds and containers:

  1. Running apt upgrade ca-certificates inside a vendor JDK image does nothing for Java. Vendor JDKs ship their own cacerts, and Temurin’s USE_SYSTEM_CA_CERTS=1 option only adds the OS roots on top. It never removes anything.
  2. Not every vendor has shipped a fix yet. Azul Zulu released one on October 21 and Corretto 21 and Corretto 25 on October 23, but as of October 22, Temurin had no patched release, and Corretto’s fix was still in review for versions 11, 17, 21 and 25. Watch your vendor’s release announcements and container image tags. If you use an image that is built on top of a vendor JDK image, also check when that image was last rebuilt before you assume it contains the fix.

The workaround: patching blocked.certs in your image

blocked.certs lists certificates Java will refuse to trust even if they chain to a trusted root. It’s a plain text file: the first line declares Algorithm=SHA-256, and each following line is one certificate fingerprint. The workaround appends fingerprints for all 16 certificates (the 8 intermediates plus their 8 cross-signed copies), in every encoding Java is known to accept, which comes to 48 lines. In independent testing, a JDK patched this way refused the compromised chains even with revocation checking off, while ordinary HTTPS sites kept working.

The 16 “as issued” fingerprints come from the reporter’s impacted-intermediates.json. The other 32 cover re-encoded copies that an attacker can produce without the private key (see below). They follow the same rules OpenJDK’s own tooling uses to generate blocked.certs, as published in a package maintainer’s fix, and we recomputed all 48 independently from the public certificates before publishing. Oracle’s fixed builds add the same number of entries to their blocked.certs. Save the list as emudhra-blocked.certs next to your Dockerfile. Comment lines are fine, because the build step only picks up the fingerprint lines. Check it against the sources rather than trusting a copy from a blog post, this one included.

# emudhra-blocked.certs: SHA-256 fingerprints of every known encoding of the
# 16 compromised eMudhra intermediate certificates (8 keys x 2 issuers).
# Per certificate: the DER as issued, the same with the signatureAlgorithm NULL
# parameter toggled, and for the ECDSA-signed (emSign-issued) ones the s -> n-s
# variant of each. 8 x 4 + 8 x 2 = 48 lines.
# Sources: impacted-intermediates.json (originals) and the variant set from
# github.com/gominimal/pkgs/pull/949, recomputed independently from the PEMs.

# EM DV TLS CA - G3B (issued by emSign Root TLS CA - G3)
42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
37E866582D43C35D7C17D47794B974F291B3047B868DC123382477F7A08AEFA8
CD740652E552D93EE64D7C9D1CC25228E466895889CEE25A11C962AB09906978
C5F1531C6331659C75A6411A088A65DAD7518FD91F57B64537A651B6DCD76AE0

# EM DV TLS CA - G3B (issued by AAA Certificate Services)
45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
C93F7B1EEF27CFD0F227DFE3F057D63833533890B7230B1821A424BD40848E33

# EM OV TLS CA - G3B (issued by emSign Root TLS CA - G3)
98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
33C1BCDC6DA52DF950B3B14121127DA1955F7F31F828497A7608986EB2DDCC09
8F580C6E34CEE7EE57B93BA9C0AC5FAEDD7BF3085F5EE9C6C0175A2555B111D0
50E71B08B9AC407B93D50EE90100CB6B6B41C956DC7AA86C5BAA38AE713CFD6A

# EM OV TLS CA - G3B (issued by AAA Certificate Services)
5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
21182E577E5106B669322ABE6086FFF6B101E8C83FD2D01DC32D854961AAC832

# EM EV TLS CA - G3B (issued by emSign Root TLS CA - G3)
E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
EF34030C01B13BF42B534072DCC3C75B13C009DC9241119ADA39E2C15E2AFD2E
C65CBC98295549BA940494A6214B9706E7115E64F3FE269412C5B48AEACB2222
B75104427B6A5BE55033AF50DC0FE3102181BE130E761D487A4E8178C93317DD

# EM EV TLS CA - G3B (issued by AAA Certificate Services)
579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
75D8853BE99C87678E6C7BF9F684B31454D81DEB1C7F37B9FBC026A268337536

# EM DV TLS CA - G3C (issued by emSign Root TLS CA - G3)
0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
A4B72DBD37256324B557B9176F8CBA4310DDFFBCC4609977E2463F3504A716C8
59CC5FD35A737B84682EDA26AD23F5ADE8AA847D5BEB3B38AB6CD62347925A66
A0ED2032C5249EE1A653F1F88005D9E779E385DF533B5C521137CEE5176CD7FC

# EM DV TLS CA - G3C (issued by AAA Certificate Services)
62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
D8A50FA0068E9558E6C3BEE18CDB03B7EECBC3C56C1B2336B98AEE11644994B8

# EM OV TLS CA - G3C (issued by emSign Root TLS CA - G3)
CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
A104B1314DF8E02F7DE27DDC287D0961D6E6824AD4DAFC3D11064F24C1B653D5
558EC6CA13DA9B800FEDC9ACC3C18CA98BB19768F1309B60B5BB89793B3481CB
10E7E5BFDB55CFB78D0C21366654046182087A1960C079682513795665AA0C6B

# EM OV TLS CA - G3C (issued by AAA Certificate Services)
7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
A4328E058C867AF9CA8D468C388B72C250CE84BDB6BAF7F8C47C9A0B1CB35EEC

# EM EV TLS CA - G3C (issued by emSign Root TLS CA - G3)
432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
169A0523C5E071AA4E298286DBD4EE0E40C8C06ABB6B0C077D132F001FA19240
7BA62FEC54E9D040556FCA70A6A88F03761C178FA1F7CB8390A73076849F55A2
8FED925362F62FFF90DD835BE6ADC32B02DEC8DF5E82D83E512F1C977D066E82

# EM EV TLS CA - G3C (issued by AAA Certificate Services)
FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
B7121039CAF13E03E52507F42DB56FA802FF119DA7591ABA8A2E842133DB7C9C

# EM OV CS CA - G3B (issued by emSign Root CS CA - G3)
9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
5D8FC3ECDDB4DDB243AEE5C306BCFDE670ADF2D66B193DD3AA2D6B2FB91869BE
3B88E4B77FC53C45CA216700E39FC0EA7621A0A40FCB268215082E35D2BD5829
3C5456D4219BA2372273867FAC9A07104600391E96C7FDCDE3B4420C0F1F69BF

# EM OV CS CA - G3B (issued by AAA Certificate Services)
A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
9E7617035CFF537C837E078A7CDC7FD9EB77BCE7DDF3DC6DBD5C50AAFC1F1FA7

# EM OV CS CA - G3C (issued by emSign Root CS CA - G3)
4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
AB7292F82267333031F512379FDBADA949DFA49D3C046CC8FA7F34117C342986
A61FE79B019062DD3C6420BC20EAF64702CC1063C546A084DD0A0BCB915A14A9
4DED6F955374E40B8558A611A9719B2AB69AA6852AC50966EDC4B07DE4D4277C

# EM OV CS CA - G3C (issued by AAA Certificate Services)
84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD
912A48745BFF2F14D1798B27858613DE1C0EB03C2BDE630AFD0DDD5251E1EBE1

Then add the patch to your runtime image. The example takes the base image as a build argument, so it works with whichever JDK image and version you run:

# Build with your own base image, pinned by digest, e.g.:
#   docker build --build-arg BASE_IMAGE=eclipse-temurin:<version>-jre@sha256:<digest> .
ARG BASE_IMAGE
FROM ${BASE_IMAGE}

# --- Stopgap for CVE-2026-91403 ---------------------------------------------
# Remove this block once your vendor ships a build with the official fix.
# Java 8: the file is blacklisted.certs, in $JAVA_HOME/jre/lib/security for a
# JDK or $JAVA_HOME/lib/security for a JRE; adjust the path below.
COPY emudhra-blocked.certs /tmp/emudhra-blocked.certs

RUN set -eux; \
    blocked="$JAVA_HOME/lib/security/blocked.certs"; \
    test -f "$blocked"; \
    cp "$blocked" "$blocked.orig"; \
    fps="$(grep -E '^[0-9A-Fa-f]{64}$' /tmp/emudhra-blocked.certs | tr 'a-f' 'A-F')"; \
    # Fail the build if the list is incomplete or malformed
    test "$(printf '%s\n' "$fps" | wc -l)" -eq 48; \
    printf '\n# CVE-2026-91403: compromised eMudhra intermediates\n%s\n' "$fps" >> "$blocked"; \
    rm /tmp/emudhra-blocked.certs

# --- Second layer: remove the four roots (OpenJDK guidance, CVE-2026-114820) -
# Same roots that OpenJDK's JDK-8395690 and Oracle's October 24 builds remove:
# emSign ECC Root CA - G3, emSign Root CA - G1, emSign Root CA - G2 and
# AAA Certificate Services. Matched by subject because aliases differ between
# vendors. Safe to rerun; fails the build if any of them is still present.
# Check first that none of your outbound endpoints chain to these roots.
# (Java 8 JDK: use $JAVA_HOME/jre/lib/security/cacerts instead.)
RUN set -eu; \
    ks="$JAVA_HOME/lib/security/cacerts"; \
    re='^Owner: CN=(emSign ECC Root CA - G3|emSign Root CA - G1|emSign Root CA - G2|AAA Certificate Services),'; \
    keytool -list -v -keystore "$ks" -storepass changeit \
      | awk '/^Alias name: /{a=substr($0,13)} /^Owner: /{print a "\t" $0}' \
      | grep -E "$(printf '\t')${re#^}" | cut -f1 \
      | while IFS= read -r alias; do \
          keytool -delete -keystore "$ks" -storepass changeit -alias "$alias"; \
        done; \
    if keytool -list -v -keystore "$ks" -storepass changeit | grep -qE "$re"; then \
      echo "eMudhra/AAA root still present" >&2; exit 1; \
    fi

# --- Optional extra layer: revocation checking ------------------------------
# Rejects the revoked intermediates, but every TLS handshake now needs to
# reach the CA's CRL endpoint, which breaks in egress-restricted networks.
# ENV JAVA_TOOL_OPTIONS="-Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true"
# ----------------------------------------------------------------------------

# ... the rest of your image (app, user, entrypoint) ...

The first RUN step blocks the intermediates; the second removes the four roots that OpenJDK’s guidance lists, matching them by certificate subject because aliases differ between vendors (Temurin, for example, uses aliases like cn_emsign_root_ca__g1,... instead of emsignrootcag1 [jdk]). We tested the root-removal step against a real cacerts file: it removed only the listed roots, left unrelated emSign roots alone, and running it twice is harmless. Both steps work on any image whose JDK sets JAVA_HOME, including application-server images built on a vendor JDK. Restart running JVMs after deploying, since blocked.certs is read at startup.

Distroless and other shell-less images: both steps need a shell and keytool, which minimal runtime images often don’t have. Run them in a build stage based on an image with the same JDK version, then COPY --from the patched lib/security/blocked.certs and lib/security/cacerts into the final image’s Java directory. Also check which trust store the final image actually uses: some distroless Java images ship the operating system’s certificate bundle instead of the JDK’s, which can contain both affected roots.

Check which trust store your JVM actually uses. blocked.certs lives in the JDK itself and is checked during certificate path validation whatever trust store the application uses, but root removal only helps in the trust store the JVM reads, and that isn’t always cacerts. Look for these before you assume you’re covered:

  • A javax.net.ssl.trustStore system property, in JVM options, JAVA_TOOL_OPTIONS or startup scripts. If it’s set, the JVM ignores cacerts.
  • A jssecacerts file next to cacerts in $JAVA_HOME/lib/security. It takes precedence over cacerts.
  • Trust stores configured inside client libraries, application servers, database and messaging drivers. Each one is a separate file to fix.
  • Runtimes built with jlink, which contain their own copy of cacerts and blocked.certs. Patch the runtime you ship, not just the JDK you built it from.

To verify the patch, use the public test hosts listed on the reporter’s incident page, which serve certificates from the compromised intermediates. Some hosts serve the chain through the emSign root and others the chain through AAA Certificate Services, and a JDK can reject one while accepting the other, so test at least one of each. An HTTPS request from inside your patched container, using the same JVM and trust settings as your service, should fail with an untrusted-certificate error on every test host. The same request to any normal site should still succeed.

Why blocked.certs alone isn’t enough

Fingerprint blocklists have a known weakness here. A fingerprint is a hash of a certificate’s exact bytes, and Sonatype’s researchers showed that an attacker can change those bytes without the private key while the signature stays valid. For ECDSA, they swapped the signature’s s value for its mathematically equivalent n − s. For RSA, they dropped an optional NULL parameter. In both cases Java blocked the listed certificate but trusted the re-encoded one, because its fingerprint was different.

The official fix covers this case. The upstream OpenJDK change adds the same 16 certificates and generates the blocklist so that alternative encodings are matched too. A hand-edited file with only the 16 original fingerprints doesn’t have that protection. The 48-line list above adds the two known re-encodings, which are exactly the ones Sonatype used, and testing on Temurin showed Java does accept the NULL-toggled variants, so they’re worth blocking.

Even with all 48 lines, a hand-edited file only blocks the encodings someone has thought of, so treat it as the first layer and remove the roots as the second. Since October 24 that’s also the official advice: OpenJDK and Oracle (CVE-2026-114820) remove four roots, emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 and AAA Certificate Services, and OpenJDK tells anyone whose vendor hasn’t shipped that change yet to delete them from cacerts themselves. Browsers are dropping the emSign roots, eMudhra is leaving the TLS business, and Chrome and Firefox no longer trust AAA Certificate Services for TLS, so the cost is low for most applications. Still check your outbound dependencies first. Revocation checking is an extra option if your network can reach the CAs’ CRL endpoints. Replace the workaround with a vendor build that fixes both CVEs as soon as one is available.

Checklist

  1. Inventory every Java runtime you run: services, containers, CI runners and desktop tools. Note which trust store each one actually reads: its own cacerts, the OS trust store, a jssecacerts file, or a custom file set with javax.net.ssl.trustStore.
  2. Distro-packaged OpenJDK: update ca-certificates, or on RHEL and UBI apply Red Hat’s workaround until a fixed package ships.
  3. Oracle JDK: install the newest build covering both Oracle alerts (CVE-2026-91403 and CVE-2026-114820), not just the .0.2 build. Azul Zulu: install the patched build. Until you can, use the vendor’s replacement block-list file.
  4. Other standalone JDK builds: patch blocked.certs, remove the four roots (emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2, AAA Certificate Services), and watch for a vendor build whose release notes mention JDK-8395690 / CVE-2026-114820.
  5. Restart JVMs, then verify against test hosts for both the emSign and the AAA chain.
  6. Once fixed builds ship, bump your base images and rebuild with docker build --pull (redeploying or retagging an old image keeps the old JDK inside it). Rerun the test hosts for both chains against the new build, and only then remove the workaround.

Updates

October 30, 2026, 11:47 UTC

The official Temurin 25 and 21 container images now ship the fixed builds. The daily image audit from October 30, 09:53 UTC found eclipse-temurin:25-jdk on 25.0.5 and eclipse-temurin:21-jdk on 21.0.13, and both rejected all 12 compromised test chains. They show none of the 48 fingerprints in blocked.certs, which is expected: Temurin’s fix removes the roots instead. eclipse-temurin:17-jdk was still on 17.0.20.1 and failed. Adoptium publishes container images only once all binaries for a JDK version are out, which explains the delay.

What to do now: rebuild images based on eclipse-temurin:25 or :21 with docker build --pull, and check the Java version inside the result. Images built on top of the official Temurin images, such as application-server images, only pick up the fix once their own maintainers rebuild them, so check those separately. The Dockerfile approach is unchanged: on the new Temurin images, its steps become extra hardening for custom trust stores rather than the only protection. Temurin 17 images still need the full workaround. Docker’s separate hardened Temurin images are a different product; one user reported on October 26 that they still contained the affected certificates, so check them on their own.

No change for Corretto, Oracle or OpenJDK since the previous update.

October 30, 2026, 10:23 UTC

Adoptium has published the list of fixed Temurin versions. Its announcement now names the builds that contain the fix: 27.0.1.0.2+1, 25.0.5+8, 21.0.13+9 and 17.0.21+9. JDK 11 and 8 are still waiting for upstream tags. That confirms the Temurin 27 build we could only see on a third-party site on October 25, and adds Temurin 17. Adoptium also clarifies that OpenJDK’s CheckCerts tool correctly finds emSign Root CA – G1 in these builds but wrongly reports it as a bad root, since Mozilla still trusts it.

The official Temurin container image still hadn’t caught up on October 29. The daily image audit again found eclipse-temurin:25-jdk running 25.0.4.1, with none of the 48 fingerprints, and failing the TLS chain test. One project noticed that on October 26 the 25.0.5+8 binaries existed only for Alpine on x64, which may be why the multi-architecture image tags are lagging. Until the tags move, images built on the official Temurin images need the Dockerfile workaround. The Dockerfile approach itself is unchanged.

No change for Corretto, Oracle or OpenJDK since the previous update.

October 29, 2026, 08:31 UTC

The official Temurin container image was still unpatched on October 28. A public project that audits JDK container images daily found that eclipse-temurin:25-jdk still contained Temurin 25.0.4.1 on October 28 at 15:01 UTC, with none of the 48 blocked fingerprints, and it failed the TLS chain test. So even though Temurin 25.0.5+8 is released, anyone building on the official Temurin images, including images built on top of them, is still running an unpatched JDK. Keep the Dockerfile workaround in those images, and check the Java version inside your image rather than trusting the tag.

Corretto’s Docker image has caught up. In the same audit, amazoncorretto:25 contained Corretto 25.0.5 with all 48 fingerprints and rejected all 12 compromised test chains. Its roots are still present, so it doesn’t match OpenJDK’s root-removal list, but the attack path is closed. This supersedes the October 23 note that the Corretto images hadn’t been updated, at least for Corretto 25. The audit also confirms that vendors’ fixed builds use the same 48 fingerprints as this post’s list.

The Dockerfile approach is unchanged. No change for Oracle or OpenJDK since the previous update.

October 28, 2026, 13:15 UTC

Inbound client-certificate authentication is exposed without interception. A project’s security notice points out that if a Java service accepts CA-signed client certificates, an attacker can create one with a compromised key and connect directly, without any network position. We’ve added this to “What could be exploited”: services that authenticate clients against the JDK’s default cacerts should patch or apply the workaround immediately, or restrict client trust to their own CA.

Shell-less images need a different approach. The same notice found that the project’s distroless image trusted both affected roots, while its regular Temurin image had only the emSign root. The Dockerfile steps need a shell and keytool, so we’ve added a note on running them in a build stage and copying the patched files into minimal images. The steps themselves are unchanged.

Oracle’s fixed builds for JDK 25 and 27 are listed by secondary sources as 25.0.5.0.3 and 27.0.1.0.3, completing the list in the Oracle section. No change for Temurin, Corretto or OpenJDK since the previous update.

October 28, 2026, 10:29 UTC

Adoptium has officially confirmed the Temurin fix. In an announcement on its news page, Adoptium says the October 2026 Temurin releases remove the roots that signed the compromised intermediates from Temurin’s trust store, because they’re built from Mozilla’s NSS 3.131.1 root data. Release pipelines for JDK 27, 25, 21 and 17 have been launched and binaries are published as testing completes. As of October 26, JDK 8 and 11 were still waiting for upstream build tags. This confirms what we described in the October 27, 07:50 UTC update.

A caveat about OpenJDK’s checker. Adoptium points to the OpenJDK guidance but warns that its CheckCerts.java tool also looks for emSign Root CA – G1 and G2, which Adoptium describes as not related to the compromised intermediates. So a fixed Temurin build can still fail that check. To verify Temurin, use the test hosts for both chains instead. The Dockerfile in this post is unchanged: removing all four roots still matches the OpenJDK and Oracle fix, and on Temurin you can drop G1 and G2 from the pattern if you prefer to follow Adoptium and Mozilla.

No change for Corretto, Oracle or OpenJDK since the previous update.

October 27, 2026, 07:50 UTC

Adoptium says its October 22 Temurin builds are fixed, which softens our earlier correction. Asked on its release tracker about the follow-up CVE-2026-114820, an Adoptium maintainer replied on October 26 that the Temurin 25 and 21 binaries released last week are fixed. Temurin takes its roots from Mozilla’s list, and the NSS 3.131.1 update removed the roots that signed the compromised intermediates. That’s emSign ECC Root CA – G3; Temurin never shipped AAA Certificate Services.

The difference from Oracle and OpenJDK is emSign Root CA – G1 (and G2, which Temurin doesn’t ship). Those roots aren’t behind the compromised chains. OpenJDK and Oracle remove them as a precaution, while Mozilla has kept G1 trusted for now. So our October 26 statement that Temurin 25.0.5+8 “doesn’t fix CVE-2026-114820” was too strong: it closes the actual attack path, but its cacerts doesn’t match the OpenJDK guidance exactly, and scanners that match on Java versions may still flag it. We’ve reworded the earlier notes.

What we recommend for Temurin users: upgrade to 25.0.5+8 or 21.0.13+9. Keeping the Dockerfile’s root-removal step is still sensible: it costs little, matches OpenJDK’s guidance, and covers any trust store that wasn’t rebuilt from Mozilla’s list. If you’d rather follow Mozilla’s decision on G1, you can drop G1 and G2 from the step’s pattern and keep G3 and AAA. Keep the blocked.certs step either way.

No change for Corretto, Oracle or OpenJDK since the previous update.

October 26, 2026, 15:01 UTC

Temurin 21.0.13+9 also still contains emSign Root CA – G1. A second project checked Temurin’s JREs with keytool on October 25: Temurin 21.0.13+9 has emSign ECC Root CA – G3 removed but still has emSign Root CA – G1. That matches what we reported for 25.0.5+8, so the root-removal step in the Dockerfile applies to both Temurin LTS builds from October 22. The same report notes that the upstream root removal (JDK-8395690) hadn’t been backported to the JDK 21 update repositories yet, so a Temurin build with it may take a while.

No change for Corretto, Oracle or OpenJDK since the previous update.

October 26, 2026, 10:32 UTC

OpenJDK now officially recommends removing four roots. OpenJDK’s eMudhra guidance page covers the follow-up CVE-2026-114820 (JDK-8395690). Its preferred fix is a runtime whose release notes mention JDK-8395690 / CVE-2026-114820, even if you already updated in the past few days. Until your vendor ships one, it says to delete four roots from cacerts: emsignrootcag1 [jdk], emsignrootcag2 [jdk], emsigneccrootcag3 [jdk] and comodoaaaca [jdk]. For runtimes that use the operating system’s certificates, it says to rebuild Java’s copy after updating them (rm -f /etc/ssl/certs/java/cacerts then update-ca-certificates --fresh).

We’ve made root removal an active step in the Dockerfile. It used to be a commented-out suggestion for two roots. It now removes all four, matches them by subject so it works with any vendor’s alias names, and fails the build if any remain. We tested it against a real cacerts file. The “Why blocked.certs alone isn’t enough” section and the checklist are updated to match.

What this means per vendor. Oracle’s October 24 builds and Azul Zulu’s October 24 out-of-cycle release fix CVE-2026-114820. The Corretto 21 and 25 builds from October 23 fix CVE-2026-91403, but we haven’t seen them claim the follow-up, so remove the roots yourself on those for now. Temurin: our October 24 and 25 updates said 25.0.5+8 drops the emSign root. It drops emSign ECC Root CA – G3, but a project that checked the build found emSign Root CA – G1 still present. See the October 27, 07:50 UTC update for what that means.

October 26, 2026, 07:52 UTC

Oracle issued a second alert, CVE-2026-114820, and now also removes the roots. On October 24, Oracle published Security Alert CVE-2026-114820 (CVSS 9.1, JSSE). It provides Java updates that remove the set of impacted root CA certificates related to eMudhra, and it lists the earlier fixed builds, including 25.0.5.0.2, 21.0.13.0.2 and 17.0.21.0.2, as affected. According to a review of Oracle’s release notes, the new builds remove three emSign roots and the AAA Certificate Services root from cacerts, with baselines such as 21.0.13.0.3+1 and 17.0.21.0.3+1. If you run Oracle JDK, a .0.2 build is no longer enough: install the newest build from the patch availability document. We’ve updated the TL;DR, the Oracle section and the checklist.

What it means for other JDKs. Oracle’s approach matches this post’s recommended second layer: block the intermediates and remove the roots. Fixed builds from other vendors that only carry the upstream blocked.certs change, such as Corretto 21.0.13.0.10, may get a similar root removal later. Until they do, removing the roots yourself, as in the Dockerfile above, gets you to the same state. We haven’t seen an OpenJDK advisory for CVE-2026-114820 yet.

October 25, 2026, 12:49 UTC

(Clarified on October 27, 2026, 07:50 UTC: 25.0.5+8 removes the emSign root behind the compromised chains, but keeps emSign Root CA – G1, which OpenJDK and Oracle remove as a precaution. See the October 27, 07:50 UTC update.) Adoptium confirms how its October release handles eMudhra. On its October release tracker, an Adoptium maintainer explained that Temurin’s trust store comes from Mozilla’s root list, and that with the NSS 3.131.1 update the roots that signed the compromised intermediates have been removed. Together with the Jenkins tracking issue from our previous update, which lists 25.0.5+8 and 21.0.13+9 as fixed, that makes the root removal in those builds very likely. It’s still a root removal rather than the upstream blocked.certs fix, so the advice from the previous update stands: verify with keytool and the test hosts, and keep the blocked.certs entries if you use other trust stores.

A Temurin build with the upstream fix may have appeared for JDK 27. endoflife.date lists Temurin 27.0.1.0.2+1, dated October 24, matching the version number of the upstream fix. We couldn’t confirm it on Adoptium’s own pages yet, and Temurin 25 and 21 were still at 25.0.5+8 and 21.0.13+9, but it suggests Temurin builds of the .0.2 fix may follow for the LTS versions.

No change for Corretto, Oracle or OpenJDK since the previous update.

October 24, 2026, 11:40 UTC

(Clarified on October 27, 2026, 07:50 UTC: 25.0.5+8 removes the emSign root behind the compromised chains, but keeps emSign Root CA – G1, which OpenJDK and Oracle remove as a precaution. See the October 27, 07:50 UTC update.) Temurin 25.0.5+8 and 21.0.13+9 appear to include the root list update. The Jenkins project’s tracking issue for its container images marks Temurin 21.0.13+9 and 25.0.5+8 as fixed, citing the Temurin build change that updates the root list to NSS 3.131.1 and removes the emSign root. Because Temurin’s root list already leaves out AAA Certificate Services, removing the emSign root means Temurin’s default cacerts should reject both chains. Adoptium still hasn’t published release notes confirming this, and not every source agrees yet, so treat it as likely rather than confirmed.

This is a root removal, not the upstream blocked.certs fix, so it doesn’t protect custom trust stores that still contain either root. If you run Temurin, upgrade to 25.0.5+8 or 21.0.13+9, check that keytool -list -cacerts -storepass changeit | grep -i emsign returns nothing, run the test hosts for both chains, and keep the blocked.certs entries if you use any trust store other than the JDK’s own. Container tags may lag: on October 23, one project reported that eclipse-temurin:21-jre still resolved to 21.0.12.1, so check which JDK your image actually contains.

No change for Corretto, Oracle or OpenJDK since the previous update.

October 23, 2026, 19:24 UTC

eMudhra is leaving the TLS certificate business. According to Cybernews, eMudhra has withdrawn the eight certificates and is exiting its global TLS business, and around 30,000 legitimate website certificates from eMudhra will need to be replaced. That lowers the long-term cost of the root-removal layer this post recommends: sites still using eMudhra certificates have to move to another CA anyway. In the short term, though, removing the emSign root breaks connections to any endpoint that hasn’t switched yet, so check whether any service you call still uses an eMudhra certificate before you remove the root.

No change for Temurin, Corretto, Oracle or OpenJDK since the previous update. Corretto’s updated container images still hadn’t appeared when we checked.

October 23, 2026, 13:06 UTC

Corretto 25 also has the fix. The Corretto 25 changelog lists CVE-2026-91403 among the CVEs addressed in Corretto 25.0.5.0.9. Together with Corretto 21.0.13.0.10, that makes two Corretto versions with a confirmed fix. For Corretto 17, 11 and 8 we haven’t seen confirmation yet, so test before removing your workaround. As in the previous update, the Docker Hub images hadn’t been updated yet when we last checked, so the fixed builds are only available as downloads from Corretto’s GitHub releases for now.

No change for Temurin, Oracle or OpenJDK since the previous update.

October 23, 2026, 12:38 UTC

Amazon Corretto 21 has shipped the fix. A Corretto maintainer confirmed that Corretto 21.0.13.0.10, released October 23, fixes CVE-2026-91403, and that the Docker Hub and Amazon ECR images will be updated soon. The fixing commit is the upstream OpenJDK change JDK-8395142: it adds the compromised certificates to blocked.certs and generates the alternative signature encodings too, so it also covers the re-encoding bypass. It doesn’t remove the roots from cacerts.

Corretto published its other October releases the same day: 25.0.5.0.9, 17.0.21.0.10, 11.0.33.0.9 and 8.512.08.1. They’re likely built the same way, but we’ve only seen the fix confirmed for Corretto 21, so test the others against both kinds of test host before removing your workaround. If you use the Corretto container images, check the image tag’s build date: the images may lag behind the release.

(Updated October 29, 2026, 08:31 UTC: by October 28 the amazoncorretto:25 image contained the fixed build. See that update.) Where to get it today: the fixed Corretto 21 build is available now as JDK packages and archives from its GitHub release page, where Corretto publishes the download packages for each release. The container images aren’t there yet. When we checked the official amazoncorretto image on Docker Hub at 12:51 UTC on October 23, the newest Corretto 21 tag was still 21.0.12, and floating tags such as amazoncorretto:21 and 21-alpine still pointed to it. Until new tags appear, either install the JDK from the GitHub release in your own image, or keep the blocked.certs workaround on top of the current Corretto image.

No change for Temurin, Oracle or OpenJDK since the previous update.

October 23, 2026, 09:58 UTC

Temurin 25.0.5 and 21.0.13 are out, but they’re the October 20 versions, not the eMudhra fix. Adoptium’s Temurin 25 release list now shows jdk-25.0.5+8 as the latest official release, published October 22 at 08:18 UTC, and endoflife.date also lists 21.0.13+9 from the same day. Our 06:30 UTC update today, which called 25.0.5 a pre-release, was based on a third-party report and is out of date.

These builds match the October 20 updates, which Oracle and OpenJDK list as affected; the upstream eMudhra fix is in the later .0.2 builds. They may include Temurin’s updated root list, which would drop the emSign root, but Adoptium hasn’t published release notes saying so. Adoptium’s support page says it also releases out-of-band updates when OpenJDK does, so a separate fixed Temurin build may follow. Until it does, upgrade to 25.0.5 or 21.0.13 for the other October security fixes, keep the blocked.certs workaround in the image, and test both chains against the new build.

No change for Corretto, Oracle or OpenJDK since the previous update.

October 23, 2026, 08:12 UTC

Correction: BellSoft now recommends blocked.certs first. Our October 22, 10:13 UTC update said BellSoft recommended removing both roots. BellSoft has since revised its guidance (updated October 22): its recommended temporary mitigation is now adding the compromised certificates to blocked.certs, because that distrusts only the intermediates, with root removal as a broader alternative and revocation checking as an option. That’s the same order this post uses: blocked.certs first, root removal as the second layer.

Two notes on BellSoft’s guide. Its list has the 16 original fingerprints, not the re-encoded variants, so we still recommend this post’s 48-line list. And if you can’t modify the JDK installation, BellSoft shows how to delete the two roots from a copy of cacerts and point the JVM at it with javax.net.ssl.trustStore. BellSoft also says Liberica JDK updates that remove both roots are in preparation.

No change for Temurin, Corretto, Oracle or OpenJDK since the previous update.

October 23, 2026, 06:54 UTC

Oracle’s guidance gives revocation checking as an official alternative. Oracle’s guidance page, last updated on October 22, now lists two options for anyone who can’t upgrade yet: replace blocked.certs with Oracle’s file, or enable revocation checking with -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true. For signed JARs on JDK 17 and later, it recommends verifying with jarsigner -verify -revcheck -strict, which matters because two of the compromised intermediates were for code signing. We’ve added both to the Oracle section.

No change for Temurin, Corretto or OpenJDK since the previous update.

October 23, 2026, 06:30 UTC

Amazon confirms root removal for its Corretto packages, but the fix is still pending. The Amazon Linux security advisory CVE-2026-113470 says Amazon Linux will remove the affected eMudhra roots from its Corretto packages, and that chains through those roots won’t be trusted after the update. The Corretto 8, 11 and 17 packages for Amazon Linux 2, Amazon Linux 2023 and the Amazon Linux 2027 preview were still marked “Pending Fix”. This matches the approach in the open Corretto pull requests and in this post’s recommended second layer.

(Corrected on October 23 at 09:58 UTC: 25.0.5 is now an official release. See that update.) The Temurin 25.0.5 build is a pre-release. The jdk-25.0.5+8 build from our October 22, 15:08 UTC update is still listed as a pre-release, and Adoptium hasn’t announced its October release yet. The advice from that update still applies.

No change for Oracle or OpenJDK.

October 22, 2026, 15:08 UTC

A Temurin 25.0.5 build is appearing, but don’t assume it fixes this CVE. Search results for Adoptium’s Temurin 25 release list now show jdk-25.0.5+8, dated October 22, as the latest release. Our direct view of the same page still showed 25.0.4.1, so the release may still be rolling out, and the container image tags may lag behind it.

Version 25.0.5 is the October 20 scheduled update, which Oracle and OpenJDK list as still affected. The upstream fix is in the later 25.0.5.0.2 builds. Temurin’s October release was expected to include the updated Mozilla root list that drops the emSign root, which would close the emSign chain but not necessarily add the blocked intermediates. Before you remove the workaround from images that move to the new build, test both chains against it, and keep the blocked.certs entries unless the release notes confirm the full fix. The same applies to the other Temurin versions in the October release as they appear.

October 22, 2026, 14:28 UTC

Temurin’s October release will include an eMudhra change, but isn’t out yet. On Adoptium’s October 2026 release tracker (8u512, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1), a maintainer noted on October 21 that the release will pick up a change updating Temurin’s root list to NSS 3.131.1, the Mozilla release that removed emSign ECC Root CA – G3. Temurin’s root list is built from Mozilla’s, which already left out AAA Certificate Services. When we checked, the tracker showed no builds started, and a commenter’s question about whether the Sectigo cross-signed path is also handled had no public answer.

What this means: keep the workaround in place until the new Temurin build is out, and before you remove it, run the test hosts for both chains against the new build. If the release only removes the emSign root, keep the blocked.certs entries anyway, since they also protect custom trust stores that might still contain either root. We’ve added this check to the checklist.

October 22, 2026, 12:53 UTC

RHEL and UBI don’t have a fixed ca-certificates package yet. The post previously said updating ca-certificates is enough for Java from Linux distribution packages. That holds for Debian and Ubuntu, but as of October 22 Red Hat had not shipped a fixed package for RHEL or UBI images. Until it does, follow the workaround in Red Hat’s bulletin RHSB-2026-012, which distrusts the affected roots in the system trust store. We’ve corrected the distribution table.

No change for Temurin, Corretto, Oracle or OpenJDK releases since the previous update.

October 22, 2026, 12:01 UTC

The fingerprint list now covers re-encoded certificates. A package maintainer’s fix for their Temurin-based JDK packages blocks 48 fingerprints instead of 16: each certificate as issued, with the signature algorithm’s NULL parameter toggled, and for the ECDSA-signed ones with the signature value flipped from s to n − s. These are the same variants OpenJDK’s own tooling generates for blocked.certs, and they match the re-encodings in Sonatype’s bypass. Their build tests showed Java accepts the NULL-toggled copies, so a 16-line list leaves a working re-encoding of every certificate. We recomputed all 48 fingerprints from the public certificates and got exactly the same list, and we’ve replaced the list and the Dockerfile check in this post.

If you already deployed the 16-line list, add the 32 new lines and rebuild. Removing both roots still matters as a second layer.

No change for Temurin, Corretto, Oracle or OpenJDK releases since the previous update.

October 22, 2026, 10:45 UTC

Removing the roots from cacerts may not be enough on its own. A detailed guide from Safeguard points out that a JVM doesn’t always read cacerts. If the javax.net.ssl.trustStore property is set, the JVM uses that file instead, and if a jssecacerts file exists next to cacerts, it wins silently. Runtimes built with jlink carry their own frozen copy, and client libraries and application servers often take their own trust store path. Each of those needs the same root removal. We’ve added a section on this to the workaround and updated the checklist.

Test both chains. Because builds differ in which roots they ship, a JDK can reject the chain through the emSign root and still accept the one through AAA Certificate Services, or the other way round. Only a failure on both kinds of test host proves the fix. We’ve updated the verification step.

No change for Temurin, Corretto, Oracle or OpenJDK since the previous update.

October 22, 2026, 10:13 UTC

(Corrected on October 23: BellSoft has since changed its recommendation. See the October 23, 08:12 UTC update.) BellSoft (Liberica JDK) recommends removing both roots. In its guidance, BellSoft’s temporary mitigation is the same as the recommended second layer in this post: delete emSign ECC Root CA – G3 and AAA Certificate Services from cacerts. Liberica is more exposed than some other builds because its cacerts still contains the AAA root, and in BellSoft’s tests it accepted all twelve compromised test chains. Builds based on Mozilla’s root list, such as Temurin, don’t ship the AAA root and accepted only the six chains through the emSign root.

Root aliases differ between vendors. BellSoft notes that Liberica names the roots emsigneccrootcag3 [jdk] and comodoaaaca [jdk], while Temurin uses aliases that start with cn_emsign_ecc_root_ca__g3. Check each certificate’s subject with keytool -list -v before deleting anything. We’ve added this to the Dockerfile comments.

No change for Temurin, Corretto, Oracle or OpenJDK since the previous update.

October 22, 2026, 10:03 UTC

Azul Zulu has shipped a fix. Azul published an out-of-cycle release on October 21 for Zulu 6, 7, 8, 11, 17, 21, 25 and 27. It includes the upstream OpenJDK change JDK-8395142, which blocks the compromised intermediates in blocked.certs (blacklisted.certs on Java 8 and older), so no manual workaround is needed after upgrading. For installations that can’t be upgraded yet, Azul publishes a replacement block-list file and script.

Exploiting unpatched clients has become easier. According to SafeDep, mitmproxy 12.3.0, released on October 22, can sign intercepted traffic with a recovered eMudhra key, so an attacker who can intercept an affected client’s traffic doesn’t need custom tooling. CT log researchers also report that certificates for google.com signed with these keys are already public. An attacker still needs a position on the network path, but once there, the rest is off-the-shelf. We’ve updated the risk assessment in “What could be exploited” accordingly.

No change yet for Temurin and Corretto: neither had published a fixed release when we checked, and the Corretto pull requests were still open.

October 22, 2026, 09:45 UTC

Amazon Corretto has a proposed fix that goes further than blocking the eight intermediates. A set of community pull requests, one for each supported Corretto version (11, 17, 21 and 25), removes both roots involved from Corretto’s trust store: eMudhra’s emSign ECC Root CA – G3 and Sectigo’s AAA Certificate Services. The Corretto 17 pull request was opened first, on October 20, and the others followed on October 21. A Corretto maintainer replied on both the 17 and 21 pull requests that an urgent release is being prepared. All four were still open when we updated this post.

That matches what the rest of the ecosystem is doing. Mozilla removed the emSign ECC root in NSS 3.131.1 on October 20, and Chrome’s removal reaches all devices on October 27. Debian dropped both roots from its ca-certificates package. Chrome and Firefox already stopped trusting AAA Certificate Services for TLS before this incident.

Removing the two roots also closes the fingerprint-bypass gap described in “Why blocked.certs alone isn’t enough”, which a hand-edited blocked.certs can’t. We’ve updated the Dockerfile, the recommendations and the checklist: removing both roots is now the recommended second layer next to blocked.certs.

Sources

Credits

This post was written with the help of Claude, Anthropic’s AI assistant. Thanks to Maciej Pyszka, who worked out the blocked.certs workaround described above together with Claude.

Helm Charts upgrade script

In my homelab I’m running small Kubernetes cluster using k3s and install applications on it using Helm Charts. I don’t use gitops and for now I’m using Rancher to mostly navigate through all different types of Kubernetes objects. For a lot of Charts I’m using TrueCharts that contains ~800 different Charts and they’re using common libraries, templates and enjoy using it a lot. Because of that Charts are updated not only when docker image of application is being updated but also when common library is updated it could update a lot of Charts, so I get a lot of Helm Charts upgrades.

Upgrading every Helm Chart manually inside Rancher is fine when you need to update few of them every month. But with number of installed Helm Charts multiplied by frequency they’re updated it wasn’t feasible for me to do it that way. So I’ve built simple script that:

  • Iterates through helm ls, skips some exclusions (e.g. for rancher helm I run it manually because I update it together with k3s version)
  • checks if new Chart version is present
  • checks rollout status and ingress HTTP codes (to not upgrade application that’s not in healthy state)
  • ask if upgrade should be made (until --yes is not used)
  • check rollout status and ingress HTTP codes after upgrade (to know if maybe new Chart version broke something)

I’m not running it with --yes but still confirm every upgrade, at least for now. It saved me a lot of time and nerves. (;

You can check it’s code on GitHub.

Photos from Flickr on your craiglist/ebay listing

When I wan to sell some pre-owned stuff on ebay/craiglist/allegro/whatever I want it to have pictures of what I sell. I host my pictures on flickr and usually copied urls of them one-by-one to have thumbnail url and full size url in simple  html. I did 27 pictures of my MacBook and there’s no way that I’m gonna spend ~15 minutes coping those links instead code it in 2h, right? #overengineeredSolutions

 

Source code available at GitHub.

If you want to give me five and/or listen to my presentation in February (2016)

This would be (probably) my last presentation of “Lessons learned from scaling software” . I’m satisfied with last one I did on Devoxx, aside from low energy level (as caffeine kicked in way too late). This delivery will be on CareerCon IT carrier fairs and will be held in Polish. You can also join presentation by other geeks from our Company: Maciej just after me and Rafał during last conference slot.
Continue reading →