JDK 8u301 contains IANA time zone data 2021a.

For more information, refer to Timezone Data Versions in the JRE Software.

The support for the Kerberos MSSFU extensions [1] is now extended to cross-realm environments.

By leveraging the Kerberos cross-realm referrals enhancement introduced in the context of JDK-8215032, the 'S4U2Self' and 'S4U2Proxy' extensions may be used to impersonate user and service principals located on different realms.

[1] - https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94

New system and security properties have been added to enable users to customize the generation of PKCS #12 keystores. This includes algorithms and parameters for key protection, certificate protection, and MacData. The detailed explanation and possible values for these properties can be found in the "PKCS12 KeyStore properties" section of the java.security file.

Also, support for the following SHA-2 based HmacPBE algorithms has been added to the SunJCE provider: HmacPBESHA224, HmacPBESHA256, HmacPBESHA384, HmacPBESHA512, HmacPBESHA512/224, HmacPBESHA512/256

The following root certificates with weak 1024-bit RSA public keys have been removed from the cacerts keystore:

+ alias name "thawtepremiumserverca [jdk]"

  Distinguished Name: EMAILADDRESS=premium-server@thawte.com, 
  CN=Thawte Premium Server CA, OU=Certification Services Division, 
  O=Thawte Consulting cc, 
  L=Cape Town, ST=Western Cape, C=ZA

+ alias name "verisignclass2g2ca [jdk]"
  Distinguished Name: OU=VeriSign Trust Network, 
  OU="(c) 1998 VeriSign, Inc. - For authorized use only", 
  OU=Class 2 Public Primary Certification Authority - G2, 
  O="VeriSign, Inc.", C=US

+ alias name "verisignclass3ca [jdk]"
  Distinguished Name: OU=Class 3 Public Primary Certification Authority, 
  O="VeriSign, Inc.", C=US

+ alias name "verisignclass3g2ca [jdk]"
  Distinguished Name: OU=VeriSign Trust Network, 
  OU="(c) 1998 VeriSign, Inc. - For authorized use only", 
  OU=Class 3 Public Primary Certification Authority - G2, 
  O="VeriSign, Inc.", C=US

+ alias name "verisigntsaca [jdk]"
  Distinguished Name: CN=Thawte Timestamping CA, 
  OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA

+ alias name "gtecybertrustglobalca [jdk]"
  Distinguished Name:CN=GTE CyberTrust Global Root, 
  OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US 

The following root certificate has been removed from the cacerts truststore:

+ Telia Company

  + soneraclass2ca
    DN: CN=Sonera Class2 CA, O=Sonera, C=FI

The following capabilities have been removed from the list of what OracleJDK/OracleJRE RPMs provide: xml-commons-api, jaxp_parser_impl, and java-fonts. This clean-up of the list resolves existing and potential conflicts with modular RPMs.

There are other rpms providing these capabilities, so there should be no impact on packages that depend on them. Package managers can use other RPMs to satisfy the dependencies provided by the OracleJDK/OracleJRE RPMs before this change.

Client-side FTP support in the Java platform is available through the FTP URL stream protocol handler, now referred to as the FTP Client.

The following system property has been added for validation of server addresses in FTP passive mode.

• jdk.net.ftp.trustPasvAddress.

In this release, the FTP Client has been enhanced to reject an address sent by a server, in response to a PASV command from the FTP Client, when that address differs from the address which the FTP Client initially connected.

To revert to the prior behavior, the jdk.net.ftp.trustPasvAddress system property can be set to true. The affect of setting this property is that the FTP Client accepts and uses the address value returned in reply to a PASV command

On the macOS platform, custom URL protocol handlers such as Java WebStart (jnlp and jnlps URI schemes) are deregistered after an OS upgrade. If the Java WebStart application uses jnlp or jnlps URI scheme(s), it is recommended that you check their registration status after the OS upgrade. The registration status of the custom URL protocol handlers can be obtained via the 'lsregister' command.

For example:

lsregister -dump URLSchemeBinding | sort | grep 'jnlp|java|jar'

The Java WebStart protocol handler is registered and no-further action is required if the output of the above command contains the following lines:

jnlp: Java Network Launch Protocol (0x4680) (0x4682)
jnlps: Secure Java Network Launch Protocol (0x4684) (0x4686)

Otherwise, it is necessary to upgrade or reinstall the JRE in order to register the Java WebStart protocol.

The default encryption algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.

For compatibility, a new system property named keystore.pkcs12.legacy is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.

JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked.

In order to reduce the compatibility risk for applications that have been previously timestamped or use private CAs, there are two exceptions to this policy:

• Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted.
• Any JAR signed with a SHA-1 certificate that does not chain back to a Root CA included by default in the JDK cacerts keystore will not be restricted.

These exceptions may be removed in a future JDK release.

Users can, at their own risk, remove these restrictions by modifying the java.security configuration file (or overriding it using the java.security.properties system property) and removing "SHA1 jdkCA & usage SignedJAR & denyAfter 2019-01-01" from the jdk.certpath.disabledAlgorithms security property and "SHA1 jdkCA & denyAfter 2019-01-01" from the jdk.jar.disabledAlgorithms security property.

Certain TLS ALPN values couldn't be properly read or written by the SunJSSE provider. This is due to the choice of Strings as the API interface and the undocumented internal use of the UTF-8 character set which converts characters larger than U+00007F (7-bit ASCII) into multi-byte arrays that may not be expected by a peer.

SunJSSE now encodes/decodes String characters as 8-bit ISO_8859_1/LATIN-1 characters. This means applications that used characters above U+000007F that were previously encoded using UTF-8 may need to either be modified to perform the UTF-8 conversion, or set the Java security property jdk.tls.alpnCharset to "UTF-8" revert the behavior.

See the updated guide at https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/alpn.html for more information.

Client-side FTP support in the Java platform is available through the FTP URL stream protocol handler, henceforth referred to as the FTP Client.

The following system property has been added for validation of server addresses in FTP passive mode.

• jdk.net.ftp.trustPasvAddress.

In this release, the FTP Client has been enhanced to reject an address sent by a server, in response to a PASV command from the FTP Client, when that address differs from the address which the FTP Client initially connected.

To revert to the prior behavior, the jdk.net.ftp.trustPasvAddress system property can be set to true. The affect of setting this property is that the FTP Client accepts and uses the address value returned in reply to a PASV command