JDK-8227395 : Remove the deprecated javax.security.cert APIs
  • Type: CSR
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P3
  • Status: Draft
  • Resolution: Unresolved
  • Fix Versions: 19
  • Submitted: 2019-07-08
  • Updated: 2022-04-23
Related Reports
CSR :  
JDK-8227024 - Remove the deprecated javax.security.cert APIs
Description
Summary
-------
Remove the deprecated javax.security.cert APIs.

Problem
-------
The legacy javax.security.cert APIs and the dependent APIs were initially deprecated in Java SE 9 and targeted for removal in Java SE 13.  Delays pushed the removal target to JDK 19.  Applications should migrate the java.security.cert APIs.

We included the javax.security.cert in JDK 1.4 (circa 2002) due to backwards compatibility concerns with the unbundled JSSE release for JDK 1.2/1.3, but have always encouraged everyone not to use this API from day 1.

> Note: The classes in the package javax.security.cert exist for compatibility with earlier versions of the Java Secure Sockets Extension (JSSE). New applications should instead use the standard Java SE certificate classes located in java.security.cert. 

Solution
--------
Remove the deprecated javax.security.cert APIs and public APIs that depends on them.

Specification
-------------
The javax.security.cert package will be removed, which include the following classes:

 - Certificate
 - CertificateEncodingException
 - CertificateException
 - CertificateExpiredException
 - CertificateNotYetValidException
 - CertificateParsingException
 - X509Certificate

The following methods that depend on javax.security.cert will be removed:

> javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()

    - 
    -    /**
    -     * Returns the identity of the peer which was identified as part
    -     * of defining the session.
    -     * Note: This method can be used only when using certificate-based
    -     * cipher suites; using it with non-certificate-based cipher suites,
    -     * such as Kerberos, will throw an SSLPeerUnverifiedException.
    -     * <P>
    -     * Note: The returned value may not be a valid certificate chain
    -     * and should not be relied on for trust decisions.
    -     *
    -     * <p><em>Note: this method exists for compatibility with previous
    -     * releases. New applications should use
    -     * {@link #getPeerCertificates} instead.</em></p>
    -     *
    -     * @return an ordered array of peer X.509 certificates,
    -     *          with the peer's own certificate first followed by any
    -     *          certificate authorities.  (The certificates are in
    -     *          the original JSSE
    -     *          {@link javax.security.cert.X509Certificate} format).
    -     * @exception SSLPeerUnverifiedException if the peer is not verified.
    -     * @see #getPeerPrincipal()
    -     * @deprecated The {@link #getPeerCertificates()} method that returns an
    -     *               array of {@code java.security.cert.Certificate} should
    -     *               be used instead.
    -     */
    -    @SuppressWarnings("removal")
    -    @Deprecated(since="9", forRemoval=true)
    -    public javax.security.cert.X509Certificate [] getPeerCertificateChain()
    -            throws SSLPeerUnverifiedException
    -    {
    -        return session.getPeerCertificateChain();
    -    }


> javax.net.ssl.SSLSession.getPeerCertificateChain()
 
    -    /**
    -     * Returns the identity of the peer which was identified as part
    -     * of defining the session.
    -     * <P>
    -     * Note: This method can be used only when using certificate-based
    -     * cipher suites; using it with non-certificate-based cipher suites,
    -     * such as Kerberos, will throw an SSLPeerUnverifiedException.
    -     * <P>
    -     * Note: The returned value may not be a valid certificate chain
    -     * and should not be relied on for trust decisions.
    -     *
    -     * <p><em>Note: this method exists for compatibility with previous
    -     * releases. New applications should use
    -     * {@link #getPeerCertificates} instead.</em></p>
    -     *
    -     * @return an ordered array of peer X.509 certificates,
    -     *          with the peer's own certificate first followed by any
    -     *          certificate authorities.  (The certificates are in
    -     *          the original JSSE certificate
    -     *          {@link javax.security.cert.X509Certificate} format.)
    -     * @exception SSLPeerUnverifiedException if the peer's identity
    -     *          has not been verified
    -     * @see #getPeerPrincipal()
    -     * @deprecated The {@link #getPeerCertificates()} method that returns an
    -     *               array of {@code java.security.cert.Certificate} should
    -     *               be used instead.
    -     */
    -    @SuppressWarnings("removal")
    -    @Deprecated(since="9", forRemoval=true)
    -    public javax.security.cert.X509Certificate [] getPeerCertificateChain()
    -            throws SSLPeerUnverifiedException;
    -
