Skip to main content

Setting a Certificate Revocation List

13 replies [Last post]
jcstover
Offline
Joined: 2007-11-01

Using Mutual certificates Security with Metro 1.4, my own root-ca is the only trusted certificate. All certificates I singed are trusted. When I revoke a certificate a can create a Certificate Revocation List to store those revoked certificates.

But I cannot specify this list in glassfish. I can but on revocationEnabled for the ValidatorConfiguration, but nowhere I can find what is going to happen if it is put on.

Basic question how to enable the use of revocation list when using WS-Security with Mutual Certificates.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jcstover
Offline
Joined: 2007-11-01

I'm not sure if it is correct, but my root ca holds a crldistributionpoint and I have signed the certificates with it. I finally got my certificates working.

BUT
revocationEnabled doesn't do anything. Metro 1.4 is installed on glassfish prior to domain creation. The webserver where the crl stands shows no requests for the crl file.

So I gonna dig into it today. If you have any suggestions please let me know.

kumarjayanti
Offline
Joined: 2003-12-10

It is the client cert which needs to have the crldistributionpoint info.

Can i see your service config which has the validatorconfiguration.

The last time my team member tested this feature (revocationEnabled), he mentioned it does work. Let me try a sample on my own and get back.

jcstover
Offline
Joined: 2007-11-01

It was only in the root CA not in the client certificate. Gonna recreate the certificates and try it again.

In my search I found that the system property com.sun.security.enableCRLDP=true needs to be set in order to make it work. Can you confirm this.

Johan

jcstover
Offline
Joined: 2007-11-01

Client certificates are containing a CRL Distribution Point, but still it doesn't do anything.

Do I need to set additional properties in glassfish to enable it?

Johan

kumarjayanti
Offline
Joined: 2003-12-10

Sorry for the delay. I just got to trying it out on my own today and here is what i have in my server side :

And it throws the following exception when running, because my certs do not have a CRLDP extension, neither do they have the ocsp extension.

WSS0223: Certificate validation failed
java.security.cert.CertPathValidatorException: Must specify the location of an OCSP Responder
at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:139)
at sun.security.provider.certpath.PKIXCertPathValidator.doValidate(PKIXCertPathValidator.java:316)
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:178)
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:206)
at com.sun.xml.wss.impl.misc.WSITProviderSecurityEnvironment.validateCertificate(WSITProviderSecurityEnvironment.java:979)

Please note : the revocationEnabled attr is namespace qualified (xmlns:sc="http://schemas.sun.com/2006/03/wss/server"). You may have most likely specified it without any namespace qualifier (due to a bug in documentation).

Please try it and let me know if it worked.

jcstover
Offline
Joined: 2007-11-01

I got delayed also. But the namespace part did the trick. I also got an exception:

Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: revocation status check failed: no CRL found
at com.sun.xml.ws.security.secconv.WSSCPlugin.sendRequest(WSSCPlugin.java:431)
at com.sun.xml.ws.security.secconv.WSSCPlugin.process(WSSCPlugin.java:260)
at com.sun.xml.ws.security.secconv.impl.client.SCTokenProviderImpl.issue(SCTokenProviderImpl.java:129)
at com.sun.xml.ws.api.security.trust.client.IssuedTokenManager.getIssuedToken(IssuedTokenManager.java:79)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.invokeSCPlugin(SecurityClientTube.java:391)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientRequestPacket(SecurityClientTube.java:196)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processRequest(SecurityClientTube.java:167)

So it is looking good. Since I put this issue aside, I have to dive into it again. I let you know when I got the complete setup working

The CRL I used was expired. I created a new CRL and put it on the location specified in the CRLDP. And it works. A correct certificate is working and a revoked certificate is causing the expected exception:

Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Certificate has been revoked, reason: unspecified
at com.sun.xml.ws.security.secconv.WSSCPlugin.sendRequest(WSSCPlugin.java:431)
at com.sun.xml.ws.security.secconv.WSSCPlugin.process(WSSCPlugin.java:260)
at com.sun.xml.ws.security.secconv.impl.client.SCTokenProviderImpl.issue(SCTokenProviderImpl.java:129)
at com.sun.xml.ws.api.security.trust.client.IssuedTokenManager.getIssuedToken(IssuedTokenManager.java:79)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.invokeSCPlugin(SecurityClientTube.java:391)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processClientRequestPacket(SecurityClientTube.java:196)
at com.sun.xml.wss.jaxws.impl.SecurityClientTube.processRequest(SecurityClientTube.java:167)

