Marvin, Just one more follow up before I move out to start an implementation. What if we do not issue the certificates we want to revoke. Will this solution still work? Our solution is trying to integrate DoD CAC cards (which contains certs issued by DoD on the CAC card itself). Can we even revoke these certificates when we are not the issuer? I was thinking we could because all we are doing when we run the openSSL command to revoke a certificate is adding it to our CRL that our applications use. We are not really revoking the certificate -making it invalid for use across the DoD - since that is the job of the issuer (in this case DoD).
My plan was to take the Server Certificate we generated (our CA) and add the crlDistributionPoints section to my openSSL configuration file, then regenerate the Server Certificate. Then as we identify certificates we want to revoke from using our system, we would simply revoke the certificate and add it to our CRL in which our Server Certificate points to based on the crlDistributionPoints declaration. Trying to understand the revocation process a little more. Schawn- ________________________________ From: Marvin Addison <[email protected]> To: [email protected] Sent: Friday, February 8, 2013 12:26 PM Subject: Re: [cas-user] CAS support for CRL > After digging around, I think I figured this out. I have to add a > crlDistributionPoints section to my openSSL configuration file and > regenerate my CA that I am using. Does that sound correct? You would need to do that if you are not presently issuing certs with the crlDistributionPoints extension field and you want to use CRLDistributionPointRevocationChecker. There is another component that supports specifying a static URI to the CRL endpoint, ResourceCRLRevocationChecker. In either case I had assumed that you would be using certs issued from a PKI that has some kind of support for revocation, either CRL or OCSP. I would say that requirement holds generally. If you're developing a PKI in tandem with rolling out X.509 support in CAS, then you should certainly consider a number of policy concerns, among them revocation. We have an entire team dedicated to our PKI; it's a lot of work, largely in crafting policy at a high level and implementing it in software/systems. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
