JDK 27 Security Enhancements

JDK 27 was released on September 15, 2026! As with my previous blogs, I have compiled a list of what I think are the most interesting and useful security enhancements in this release. I have also grouped them into appropriate categories (crypto, TLS, etc) which should make it easier to find out what has changed in each specific area. The JDK 27 release notes also contain further details on these and other enhancements.

Highlights of this release include TLS 1.3 support for post-quantum hybrid key exchange mechanisms, and a third preview of the PEM API.

Table of Contents

1. Crypto
2. PKI
3. TLS
4. Tools

Crypto

• JEP 538: PEM Encodings of Cryptographic Objects (Third Preview)

  JDK 27 includes the third preview API for encoding and decoding cryptographic objects to/from the PEM format which was defined in JEP 538. PEM is a widely used format for transferring and storing DER-encoded cryptographic data such as certificates, CRLs, private keys, and more. This was one of the most commonly requested features in a JCE survey a few years ago. The History section of the JEP contains a list of changes since the second preview.

  There are two primary APIs, a PEMEncoder class for encoding cryptographic objects to PEM, and a PEMDecoder class for decoding PEM data into cryptographic objects. In this version, the DEREncodable interface has been renamed to BinaryEncodable to better reflect its usage and that it is not restricted to DER encodings. Existing classes such as X509Certificate and X509CRL have been retrofitted to implement this interface, thereby making it easier to encode/decode these objects to/from PEM.

  PEMEncoder can also be configured for encryption which makes it easier to encrypt and encode private keys in one step. Similarly, PEMDecoder can be configured for decryption to allow private keys to be decoded and decrypted in one step. For more advanced usage, the existing EncryptedPrivateKeyInfo class has been enhanced with several new methods that make it easier to encrypt and decrypt private keys.

  Here is an example of encoding an X509Certificate retrieved from a KeyStore to PEM:

      X509Certificate cert = (X509Certificate)keystore.getCertificate("mycert");
      PEMEncoder encoder = PEMEncoder.of();
      String pem = encoder.encodeToString(cert);
  

  Here is an example of decoding the PEM back into an X509Certificate:

      PEMDecoder decoder = PEMDecoder.of();
      X509Certificate cert = decoder.decode(pem, X509Certificate.class);
  

  Here are two examples of encrypting a PrivateKey with a password and then encoding it into PEM. This example uses a PEMEncoder configured for encryption:

      PEMEncoder encoderWithEncryption = PEMEncoder.of().withEncryption(password);
      String pem = encoderWithEncryption.encodeToString(privateKey);
  

  The above example uses default parameters when encrypting. This second example uses the EncryptedPrivateKeyInfo class and encrypts the private key with additional parameters such as the password-based encryption algorithm, and then encodes it to PEM:

      EncryptedPrivateKeyInfo epki =
          EncryptedPrivateKeyInfo.encrypt(privateKey, password,
              "PBEWithHmacSHA256AndAES_256", null, null);
      String pem = PEMEncoder.of().encodeToString(epki);
  

• Support for Additional Parameter Sets for the HSS/LMS Signature Algorithm

  The HSS/LMS Signature algorithm implementation now supports additional parameter sets as defined in RFC 9858, in addition to those defined in RFC 8554. This RFC introduces new parameter sets for LMS/HSS that use SHA-256/192 (truncated output) and SHAKE-based hash functions (SHAKE256/256 and SHAKE256/192). These new parameter sets can produce smaller signatures.

  Note that the HSS/LMS KeyFactory and Signature implementations only support public keys and signature verification.

  Issue: JDK-8369917

• New KeyStore and KeyStoreSpi Methods to Retrieve Alias Creation Date as an Instant

  Two new methods have been added to the KeyStore and KeyStoreSpi APIs that return the date a keystore alias was created as an Instant object. These methods can be used instead of the methods that return the creation dates as a Date object. Instants are immutable and can be used more readily with other APIs in the java.time package. The new methods are the following:

  • KeyStore.getCreationInstant(String)
  • KeyStoreSpi.engineGetCreationInstant(String)

  Issue: JDK-8374808