So I can report it is working as expected. Also the CRLDP method is working. Need to check tomorrow if it will fail, because tomorrow the CRL is expired.

Message was edited by: jcstover

jcstover
Offline
Joined: 2007-11-01

In order to use CRLDP one important jvm option is:

-Dcom.sun.security.enableCRLDP=true

If not set it won't work.

kumarjayanti
Offline
Joined: 2003-12-10

Just curious at present what happens when you set revocationEnabled to true in validatorconfiguration.

What i expect to see that you will see a failure during certificate validation stating that CRL information not present in the certs. Do you see that or does it appear like the revocationEnabled flag has been ignored. If your answer is that it is being ignored, then make sure you have Metro 1.4 installed on GlassFish and then you should see certificate validation failures.

jcstover
Offline
Joined: 2007-11-01

Having serious problem generating correct certificates, but on the old certificate where the root CA doesn't have a crlDistributionPoints element revocationEnabled set on true does't give a failure.

Having a crlDistributionPoint in the root CA is causing an:

com.sun.xml.wss.impl.WssSoapFaultException: WSS1927: Error occured while decrypting EncryptedKey caused by a:

java.io.IOException: Key used to decrypt EncryptedKey cannot be null

So I'm creating all my certificates from scratch to see if this problem goes away. At least revocationEnabled has nothing to do with it.

kumarjayanti
Offline
Joined: 2003-12-10

GlassFish does have a custom CRL feature, but that is checked during SSL interactions and is actually configured inside the http-listener as a property :


See : http://weblogs.java.net/blog/kumarjayanti/archive/2007/11/ssl_and_crl_ch...
for more details.

Sorry to say that this crlFile if configured is not used during webservices interactions. If this is important for you please file an RFE on Metro (https://wsit.dev.java.net).

When you set revocationEnabled for the ValidatorConfiguration, it actually enables the underlying JSSE mechanisms (Revocation List based CRL checking, and Revocation Checking Using OCSP).

JSSE supports Http URL based Revocation Checking wherein the Revocation List will be dynamically downloaded from the Ceritificate Authority. For this your certs need to have the CRLDistributionPoints extension which specifies the URL of the downloadable CRL file from the CA.

For revocation checking based on OCSP to work the certificate would need to have the URL of an online certificate status protocol (OCSP) server in the Authority Info Access (AIA) extension of the certificate.

Thanks.

jcstover
Offline
Joined: 2007-11-01

Thanks for the clarity. Basicly what you tell me is, in order to make checking a CRL is to make sure the certificates include an CRLDistributionPoints extention and if I put in that location the crl file so it can be downloaded it works.

Well I can live with that so I gonna try it. Using a file is not that good anyway. Just one question, is the CRL cached or retrieved each time a certificate is checked?

Thanks

Johan

V B Kumar Jayanti

glassfish@javadesktop.org wrote:

>Thanks for the clarity. Basicly what you tell me is, in order to make checking a CRL is to make sure the certificates include an CRLDistributionPoints extention and if I put in that location the crl file so it can be downloaded it works.
>
>Well I can live with that so I gonna try it. Using a file is not that good anyway. Just one question, is the CRL cached or retrieved each time a certificate is checked?
>
>
As you know CRL caching is not a good idea as much as a static crlFile.
The runtime would then need to deal with making sure it periodically
updates its CRL, but i guess that would also not be a fool proof IMO.
I am actually not aware how JSSE handles it. You may want to pose a
question on this in the Java SE forums. You may want to consider using
OCSP otherwise.

regards,
kumar

>Thanks
>
>Johan
>[Message sent by forum member 'jcstover' (jcstover)]
>
>http://forums.java.net/jive/thread.jspa?messageID=320800
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

jcstover
Offline
Joined: 2007-11-01

I can imaging that the list is refreshed on the valid until date, but that is an assumption. OCSP can have a performance drawback when each certificate is checked online.

I'll try just both way's, but first the generation of the sets of certificates.

Johan