What is certificate rotation and why is this important?
If you've deployed the IBM Blockchain Platform, you already know you are responsible for monitoring your network -- ensuring that you have adequate compute, storage, and memory, to track the health of your network. But did you also know that you need to monitor the expiration date of your certificates? The X.509 certificates that are generated for the identities on your network expire. And similar to how you have to regularly update your passwords for security reasons, you need to renew the certificates, in a process sometimes referred to as "certificate rotation". When certificates expire, transactions on the network will fail because the identity can no longer be trusted. To avoid any downtime of your components, it is your responsibility to monitor those expiration dates and manage your certificate renewal accordingly.
When do the certificates expire?
By default, many of the certificates on your network expire in as little as one year. If you are approaching the one year anniversary of when you deployed your network and generated the identities, you need to start to monitor the expiration dates of your certificates. The latest version of IBM Blockchain Platform now shows the expiration dates of the component certificates throughout the console and displays warnings when it is time to renew them. It also attempts to automatically renew the enrollment certificates of your peer and ordering nodes if they will expire within 30 days. But, automatic certificate renewal for a peer or ordering node can fail if the associated CA is offline or unreachable. New tooling has been added to the console UI to let you renew these certificates yourself, before and even after they expire.
You are responsible for annually renewing the CA TLS certificates as well as the peer and orderer organization admin certificates that you create. If the certificates were generated by using a Certificate Authority (CA) in the console, renewing the certificates is also performed from the console by simply enrolling the identity again. When the certificate belongs to a peer or orderer organization admin identity, then you also need to associate the new admin identity with the node, a simple action from the console.
The good news is that in December of 2019, the platform added Fabric "Node Organizational Unit (OU)" support for all new Membership Service Providers (MSPs) which greatly simplifies the steps required to update an organization admin identity across the network. Recall that when you registered a user with the CA, you had to select a user "Type" of client, peer, orderer, or admin, which is used to confer the "role" onto the identity by inserting the role as an OU attribute inside the certificate. When Node OU support is enabled for an MSP, the MSP will automatically recognize any certificate with the "admin" OU from the organization CA as an organization admin identity. This means that the organization admin identity signing certificate no longer needs to be explicitly updated in an MSP definition across the network. Therefore, if an organization admin identity was enrolled on an MSP with Node OU enabled, when the organization admin identity is renewed, it is not necessary to also update the MSP on the orderer system channel or any application channels that the MSP belongs to. This becomes especially beneficial if your network includes a large number of channels.
If Node OU support was not enabled on the MSP when the organization admin identity was enrolled, the new signing certificate for the organization admin needs to be manually added to the list of admin certificates inside the MSP definition. And you also then need to update the MSP definition on the orderer system channel and any application channels that the MSP belongs to. Lastly, because it is important that consortium members always use the latest MSP definition for each organization, when you update an MSP definition, you need to share it with the other consortium members, in an out-of-band process, so they can import it into their console. You can see why enabling Node OU support on an MSP can save a lot of effort the next time certificates expire!
How do you know if Node OU support is enabled for an MSP? The latest version of the platform now displays the Node OU status (Enabled or Disabled) throughout the console.
Finally, if you have identities enrolled for client applications, you are responsible for keeping their certificates up to date or the applications will cease to work. If these identities were stored in the console wallet when they were generated, you can monitor their expiration from the wallet. Otherwise, open source tooling, such as
openssl can be used to view the certificate expiration date.
Where can I find more information?
The renewal and update process is explained in more detail in the new
Managing certificates topic of the IBM Blockchain Platform documentation. It includes the types of certificates that you need to monitor, how to view their expiration date, impact if expired, and the process for renewing them. Use your blockchain console to review the expiration dates of the certificates in your network and take action now to renew them before they expire.
#Blockchain#IBMBlockchainTransparentSupplyandIBMFoodTrust#SupplyChain