Interested in hearing some thoughts from the community on the use of OCSP vs CRL for certificate validation when using certificates for authentication/authorization on an anyconnect VPN.
I was thinking that
1)OCSP is theoretically more efficient/effective as you only query for validity of the cert you are looking at, and you get a real-time response as to its status whereas CRLs are cached so the data could be stale and you are getting an update from the CA of all revoked certificates which might be more than you need.....BUT....if its a relatively small implementation and/or there arent a ton of revoked certificates, maybe getting the entire CRL and cacheing it as opposed to using OCSP isnt that big of a deal.
2)CRL could have an advantage (maybe?) if your CA is not highly available or at least if you dont want your certificate based authentication to be dependent upon the availability of the CA.
One thing which I am factoring in here (and correct me if I am wrong on this) is that the ASA will only cache a CRL for a short period of time (trying to find the doc where I read this). If that is true...then issue 1 where OCSP has an advantage due to the "real time" nature of the information being used isnt that much of an advantage because the ASA is checking for CRLs so frequently. Also issue 2 where CRL has an advantage in the event of CA availability issues, isnt that much of an advantage since the ASA has to pull a new CRL so frequently that you are still dependent upon the CA's being available.
Your thoughts? What have you chosen to do and why?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...