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

[Philippe MARASSE]

Thank you very much Marvin, CRL checking works new :-). But I've now another problem : we use actually 2 authentication schemes : smartcard (x509) and login/password. Both schemes uses LDAP to find a principal name. So X509 certificates have to get paired to LDAP accounts.

  - Certificate is not paired (I'd show a link to our pairing application)
  - Certificate is revoked
  - LDAP Lookup was not fast enough

At least, I want to know if the certificate has been revoked and when...

Rgds.

Le 09/06/2011 18:53, Marvin Addison a écrit :

Actually with CAS 3.3.5, I can't do CRL checking because of technical limitations of openssl (Certificate signing key and CRL signing key are different, with same DN), and SSL negotiation errors showed by browser are not very user friendly... 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 :

I don't know how to configure CRL Checking in the authentication bean.

That's my fault.  I've been meaning to pen documentation for months now.

But CRLDistributionPointRevocationChecker constructor expects a Cache
object... but I've no idea how to set it up. So I'm looking for advices...

That implementation has a poller process to fetch the CRL from the
resource (URL in practice) defined in the CRLDistributionPoints
extension field and then cache it for a period of time so that certs
issued by the same CA can avoid fetching it on every authentication.
Here's a complete example from our university:

         <bean 
class="org.jasig.cas.adaptors.x509.authentication.handler.support.X509CredentialsAuthenticationHandler"
           p:trustedIssuerDnPattern="${x509.trusted.issuer.pattern}"
           p:maxPathLength="2147483647"
           p:maxPathLengthAllowUnspecified="true"
           p:checkKeyUsage="true"
           p:requireKeyUsage="true">
                <property name="revocationChecker">
        <bean 
class="org.jasig.cas.adaptors.x509.authentication.handler.support.CRLDistributionPointRevocationChecker">
        <constructor-arg>
        <!-- Cache CRL fetches for 6h -->
        <bean class="org.springframework.cache.ehcache.EhCacheFactoryBean"
                      p:cacheName="CRLCache"
                      p:eternal="false"
                      p:overflowToDisk="false"
                      p:maxElementsInMemory="100"
                      p:timeToLive="${x509.crl.cache.timeout}"
                      p:timeToIdle="${x509.crl.cache.timeout}">
        <property name="cacheManager">
        <bean
class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean" />
        </property>
        </bean>
        </constructor-arg>
        <property name="unavailableCRLPolicy">
        <bean class="${x509.unavailable.crl.policy}" />
        </property>
        <property name="expiredCRLPolicy">
        <!-- Allow expired CRL data up to 48h -->
        <bean
class="org.jasig.cas.adaptors.x509.authentication.handler.support.ThresholdExpiredCRLRevocationPolicy"
                      p:threshold="${x509.expired.crl.policy.threshold}" />
        </property>
        </bean>
        </property>
         </bean>

The unavailableCRLPolicy can be either of the following:

org.jasig.cas.adaptors.x509.authentication.handler.support.AllowRevocationPolicy
org.jasig.cas.adaptors.x509.authentication.handler.support.DenyRevocationPolicy

While the Deny policy is arguably more secure, its use has dramatic
consequences when CRL data is unavailable:  all X.509 authentication
will fail.  In our opinion the availability/security trade off isn't
worth it for this policy.

M

--
Philippe MARASSE

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

smime.p7s
Description: S/MIME Cryptographic Signature