2

I have a X509 certificate (java.security.cert.X509Certificate) and I need to verify it. The trusted anchor is already in system default certstore ( jre\lib\security\cacerts ) but I could populate it into something else if needed. The certificate is not a SSL certificate.

My first idea was to use Java's trust manager as I am already using HTTPs with server certificates issued by the same CA. But it seems that this can be used only for SSL certifictaes as it provides only checkServerTrusted and checkClientTrusted. For sake of completness, this is my attempt:

X509TrustManager x509TrustManager=null;
trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init((KeyStore)null);
for (TrustManager trustManager : trustManagerFactory.getTrustManagers()) 
{  
    if (trustManager instanceof X509TrustManager) 
     {  
       x509TrustManager = (X509TrustManager)trustManager;
     }  
}
java.security.cert.X509Certificate x509 = .... get certificate ...
x509TrustManager.checkServerTrusted(new java.security.cert.X509Certificate[]{x509}, "RSA");

This does all I need but in addition it checks whether the certificate is valid for SSL server (or client if I use checkClientTrusted) and that obviously fails.

Is there any simple way how to specify the cert and/or key usage for the trust manager or at least a way how to disable the check (I can do it myself).

In the future I would like to use OCSP or CRL list to check the actual state of the certificate.

Radek Hladík
  • 547
  • 4
  • 15
  • 1
    http://stackoverflow.com/questions/2457795/x-509-certificate-validation-with-java-and-bouncycastle/2458343#2458343 – salyh May 04 '14 at 20:37
  • Solution from http://stackoverflow.com/questions/2457795/x-509-certificate-validation-with-java-and-bouncycastle/2458343#2458343 worked. – Radek Hladík May 04 '14 at 23:11
  • "I have a X509 certificate ... the certificate is not a SSL certificate" - that's somewhat confusing. Both [X.509](https://www.itu.int/rec/T-REC-X.509/en) and [PKIX](http://www.ietf.org/rfc/rfc5280.txt) have nearly identical standards - key usage, extended key usage, policies, subject alternative name, issuer alternative name, constraints, etc. What key usage and policies are different? – jww May 13 '14 at 05:57
  • That means, that the certificate does not have SSLServer or SSLClient usage. And the trustManager has methods for validating only these two usages. So the trustManager verifies the certificate correctly but fails on keyUsage mismatch. The usage (timestamping) is specified correctly in the certificate (and so is the policyID) and I am able to verify that myself. – Radek Hladík May 14 '14 at 10:32

0 Answers0