Certificate revocation list¶
The certificate revocation list consists of certificate serial numbers of issued certificates that are no longer valid. It is used by nodes when they establish a TLS connection between each other and need to ensure on certificate validity. In order to add entries to the certificate revocation list there is the certificate revocation process that resembles the one from the certificate signing request (CSR). Note that, once added the entries cannot be removed from the certificate revocation list.
In the similar vein as CSR, it is integrated with the JIRA tool, and the submitted requests follow exactly the same lifecycle. To support the above functionality, there are two externally available REST endpoints: one for the certificate revocation request submission and one for the certificate revocation list retrieval.
Since the certificate revocation list needs to be signed, the revocation process integrates with the HSM signing service. The certificate revocation list signing process requires human interaction and there is a separate tool designed for that purpose. Once signed the certificate revocation list replaces the current one.
Note: It is assumed that the signed certificate revocation list is always available - even if it’s empty.
HTTP certificate revocation protocol¶
The set of REST end-points for the revocation service are as follows.
Submission of the certificate revocation requests expects the following fields to be present in the request payload:
Serial number of the certificate that is to be revoked.
Certificate signing request identifier associated with the certificate that is to be revoked.
Legal name associated with the certificate that is to be revoked.
Revocation reason (as specified in the java.security.cert.CRLReason). The following values are allowed.
Issuer of this certificate revocation request.
At least one of the three: certificateSerialNumber, csrRequestId or legalName needs to be specified. Also, Corda AMQP serialization framework is used as the serialization framework.
Because of the proprietary serialization mechanism, it is assumed that those endpoints are used by dedicated tools that support this kind of data encoding.