ansaurus

Question

Java SSL/TLS ignore expired cert? (java.security.cert.CertPathValidatorException: timestamp check failed)

Answer 1

A:

i think you can download the cert and add it to your store. You then configure your jvm with environment properties to indicate where the store is.

hvgotcodes 2010-09-08 17:48:25

that is already what i am doing. the problem is that the cert has expired, and causing the exception. i was hoping there is some property you can set to ignore expired keys.

wuntee 2010-09-08 18:27:28

Answer 2

+1 A:

I'm not aware of a property that would let you ignore the time validity check on the remote certificate for the default X509TrustManagers, but if you have access to the client code, you can probably configure a different SSLContext with your own X509TrustManager, within which you could catch this exception.

If you want to use something like jSSLutils and its SSLContextFactory, you could write a wrapper along these lines:

PKIXSSLContextFactory sslContextFactory = new PKIXSSLContextFactory();
sslContextFactory.setTrustManagerWrapper(new X509TrustManagerWrapper() {
    @Override
    public X509TrustManager wrapTrustManager(final X509TrustManager origManager) {
        return new X509TrustManager() { 
            @Override
            public X509Certificate[] getAcceptedIssuers() {
                return origManager.getAcceptedIssuers();
            }

            @Override
            public void checkServerTrusted(X509Certificate[] chain,
                                                   String authType)
                    throws CertificateException {
                try {
                    origManager.checkServerTrusted(chain, authType);
                } catch (CertificateExpiredException e) {
                    // TODO log or do something else to rethrow
                                    // the exception if chain[0] isn't the certificate
                                    // for which you want to make this special case.
                }
            }

            @Override
            public void checkClientTrusted(X509Certificate[] chain,
                                                   String authType)
                    throws CertificateException {
                origManager.checkClientTrusted(chain, authType);
            }
        };
    }
});
SSLContext sslContext = sslContextFactory.buildSSLContext();

Making use of this SSLContext then really depends on what uses SSL in your application. In the worst case, you can configure it globally using SSLContext.setDefault(sslContext) with Java 6 and above. Otherwise, some libraries will let you configure an SSLContext.

Bruno 2010-09-08 19:21:38

Answer 3

+2 A:

It is not safe to alter the default SSLContext since it affects the entire process. This lowers the security setting of every connection indiscriminately. It may also not be thread-safe although I am not sure.

I recommend delegating such operations to a separate process per-request.

String content = new HttpsNoVerify.fetch(URL.create(myURL));

Listing of com/example/HttpsNoVerify.java:

package com.example;

import org.apache.commons.io.IOUtils;

import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;
import java.net.URL;

public class HttpsNoVerify {
    public static void main(String... args) throws Exception {
        URL url = new URL(args[0]);

        TrustManager[] trustAllCerts = new TrustManager[]{
            new X509TrustManager() {
                public java.security.cert.X509Certificate[] getAcceptedIssuers() {return null;}
                public void checkClientTrusted(java.security.cert.X509Certificate[] certs, String authType){}
                public void checkServerTrusted(java.security.cert.X509Certificate[] certs, String authType){}
            }
        };

        SSLContext sc = SSLContext.getInstance("SSL");
        sc.init(null, trustAllCerts, new java.security.SecureRandom());
        HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

        IOUtils.copy(url.openStream(), System.out);
    }

    public String fetch(URL url) throws Exception {
        return new SubProcess(HttpsNoVerify.class).run(url.toString());
    }
}

Listing of com/example/SubProcess.java:

package com.example;

import org.apache.commons.io.IOUtils;

import java.util.Arrays;

public class SubProcess {
    private final Class<?> classToRun;

    public SubProcess(Class<?> classToRun) {
        this.classToRun = classToRun;
    }

    public String run(String... args) throws Exception {
        ProcessBuilder processBuilder = new ProcessBuilder("java",
                "-Djava.library.path=" + System.getProperty("java.library.path"),
                "-classpath", System.getProperty("java.class.path"),
                classToRun.getCanonicalName());

        for (String arg : args) processBuilder.command().add(arg);

        processBuilder.redirectErrorStream();

        Process process = processBuilder.start();

        String output = IOUtils.toString(process.getInputStream());

        process.waitFor();

        if (process.exitValue() != 0)
            throw new IllegalStateException(
                    String.format("Running %s with %s failed", classToRun, Arrays.toString(args)));

        return output;
    }
}

Alain O'Dea 2010-09-08 19:40:36

I suppose you mean "It is not safe to alter the *default* SSLContext", with which I'd agree.

Bruno 2010-09-08 20:05:34

I have added the code I use - I tried to create the new trust manager, but was getting a "javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown" exception...

wuntee 2010-09-08 20:26:19

Sorry, I am thinking this exception is coming from the server. Specifically it is: org.apache.thrift.transport.TTransportException: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown

wuntee 2010-09-08 20:45:42

Thinking that that 'certificate_unknown' exception is the client side... any idea why that would be being thrown?

wuntee 2010-09-08 21:51:42

@wuntee, I would *strongly* recommend against using this `TrustManager`, which doesn't check anything about any server certificate this client may connect to. Instead, you could use the variant I suggested in my answer where (a) you only catch the `CertificateExpiredException` and (b) potentially ignore it once you've verified this was the certificate you wanted (from `chain[0]`).

Bruno 2010-09-08 22:42:39

@wuntee @Bruno's TrustManager is definitely preferable to the no-op one I use here. I would combine my process-based approach with his TrustManager to get a holistic solution.

Alain O'Dea 2010-09-09 12:17:17

i was going to add more logic, initially i was just trying to get it working... thanks

wuntee 2010-09-09 14:57:39

@Alain, one of the motivations for writing jSSLutils and its wrappers was to be able to use the existing trust managers (with minimal configuration), while being able to catch and handle certain cases and exceptions. It just makes it slightly easier to use I think, by being able to access the "origManager" in my example (which would be the one set up without specific settings here.

Bruno 2010-09-10 11:07:28

ansaurus

tags:

views:

answers:

Java SSL/TLS ignore expired cert? (java.security.cert.CertPathValidatorException: timestamp check failed)

related questions