Preferred protocol: OCSP

To verify the validity of a certificate issued by CAcert, the recommended method is to consult the OCSP responder running at ocsp.cacert.org. Many software packages have integrated support for the OCSP protocol, which is quite efficient in two ways:

• very little data needs to be exchanged between client and server
• the answer is always up-to-date because the server has the most recent Certificate Revocation List (CRL) on hand

Fall-back method: CRL

However, sometimes older software versions may lack working support for the OCSP protocol. But they often do have the ability to verify a given certificate against the Certificate Revocation List (CRL) published by the certificate issuer (CAcert in our case). For this to work, the client software requires a fairly recent copy of the CRL. Traditionally, such a copy can be obtained by an HTTP request for http://crl.cacert.org/revoke.crl and/or http://crl.cacert.org/class3-revoke.crl. Doing this regularly causes a lot of network traffic because the CRLs are quite large: revoke.crl is currently 5.6 MB, while class3-revoke.crl is 0.6 MB.

Improved fallback method: RSYNC

As of today a much more efficient method is available for maintaining a reasonably up-to-date local copy of the CAcert CRLs: the rsync protocol. After the initial retrieval of the full CRL, subsequent updates are orders of magnitude faster because only the small differences with the previous version need to be transmitted. The service can be used like this:

Initial setup:

$ mkdir crl-dir
$ rsync -avz crl.cacert.org::crl crl-dir

Regular update (e.g. via cron):

$ rsync -avz crl.cacert.org::crl crl-dir

Recommendation

Only if you cannot use OCSP and  really do need local up-to-date copies of CAcert’s CRLs, please consider the use of the rsync method outlined above. By saving bandwidth use on the crl.cacert.org server everybody benefits from better response times. Your cooperation is appreciated!