What is CertCache?
A client certificate can only be one of 3 states: not yet valid, valid, and no longer valid (expired). The issuing CA can add a fourth state - revoked - which can be determined by checking a CRL, or querying the CA's OCSP endpoint. CRLs can become very large, and there's always a lag between certificate revocation and downloading an updated CRL. OCSP is always up to date, but it requires an HTTP call which can have variable performance.
Additionally, Stanford only allows certificates to be used if they are associated with a compliant device, as determined by the Device Registry (based on data from BigFix or VLRE agents, AirWatch MDM, and other sources). Rather than require users to re-enroll for a new certificate anytime their device becomes non-compliant, we want to track when certificates cannot be used.
For these reasons, and to prevent multiple calls to OCSP and the Device Registry API for every authentication, we use a separate cache of certificate information - CertCache.
CertCache is a Node application, providing a set of processes, and an API, a webhook endpoint, and a database for maintaining extra information acout client certs issued by CloudPath. It is designed to integrate with the following services:
- CloudPath, via webhook (POST) notifications through the AWS API Gateway to an AWS SQS queue.
- Device Registry, via a RESTful [API](API
- MyDevices, via the same RESTful API
- Stanford's IdP, via SQL queries (as an Attribute Resolver)
- Stanford's RADIUS servers, via SQL queries
There is a separate page describing the overall architecture.
There are separate instructions for configuring CloudPath certificate templates and notifications.
See the testing instructions.
Building, Configuring, and Running CertCache
See the certcache instructions.