Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Java eMudhra certificate mitigation and custom truststore guidance

Aperta Adatta ai principianti
#905 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
68/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
azure, java

Direzione di ricerca

L’issue fornisce indicazioni per mitigare il problema del certificato e configurare un truststore personalizzato, inclusi comandi keytool e la configurazione della JVM per Azure Functions. Inizia controllando le indicazioni esistenti nel repository sui certificati Java e sulle impostazioni della JVM, quindi confrontale con i dettagli dell’incidente e i riferimenti in questa issue. Il lavoro è completo quando la documentazione pertinente spiega chiaramente la mitigazione, le operazioni per il truststore personalizzato, le indicazioni sul riavvio e i limiti dei flag di revoca.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Annoucement Documentation java

Mitigation status

Azure Functions has rolled out an initial mitigation for the eMudhra certificate incident. It has been verified across all supported Java versions on Flex Consumption, Linux Consumption and Linux Dedicated.

The initial mitigation already protects applications using the default managed Java truststore. It removes the three root certificates listed below and blocks compromised intermediate certificates, including cross-signed variants.

Customers do not need to change Java versions or add JVM flags to activate this protection. The initial mitigation updates certificate files without changing the Java version number, so an app reporting Java 25.0.3 can already be protected.

A follow-up update is expected to deploy over the next 24 hours. It adopts Microsoft OpenJDK 17.0.21.0.2, 21.0.13.0.2 and 25.0.5.0.2, while retaining platform-applied mitigation for Java 8 and 11. It also expands intermediate-certificate blocking to cover additional certificate encodings.

This adds protection for applications using custom truststores with standard JDK certificate validation, including those that have not yet removed the affected certificates. It does not modify customer-owned truststores or guarantee protection for libraries that bypass standard JDK validation. Custom truststore users should still take the steps below rather than wait for the update.

Restart your function app to pick up the updated managed runtime image available in your region. For the follow-up update, restart after it becomes available. A restart does not make an update available before it reaches your region, and it does not modify custom truststores.

Action required for custom truststores

If your application uses javax.net.ssl.trustStore, bundled CA certificates or a library-specific trust manager, review the trust configuration actually used by each TLS client.

Ensure these certificates are not present as trusted CA entries. Match the SHA-256 fingerprint, not just the name or alias.

Certificate SHA-256 fingerprint
AAA Certificate Services D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4
emSign ECC Root CA-G3 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B
emSign Root TLS CA-G3 7DD78D5F4F13459A83DFF9ABBBA62EDBAF6F2D102BF257FD712F4D9F2746ED8D

AAA Certificate Services is included because the affected intermediates also have cross-signed paths through that root. This does not mean all Sectigo roots are affected.

For a JKS or PKCS12 truststore, back up the store and inspect a copy. Let keytool prompt for the password:

keytool -list -v -keystore /path/to/custom-truststore

After matching the fingerprint, remove the entry using its actual alias:

keytool -delete -alias <verified-alias> -keystore /path/to/custom-truststore

Remove any directly trusted compromised intermediates identified in the upstream guidance as well. Removing intermediate entries alone is not a substitute for the runtime blocklist, because certificates can also arrive in a server-provided chain.

Test required TLS connections before deploying the revised store, then reload the clients that use it. Root removal can also affect legitimate chains. Work with the endpoint’s certificate provider to replace affected chains rather than restoring the removed anchors.

JVM configuration

Use languageWorkers__java__arguments on Flex Consumption and Linux Consumption. Use JAVA_OPTS on Premium and Dedicated plans.

The flags below enable revocation-related behavior for applicable Java validation paths:

-Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true

They are not equivalent to the incident certificate blocklist and should not be relied on as the sole mitigation. No additional JVM flags are required to activate the platform-applied certificate mitigation.

Applications using custom truststores or custom TLS validation must still review their effective trust configuration as described above. Do not disable certificate validation or modify the platform-managed JDK.

References

For app-specific questions, contact Azure Support. Do not post subscription IDs, truststore passwords, private keys or other customer-sensitive details in this public issue.

Lingua principale
Java
Stelle
103
Fork
74
Merge medio
4g 15h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Azure/azure-functions-java-worker

Tutte le issue di Azure/azure-functions-java-worker

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.