How to disable constraint check (Netscape cert type) in Java6?

Question

I am trying to build a custom HTTPS Server in Java (6) using the built in class com.sun.net.httpserver.HttpsServer. It works fine until I require client authentication. At t

Answer 1

You could wrap the default trust managers and catch this particular exception. This would be something along these lines:

class IgnoreClientUsageTrustManager extends X509TrustManager {
    private final X509TrustManager origTrustManager;
    public class IgnoreClientUsageTrustManager(X509TrustManager origTrustManager) {
        this.origTrustManager = origTrustManager;
    }

    public checkClientTrusted(X509Certificate[] chain, String authType
        throws IllegalArgumentException, CertificateException {
        try {
            this.origTrustManager.checkClientTrusted(chain, authType);
        } catch (ValidatorException e) {
             // Check it's that very exception, otherwise, re-throw.
        }
    }

    // delegate the other methods to the origTrustManager
}        

Then, use that trust manager to create an SSLContext and use it with your server.

TrustManagerFactory tmf = TrustManagerFactory.getInstance(
    TrustManagerFactory.getDefaultAlgorithm());
tmf.init((KeyStore)null);
TrustManager[] trustManagers = tmf.getTrustManagers();

for (int i = 0; i < trustManagers.length; i++) {
    if (trustManagers[i] instanceof X509TrustManager) {
       trustManagers[i] = IgnoreClientUsageTrustManager(trustManagers[i]);
    }
}

SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(... you keymanagers ..., trustManagers, null);

You should initialise your keymanagers from your server keystores (as normal). You should then be able to use the HttpsServer's HttpsConfigurator to set up the SSLContext (see example in the documentation).

This technique isn't ideal, though.

• Firstly, ValidatorException is in a sun.* package that's not part of the public API: this code will be specific for the Oracle/OpenJDK JRE.
• Secondly, it relies on the fact that the end entity checked (which verifies the key usage extension) happens after the rest of the trust validation (which makes it acceptable to ignore that exception, since you don't ignore other more fundamental checks this way).

You could of course re-implement your own validation instead, using the Java Certificate Path API, and ignoring only the key usage for this purpose. This requires a bit more code.

More generally, you're trying to bypass the specifications anyway, if you want to use a certificate for SSL/TLS as a client certificate when it doesn't have the right extension. The best fix for this is to amend your CA policy, which should be feasible if it's an internal CA anyway. It's quite common for server certificates to have the TLS client extended key usage set too, even with big CAs.