Hi,
I have contacted our JDK experts and here is what they responded with :
-------------------------
Yes. The certificate is not considered revoked because the reason on
the CRL Entry is "Remove from CRL". This is explained in more detail in
RFC 3280/5280 but this type of reason code is used for certificates that
were placed on hold and then subsequently found not to be revoked and it
is not considered a revocation failure. See specifically in section
6.3.3. CRL Processing :
(k) If (cert_status is removeFromCRL), then set cert_status to
UNREVOKED.
--Sean
---------------------------
regards,
kumar
On 22/10/10 12:21 AM, glassfish_at_javadesktop.org wrote:
> Kumar or anyone,
>
> I have ...
>
> 2-way SSL setup with CA's in my trust store (cacerts.jks)
> a single CRL from the CA in the trust store
> 6 Certs (3 good, 2 revoked, 1 expired) from the CA in the trust model loaded into my browser
>
> What happens when I present my certs ...
> Good - as expected - they work page displayed
> Expired - as expected - the page is NOT displayed (certpath processing fails on
> SEVERE: certpath: -Using checker5 ... [sun.security.provider.certpath.BasicChecker]
> SEVERE: certpath: ---checking timestamp:...
>
> And the problem is ...
> Revoked - should fail in certpath: -Using checker6, but it is successful. Processing shows the cert is found in the CRL however the process returns success& then the page is displayed.
>
> ---- Partial server.log ----
>
> SEVERE: certpath: -checker5 validation succeeded
> SEVERE: certpath: -Using checker6 ... [sun.security.provider.certpath.CrlRevocationChecker]
> SEVERE: certpath: CrlRevocationChecker.verifyRevocationStatus() ---checking revocation status...
> SEVERE: certpath: CrlRevocationChecker.verifyRevocationStatus() crls.size() = 1
> SEVERE: certpath: CRLRevocationChecker.verifyPossibleCRLs: Checking CRLDPs for CN=User7 John John.User7, OU=TEST, O=xxxxxxxxxx, C=xx
> SEVERE: certpath: CrlRevocationChecker.verifyRevocationStatus() approved crls.size() = 1
> SEVERE: certpath: starting the final sweep...
> SEVERE: certpath: CrlRevocationChecker.verifyRevocationStatus cert SN: 4098350723398757786823434502144507443043719918241735943196832223568800273443972745730
> SEVERE: certpath: CrlRevocationChecker.verifyRevocationStatus CRL entry: SerialNumber: [ 021c11ff a5298740 2ff8fdd5 c09f5d2a 46621183 4ea8a316 031e0419 6f480202
> 026c8a02] On: Thu May 20 08:46:12 EDT 2010
> CRL Entry Extensions: 1
> [1]: ObjectId: 2.5.29.21 Criticality=false
> Reason Code: Remove from CRL
>
> SEVERE: certpath: -checker6 validation succeeded
> SEVERE: certpath: checking for unresolvedCritExts
> SEVERE: certpath:
> cert1 validation succeeded.
>
> SEVERE: certpath: Cert path validation succeeded. (PKIX validation algorithm)
> SEVERE: certpath: --------------------------------------------------------------
>
> ---- Partial server.log ----
>
> Isn't GF, the server, supposed to trap and throw out revoked certs?
>
> BTW, I'm not running any code. This is the default ssl on port 8181 and the default GF web page.
>
> Any help would be greatly appreciated. (I'll let you write the white paper ;) )
>
> Thanks,
> Eric
> [Message sent by forum member 'eliscinsky']
>
> http://forums.java.net/jive/thread.jspa?messageID=485890
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>