• Various Performance Improvements

  A number of significant performance improvements to the SHA-3, ML-KEM, ML-DSA, and Elliptic Curve (X25519, Ed25519) algorithms were made. See the following release notes for more details:

  • 8386238
  • 8381393

  Shawn Emery wrote an informative blog with more details and performance numbers on the Curve25519 improvements made in JDK 27. The blog also covers additional improvements targeted to JDK 28.

PKI

• New Root CA Certificates

  New root CA certificates have been added to the cacerts keystore:

  • Two WISeKey root CA certificates:
    • WISeKey Global Root GB CA with the following distinguished name:
      CN=OISTE WISeKey Global Root GB CA, OU=OISTE Foundation Endorsed, O=WISeKey, C=CH
    • WISeKey Global Root GC CA with the following distinguished name:
      CN=OISTE WISeKey Global Root GC CA, OU=OISTE Foundation Endorsed, O=WISeKey, C=CH

    These root certificates have also been added to the cacerts keystore in Oracle’s JDK 25.0.4, 21.0.12, 17.0.20, 11.0.32, and 8u501 releases.

    Issue: JDK-8372351

TLS

• JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3

  JDK 27 now supports post-quantum hybrid key exchange for TLS 1.3! This is a significant feature that builds on the ML-KEM post-quantum algorithm that was introduced in JDK 24.

  This feature combines classical and post-quantum key exchange algorithms in a hybrid approach and protects against the harvest now, decrypt later risk. A hybrid scheme combines both a traditional and a post-quantum algorithm and is secure as long as one of those algorithms remains unbroken.

  We have added support for the 3 hybrid groups that have been defined by the IETF in RFC 10024: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. These combine the quantum-resistant ML-KEM algorithm with traditional elliptic-curve algorithms.

  The X25519MLKEM768 group is enabled by default. This feature works out of the box. No API or configuration change is needed, as long as both peers support the X25519MLKEM768 group, which is the most widely deployed hybrid group.

  To use one of the other groups, you can set the system property jdk.tls.namedGroups or use the SSLParameters.setNamedGroups() API.

  Jamil Nimeh wrote an informative blog with additional details on this feature and examples showing how to customize the supported groups.

  This feature will also be backported to Oracle’s JDK 25 update release in October 2026. We have also announced plans to backport the feature to Oracle’s JDK 21, 17, 11, and 8 update releases – see the Java Cryptographic Roadmap for more details and also Aurelio Garcia-Ribeyro’s blog on Post-Quantum Cryptography in Long-Term Support JDK Releases.

• Added Support for ZLIB TLS Certificate Compression

  Certificate chains exchanged via TLS 1.3 handshakes are now compressed using the zlib compression algorithm. This feature is enabled by default but can be disabled by adding the compress_certificate extension to the jdk.tls.client.disableExtensions and jdk.tls.server.disableExtensions system properties.

  Issue: JDK-8372526

• Removal of ffdhe6144 and ffdhe8192 from the Default List of TLS Named Groups

  The ffdhe6144 and ffdhe8192 named groups have been removed from the list of TLS named groups that are enabled by default. These groups are rarely used in practice, so the compatibility risk should be minimal. Applications can still use these groups by setting them with the system property jdk.tls.namedGroups or by calling the SSLParameter.setNamedGroups method when configuring a TLS socket connection.

  Issue: JDK-8373426

• Chunghwa TLS Server Certificates Distrusted

  The JDK will no longer trust TLS Server certificates issued by Chunghwa. TLS Server certificates issued before March 17, 2026 will continue to be trusted until a later date or they expire. Certificates issued after that date will be rejected. See the release note for more information and the Certificate Authority that is affected.

  This change has also been made in Oracle’s JDK 25.0.3, 21.0.11, 17.0.19, 11.0.31, and 8u491 releases.

  Issue: JDK-8369282

Tools

• New Security Property to Allow Passwords to be Read from the Standard Input Stream

  A new security property named jdk.security.password.allowSystemIn has been added that, when set to true allows passwords to be read from the standard input stream when a console is not available. The default value is true – however, this default may change to false in a future release.

  See the release note for more details, including usages where this property can be useful.

  Issue: JDK-8368692