Certificate Revocation in Fabric CA Server

Overview

This article shows how to revoke a user in a fabric network such that the user cannot access fabric network and chaincode any more. We first give a high-level walk-through of the process, and later use Test Network to demonstrate the revocation. The script provided in Test Network makes bringing Fabric CA servers much easier and we can use the material to perform the demonstration.

Revisit: Bring Up Test Network with Fabric CA Server

Here we first revisit what happens when we bring up the Test Network with Fabric CA Server. Script network.sh gives us everything by this simple command.

The details of this process can be summarized in the following steps.

  1. Bring up three Fabric CA Servers, for Org1, Org2 and OrdererOrg, respectively.
  2. For Org1, enrol the bootstrap admin with Fabric CA Client.
  3. Use bootstrap admin to register entities for Org1, including peer0 (peer), org1admin (admin) and user1 (client).
  4. Enroll these entities to obtain all their msp materials. These materials are then used to bring up the network.
  5. Repeat step 2–4 for Org2 and OrdererOrg.
  6. Bring up the peers and orderer, create channel material and join the peers of both orgs to mychannel.

As a result, we see the network is ready for use.

To know more about Fabric-CA-Server, we can use Fabric-CA-Client.

There are four entities registered in Fabric CA Server of Org1. They are the bootstrap admin, peer0 (peer), org1admin (admin) and user1 (client). A note about the two “admins” in Fabric-CA-Server

  • (bootstrap) admin: This is the admin of Fabric-CA-Server. We use this admin material in Fabric-CA-Client for entity registration (e.g. peer0, org1admin and user1) in Fabric-CA-Server. Later in our demonstration we will use this admin in Fabric-CA-Client to revoke user1.
  • org1admin: This is the admin of Org1 in the consortium network (Test Network). For example, create and update channel, install, approve and commit chaincode, etc. In the certificate it contains OU=admin.

Therefore, don’t mix these two “admins”. It is the bootstrap admin creates org1admin, and when dealing with fabric network, we are using only org1admin while bootstrap admin is not required. We will see both are required when revoking an entity.

Process of Revoking an Entity

This is the quick introduction about revoking an entity (certificate or identity) in the official documentation. In short, we can divide it into two parts.

  1. In Fabric-CA-Server, revoke an entity by its ID. A certificate revocation list (CRL) is created
  2. Update the channel configuration to include the CRL.

Part 1: Revoke an entity in Fabric-CA-Server

This is done by the bootstrap admin in Fabric-CA-Server. The admin has attributes hf.Revoker and hf.GenCRL. These are required when we revoke an entity in Fabric-CA-Server.

The revocation is done through this command.

The result is an update on the Fabric-CA-Server database (user1 is marked revoked). The option gencrl will create a CRL including this revoked user1. We can separate this into two parts: revoke entities first and later generate CRL. Here we complete these into one command.

Part 2: Update channel configuration

The CRL generated in the previous part needs to be included in the channel configuration. This is done through a configuration update. Here we first construct the configuration update transaction, and then have Admin@org1 (org1admin) sign and submit the transaction. When everything works fine, User1@org1 is no longer able to access the chaincode function.

We first take a look at the configuration block fetched from the channel. Inside Org1MSP we find an empty revocation list (line 201).

To revoke an entity, we paste the CRL (encoded in base64) into this list.

With this, we can go through the same process to compute the delta (update) between two configurations, and add the envelope upon the delta before converting it back to a transaction ready for signing. The detail process can be referred to in this example (link).

Note that this update is only relevant to Org1. Therefore only Admin@org1 is needed to sign this update. When this completes, the revocation comes into effect, and we no longer can use User1@org1.

Demonstration

Part 0: Bring Up Test Network and Deploy SACC

Bring up mychannel and deploy SACC for testing

Set environment variables for org1. Here is mine. You can see the default msp I am using is Admin@org1.

Invoke chaincode SACC.

Query chaincode with User1@org1.

We get back the right result. User1@org1 as a client can query chaincode function.

Part 1: Revoke User1@org1 in Fabric CA

We use a single command to revoke user1 and generate CRL.

We see the CRL generated. This is the CRL file.

We need the base64-encoded version of this file for later configuration update.

Part 2: Update channel configuration

First fetch the configuration block from mychannel

Perform the required editing and compute the configuration update transaction. The detail process can be referred to in this example (link).

Then sign the update transaction with Admin@org1.

With this, the configuration update is complete, and User1@org1 is revoked.

Part 3: Test

Now query chaincode function with both Admin@org1 and User1@org1.

The revoked entity User1@org1 cannot access chaincode any more.

Discussion

Always think of the operations of Fabric CA and Fabric network are separate. In normal cases, after Fabric CA generates all the crypto materials and those crypto materials are properly installed in the fabric network, Fabric CA is no longer needed. When revoking an entity, we have to first revoke the entity in Fabric CA and thus the certificate revocation list (CRL) is generated. Then update the channel configuration with this CRL in the fabric network.

In Fabric CA, the bootstrap admin has the rights to revoke certificates and generate the CRL.

In fabric network, it is the organization admin (in our case Admin@org1) having the authorization to perform this revocation configuration update. If the update is signed by either non admin (e.g. User1@org1) or by admin of another organization (Admin@org2), the update fails due to signature policy.

Finally, the configuration update is made on channel level. That is to say, User1@org1 can still work in other channels. Make sure Admin@org1 updates the revocation list in all relevant channels. For example, a new channel newchannel is created and chaincode fabcar is deployed. We can see the User1@org1 can still query chaincode.

Summary

I hope this article provides more insight about certificate revocation in Fabric CA. Special thanks to Roland (Bole Roland) as he raised this and made some trials on the process.

Written by

Happy to share what I learn on blockchain. Visit http://www.ledgertech.biz/kcarticles.html for my works. or reach me on https://www.linkedin.com/in/ktam1/.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store