CRL distribution
Certificate Revocation Lists (CRLs) are files containing the list of revoked certificates that shouldn’t be trusted anymore. As it’s usually used by clients (with OCSP) to validate certificates, it’s a critical part of the infrastructure requiring the highest availability.
As CRLs are flat files, there are multiple ways to distribute them to clients depending on the level of control required by the customer but an object storage service is usually a good solution. Two buckets are required when deploying a Cloud PKI:
-
a bucket holding CRLs, that will be automatically updated by Stream
-
a bucket holding AIAs, that will need to be updated manually each time a CA is signed.
1. Customer-managed S3 buckets (Recommended)
The ideal storage solution is an S3 bucket hosted inside the customer’s own cloud provider, as it allows the customer to be in control of the distribution point. Stream supports any S3-compatible storage provider and will upload CRLs as soon as they’re generated (see the related documentation on how to set it up in Stream).
Should the customer need to integrate existing and legacy distribution URLs, or switch to another solution than Stream in the future, this option is the most flexible. However, this implies some responsabilies on the customer side:
-
the customer will need to set up and manage the infrastructure to distribute CRLs: appropriate DNS records, usually some kind of cache proxy (CDN)…
-
SLAs will need to be negociated directly with the cloud provider, and won’t be covered by EVERTRUST Cloud standard SLAs as the infrastructure is out of the EVERTRUST control
This set up can be summarized by the following diagram, where blue-colored elements are customer-managed and green-colored elements are EVERTRUST-managed:
2. EVERTRUST-managed S3 buckets
If the customer is not able to host the infrastructure themselves, EVERTRUST will provide S3 buckets hosted in the same environment as the Stream CA Instance. Credentials with write access to both buckets will be provided to the customer, so an External CRL Storage can be configured in Stream.
| This type of setup introduces a dependency between EVERTRUST and the customer when client secrets need to be rotated. When doing so, the customer will be notified at least a week in advance and will need to update their External CRL Storage configuration accordingly to the EVERTRUST requirements, as EVERTRUST doesn’t have direct access to the platform. |
EVERTRUST will also provide a caching proxy that will distribute the CRLs to clients, which will allow access from a customer-defined DNS endpoint aliased to the EVERTRUST provided domain name :
| Record type | Record value |
|---|---|
CNAME |
|
For reversibility reasons, CRL distribution from an endpoint containing evertrust.io is not supported, and the customer-managed alias should always be used in CRLDPs.
|
This set up can be summarized by the following diagram, where blue-colored elements are customer-managed and green-colored elements are EVERTRUST-managed:
