CRL, OCSP and OCSP stapling validation with Ballerina

Once a certificate is issued by a certificate authority(CA), CA gives a validity period for the certificate and the certificate is expected to be valid for that entire validity period. After issuing a certificate, CA does not have any capability to take it back. So in order to revoke/cancel a certificate, CA publishes the certificate’s status as Revoked. Once the certificate is revoked, that should no longer be trusted.

If you want to create your own OCSP server, you can refer this.

Ballerina supports verification of certificate revocation through,

1. OCSP stapling
2. OCSP
3. CRL

Ballerina HTTP client endpoint and listener endpoint can verify with the certificate authority whether a certificate is still trusted before it completes an SSL connection.

OCSP stapling

OCSP stapling http:Client configurations,

In http:Client, apart from the normal HTTPS configurations (See ‘Basic HTTPS Listener Client ballerina by example), we need to add another field inside secureSocket record type to enable/disable ocspStapling in client side.

ocspStapling — True/false to enable/disable ocspStapling.

After enabling ocspStapling in client side, a client will request the OCSP staple from the server during the SSL handshake. Depending on the OCSP staple which client receives, it will do the validations accordingly and establish the connection. If the validation fails with the server sent OCSP staple, or if the server didn’t send the staple, validation will be followed up by OCSP and CRL.

OCSP stapling http:Listener configurations,

Apart from the normal HTTPS configurations, this will include a record type called ocspStapling under the secureSocket record type.

ocspStapling — Record type to configure OCSP stapling related parameters.

enable — True/false to enable/disable OCSP stapling in listener

cacheSize — Maximum size of the cache to hold the OCSP staple of the listener

cacheValidityPeriod — The time period for which a cache entry is valid

It is necessary to have the end-user certificate(here listener certificate) and it’s issuer’s certificate placed inside a pkcs12 keystore. These certificates should be issued by a well known Certificate Authority which acts as an OCSP server or else you need to have your own OCSP servers set up in your local machine. If you want to set up your own OCSP servers you can refer this. If you follow that blog you need to have the private key (certKey.key), end-user certificate(certificate.crt) and it’s issuer’s certificate (rootCA.crt) inside a pkcs12 keystore. This will be used as the keystore. And we need to create another keystore which we are going to use as the truststore. It needs to contain the end-user certificate(certificate.crt) and the issuer’s certificate(rootCA.crt).

If you have certificates from a well known CA, arrange them into 2 pkcs12 files as above mentioned.

OCSP stapling enabled listener

OCSP stapling enabled client

OCSP and CRL validation

This is supported in both the client side and server side (Mutual SSL). This is implemented in such a way that, first check the verification with OCSP and if OCSP authority points are not included or OCSP validation fails at some point, verification will be followed up by CRL.

OCSP and CRL validation configurations,

Same configuration applies to both the client and listener endpoint. These configurations should be included inside the secureSocket record type.

certValidation — Record type to configure OCSP and CRL validation related parameters.

enable — True/false to enable/disable

cacheSize — Maximum size of the cache to hold the OCSP or CRL result

cacheValidityPeriod — The time period for which a cache entry is valid

OCSP and CRL validation enabled listener

OCSP and CRL validation enabled client