Comments
Apps like IntelliJ use Netty libraries. Running IntelliJ idea with the removed `javax.security.cert` packages is causing the Netty `ResourceLeakDetector` code to crash, since `io.netty.util.internal.EmptyArrays` can't be loaded due to the missing package. Unfortunately, `javax.security.cert` is pretty tightly wound into Netty, likely to support the OpenSSL calls. There is a mix of `java.security.cert` and `javax.security.cert` throughout the code. This will take some careful removal. https://github.com/netty/netty Searching for `javax.security.cert` ./common/src/main/java/io/netty/util/internal/EmptyArrays.java ./example/src/main/java/io/netty/example/ocsp/OcspClientExample.java ./handler/src/main/java/io/netty/handler/ssl/ExtendedOpenSslSession.java ./handler/src/main/java/io/netty/handler/ssl/OpenSslSessionCache.java ./handler/src/main/java/io/netty/handler/ssl/ReferenceCountedOpenSslEngine.java (used in DefaultOpenSSLSession) ./handler/src/main/java/io/netty/handler/ssl/util/LazyJavaxX509Certificate.java (used by above) ./handler/src/test/java/io/netty/handler/ssl/SSLEngineTest.java (test case)
21-04-2022
Whether we remove just the SSLSession/HandshakeCompletedEvent or include the javax.security.cert package, this removal has been talked about for 5+ years, during which we've already taken intermediate steps (JDK-8241039). We've been discouraging folks from using these APIs since they went into JDK 1.4. At some point, any removal is going to force 3rd party changes for source compatibility, and IMHO, forcing two similar changes over two releases is stretching out the pain. At some point, we need to rip this band-aid off, and IMHO, I'd like to do it all at once rather than do a little then wait another 2 years to complete the job. Now (after LTS 17) seems like a good time to do it. We could neuter the Certificate/X509Certificate constructors which will affect binary compatibility, but that will add another couple years to this sunset.
09-04-2022
It looks like this removal will be disruptive, esp. with projects that want to compile or be used across a broad range of JDK releases. The Grizzly framework is used in SPECjbb2015 for example, will it mean that this benchmark will no longer run on JDK main line? How disruptive would it be to remove SSLSession.getPeerCertificateChain and HandshakeCompletedEvent.getPeerCertificateChain and leave javax.security.cert in place? How disruptive would it be to neuter javax.security.cert.Certificate and X509Certificate by having their constructors throw? Asking to see if there additional steps that dial-up the degradation without too much disruption.
28-01-2022
## Potentially Impacted Third Party Projects ## This is not a complete list, but we should socialize this with some of these maintainers in addition to the standard CSR/JCP processes. Some of these libraries have already been taking our advice into account and removing dependence on javax.security.cert, but some are still overriding SSLSession/HandshakeCompletedEvent to work with older releases. (This list included notes to myself: apologies if any info is incorrect here.) - Apache commons-httpclient/commons-httpclient/3.1 - The Commons HttpClient project has end-of-lifed, and is no longer being developed. It has been replaced by the Apache HttpComponents project in its HttpClient and HttpCore modules, which offer better performance and more flexibility. - io.netty/netty-all/4.1.25.Final - Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers and clients. (The Netty Project) - io.undertow/undertow-core/2.2.3.Final - Undertow is a flexible performant web server written in java, providing both blocking and non-blocking API’s based on NIO. The gives you the flexibility to choose between a full Java EE servlet 4.0 container, or a low level non-blocking handler, to anything in between….Undertow is sponsored by JBoss and is the default web server in the Wildfly Application Server. - io.vertx/vertx-core/4.0.0 - Sonatype helps open source projects to set up Maven repositories on https://oss.sonatype.org/ (Eclipse) - org.apache.tomcat/tomcat-coyote/10.0.0 - Tomcat Connectors and HTTP parser - Glassfish and Grizzly - org.glassfish.grizzly/grizzly-core/3.0.0 - org.glassfish.grizzly/grizzly-framework/3.0.0 - org.glassfish.grizzly/grizzly-http-server-core/3.0.0 - org.glassfish.grizzly/grizzly-websockets-server/3.0.0 - Grizzly Bill of Materials (BOM) (Oracle Corporation) - [Bouncy Castle][1] - [Google Conscrypt][2] - [android-cpp-sdk][3] - [Android libcore][4] - [javasqlite][5] - apache-harmony test suite (Likely retired) [1]: https://www.bouncycastle.org/ [2]: http://github.com/google/conscrypt [3]: https://code.google.com/archive/p/android-cpp-sdk/ [4]: https://android.googlesource.com/platform/libcore/ [5]: http://www.ch-werner.de/
28-01-2022
Reopening this issue. Enough time has passed and we're at a good spot Post-17 (LTS).
27-01-2022
I will make an update in a new bug by having default getPeerCertificateChain() method , throwing exception in the default implementation, and removing the real implementation in the SunJSSE provider and httpclient. As would reduce the compatibility risks. We may come back to this enhancement and CSR in a few years (after JDK 17 at least).
14-03-2020
I think we need to explore the option that changes SSLSession:: getPeerCertificateChain to be a default method that throws UOE, also changing HandshakeCompletedEvent:: getPeerCertificateChain to throw UOE. That should be source compatible. The cleanup in the webrev (like the removal of X509V1CertImpl and override in SSLSessionImpl) could go ahead.
14-03-2020
[~alanb] Third party JSSE providers, like Bouncy Castle, may implement the getPeerCertificateChain(). There is compile impact if the provider want to support prior JDK releases. It has been a while that this method is marked as deprecation. I'd like to move forward sooner and see what the real impact is, before we move forward to the next long term release. JDK 15 may be the only release we want to test with for the compatibility impact. We can revert back or look for alternative solutions if there are serious issues in practice. JDK 16 is too close to the next long term release, for properly testing and provider update.
13-03-2020
Do we have any sense as what libraries implement javax.net.ssl.SSLSession? I suspect removing getPeerCertificateChain from that interface will be problematic for libraries that expect to compile and test on multiple JDK releases.
13-03-2020