Re: [cas-user] CAS 3.4.8 - X509 Certificates CRL Checking

[Philippe MARASSE]

Le 10/06/2011 15:40, Marvin Addison a écrit :

I've modified CasLoginView.lsp to display a warning if a X509 certificate is
showed but authentication has failed, so how can I determine the reason why
the certificate has been rejected ? Main causes I've identified are :
  - Certificate is not paired (I'd show a link to our pairing application)
  - Certificate is revoked
  - LDAP Lookup was not fast enough

By "pairing" I suppose you mean there is no corresponding LDAP account
corresponding to the cert.  If that's correct you could potentially
provide meaningful errors for cases 1 and 3.

Yes, it's exactly that case. Actually my test is too simplistic : certificate provided & casLoginView displayed => Certificate not paired, but when the certificate is revoked... I get the same behaviour !

Case 2, revoked
certificate, can't be handled by CAS because something external to the
JVM (OpenSSL in your case) is performing the SSL negotiation.  The
container is bouncing the connection long before the request could get
to the cas servlet for examination of the cause.

Hmmm, I should tell more about our architecture, we've 3-tier architecture with 
:

Apache +mod_jk + mod_ssl <=> Tomcat + CAS <=> MySQL

Our Apache server does :
  - SSL negotiation :
    - optional client certificate (with the list of expected issuers)
    - Validity check (not before / not after)
    - Certificate chain check
    - No revocation check !! (because of openSSL issue)
  - other stuff like mod_security, ...

And my CAS 3.4.8 test platform actually does :
  - Issuer regex matching
  - CRL checking
  - Certificate key usage check
  - Validity check

Supporting case #2 brings up some interesting points for discussion.
It's worth discussion because currently you have to do substantial
work to provide a good user experience for a failed cert
authentication.

In our case, as openssl (so Apache) cannot do CRL checking so it's delegated to CAS which does that pretty well, in fact, to improve user experience, I wish I can shut down Apache's certificate validity check. As far as our smartcards are issued by a governmental organization, the issuer list is fixed and known and should not be a problem.

I wonder whether it would it be possible and feasible to develop some
components that hook into the container (e.g. Tomcat) that would
accept _any_ client certificate and delegate to the
X509AuthenticationHandler for full validation, including the
following:

  - Validity (NotBefore+NotAfter)
  - Allowed issuer
  - Path length checking
  - Revocation

The second point above is fairly involved since we'd no longer be
relying on the container to do the cert path verification, which is
the assumption underlying the simple regex patterns we currently use
for that feature.

So the question is, if it's possible, is it worth the admittedly large
effort to support a better user experience for X.509 auth.  I'm taking
for granted that the browser dialogs for failed SSL negotiation
provide a terrible user experience.

For know I would be happy If I can provide to users some informations as :
  - User certificate is not paired (more reliably)
  - User certificate is revoked



Rgds.

--
Philippe MARASSE

Service Informatique - Centre Hospitalier Henri Laborit
BP 587 - 370 avenue Jacques Coeur
86021 Poitiers Cedex
Tel : 05.49.44.57.19

Those points actually brought the same behaviour : X509 Auth fails and authentication is falling back silently to login/password form. I'm looking for a way to improve user experience at this point.

smime.p7s
Description: S/MIME Cryptographic Signature