July 20, 2021
The full version string for this update release is 8u301-b09 (where "b" means "build"). The version number is 8u301.
JDK 8u301 contains IANA time zone data 2021a.
For more information, refer to Timezone Data Versions in the JRE Software.
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u301 are specified in the following table:
JRE Family Version | JRE Security Baseline (Full Version String) |
---|---|
8 | 8u301-b09 |
7 | 7u311-b07 |
Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.
Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u301) be used after the next critical patch update scheduled for October 19, 2021.
Java SE Subscription customers managing JRE updates/installs for large numbers of desktops should consider using Java Advanced Management Console (AMC).
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u301) on 2021-11-19. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.
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.
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:
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
This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 8u301 Bug Fixes page.