JDK-8194702 : pkcs12 can be loaded with null password but certificates are missing
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-01-06
  • Updated: 2022-05-27
  • Resolved: 2021-10-13
Related Reports
Blocks :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
keytool's default keystore type changed from jks to pkcs12.
BUT the cacerts file is still in jks format (why?)
There seems to be an attempt at jks/pkcs12 coexistence and compatibility (JEP 319).  So the cacerts file should work well if stored in either format.  But it only works in jks format.  Conversion to pkcs12 format results in silent failure.  But accidental conversion to pkcs12 is likely to be common because it's the new keytool default output format.

You can convert from jks to pkcs12 format as follows:
$ cd lib/security
$ cp -p cacerts cacerts.jks
$ rm -f cacerts; ~/jdk/jdk11/bin/keytool -importkeystore -srckeystore cacerts.jks -srcstorepass changeit -destkeystore cacerts -deststorepass changeit 

# Now the cacerts are broken!
# Let's specify jks format explicitly:

rm -f cacerts; ~/jdk/jdk11/bin/keytool -importkeystore -srckeystore cacerts.jks -srcstorepass changeit -destkeystore cacerts -deststorepass changeit -deststoretype jks

# Now they work again!

Here's a program that demonstrates the failure and is directly usable as a jtreg test:

/*
 * Copyright (c) 2018 Google Inc. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

import java.security.KeyStore;
import java.security.cert.X509Certificate;
import java.util.Arrays;
import javax.net.ssl.TrustManager;
import javax.net.ssl.TrustManagerFactory;
import javax.net.ssl.X509TrustManager;

/*
 * @test
 * @summary Sanity check trust manager defaults/cacerts.
 */

/**
 * Explores the set of root certificates.
 * Useful as a standalone program.
 *
 * Prior to JEP 319, completely stock openjdk fails this because no
 * root certificates were checked into the repo.
 */
public class CacertsExplorer {
    public static void main(String[] args) throws Throwable {
        String defaultAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
        if (!defaultAlgorithm.equals("PKIX"))
            throw new AssertionError(
                "Expected default algorithm PKIX, got " + defaultAlgorithm);

        TrustManagerFactory trustManagerFactory =
            TrustManagerFactory.getInstance(defaultAlgorithm);
        trustManagerFactory.init((KeyStore) null);
        TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
        if (trustManagers.length != 1)
            throw new AssertionError(
                "Expected exactly one TrustManager, got "
                + Arrays.toString(trustManagers));
        X509TrustManager trustManager = (X509TrustManager) trustManagers[0];

        X509Certificate[] acceptedIssuers = trustManager.getAcceptedIssuers();
        if (acceptedIssuers.length == 0)
            throw new AssertionError(
                "no accepted issuers - cacerts file configuration problem?");
        Arrays.stream(acceptedIssuers)
            .map(X509Certificate::getIssuerX500Principal)
            .forEach(System.out::println);
    }
}

Comments
I see. Let's hope it still passes after JDK-8162628 is resolved.
12-01-2018

I'll send a RFR, but note that the test is passing - it only fails on a JDK with cacerts keystore converted to PKCS12 format, which is easily corrected once you understand the problem.
12-01-2018

Martin, sure we can add it. You can even add more cases, for example, if password is wrong, throw an exception. I am not sure if we would fix it this way, but adding this case is not bad. Since the test is failing now, remember to add it into ProblemList.txt from the beginning. You can file another bug for this push.
11-01-2018

One thing we can do in the meantime is check in my jtreg test somewhere - what do you think?
11-01-2018

Workaround: -Djavax.net.ssl.trustStorePassword=changeit
11-01-2018

keyStore.getCertificate(alias) returns null when keystore is loaded with a null password. The spec says it can return "null if the given alias does not exist or does not contain a certificate". Does not really match.
08-01-2018

Weijun: any such difference between JKS and PKCS12 is non-obvious. Certainly keytool -list -cacerts insists on a storepass before returning any contents from a JKS cacerts. But the silence of the failure is the worst part. If you configure your jdk build using --with-cacerts-file giving a pkcs12 file, it will happily build you a non-working jdk.
08-01-2018

One huge difference between JKS and PKCS12 (as used by the current JDK) is that you can read certificates from a JKS without providing a storepass but this is not true for PKCS12.
08-01-2018