4

I'm adopting the Hyperledger Fabric to build applications for my business.

Since permissioned blockchains like Fabric rely heavily on the PKI for identity management, and the fact that every transaction on the network requires signatures from participating components along way the transaction flow and transactions with those signatures finally got immutably persisted in the ledger.

I wonder what happens if participating components would have to renew their certificates? For example, the original certificates expired or private keys got compromised.

Specifically, I want to know:

  1. Should renewal of a certificate require a new PKI key pair in best practice, or should a new certificate be created with the original key pair be created with its validity extended?

  2. What if it's the case when a private key got compromised, and I have to revoke the original certificate and use a new one with a new key pair. In this case, how should I validate signatures of transactions that were already persisted in the ledger? I wonder if it means that even if a certificate were revoked, it should be kept for validating history signatures.

yacovm
  • 5,120
  • 1
  • 11
  • 21
WayChan
  • 53
  • 5

1 Answers1

6

First of all, there are 2 types of certificates in Fabric:

  • TLS certificates
  • Enrollment certificates

For TLS certificates, when they expire - they cannot be used anymore but obviously active TLS connections aren't being terminated when it happens.

For enrollment certificates - when they expire they still keep on being useful regardless of their expiration. This is to prevent a fork when peers join the Blockchain late. So, in short - certificate expiration has no effect in enrollment certificates.

Should renewal of a certificate require a new PKI key pair in best practice, or should a new certificate be created with the original key

pair be created with its validity extended?

In most cases, Fabric treats 2 certificates with the same public key but different attributes as 2 completely different identities (unless you take into account de-duplication at transaction validation) so if you have a chance to renew a certificate of a node or a client - you might as well also use a fresh key. It is not required but it is possible.

What if it's the case when a private key got compromised, and I have to revoke the original certificate and use a new one with a new key pair. In this case, how should I validate signatures of transactions that were already persisted in the ledger? I wonder if it means that even if a certificate were revoked, it should be kept for validating history signatures.

For TLS certificates, Fabric doesn't use CRLs so you can only rely on short expiration periods, or you can always just replace the entire certification chain and this would implicitly invalidate the leaf certificates of the old chain.

For Enrollment certificates you can issue a CRL config update to all channels and this would make it impossible to use the compromised key in future transactions, however signatures of transactions made in the past (in the blocks that precede the revocation of the certificate) would still be valid from obvious reasons.

However, there is a code path that checks expiration of enrollment certificates: Whenever a request from a peer or a client is authenticated to access a resource (i.e a client wants to execute a chaincode, or a peer wants to pull blocks) - then the certificate expiration of enrollment certificates is also checked by the server (peer/orderer).

yacovm
  • 5,120
  • 1
  • 11
  • 21
  • Thank you a lot for your answer, yacovm. Thanks a lot especially for pointing out the two different types of certificates in fabric. With the clarification of two different types of certificates, I'm able to understand that in the case of a TLS certificate, only the inter-component connection authentication might be affected and it's easy to handle by just replacing it with a new one. – WayChan Dec 31 '19 at 07:11
  • In the case of an enrollment certificate, about the validity of signatures made before the signing certificate expired or revoked, I agree that its obvious that the signatures stay valid even after the expiration or revocation of its signing ceritifcate. When I posted the question, I was looking for a technically way to validate whether a signature was signed during the validity of its signing certificate. Then I found the method called Time Stamping Signatures, which yields a trusted Time Stamp Authority to sign our data with a trusted timestamp. – WayChan Dec 31 '19 at 07:54
  • Time stamping the signatures seems to be a good way, but I'm not sure what's the fabric way to validate such signatures. At last, I think keeping a CRL as you mentioned is required for both rejecting invalid certificates in use and validating history signatures. – WayChan Dec 31 '19 at 07:55
  • I edited my answer because I forgot to mention something. – yacovm Dec 31 '19 at 08:54
  • Hi @yacovm, you have added that there is a code path that checks expiraton of enrollment certificates, so, I understand that It is not possible to use an expired unrollment certificate, is it? Look at this (https://github.com/hyperledger/fabric/blob/master/common/deliver/acl.go) – Yeray Rodriguez Feb 13 '20 at 11:25
  • Hi @yacovm, I'm sorry, but my english level is horrible. I mean that official Fabric documentation says that enrollement certificates (https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#msp-configuration) However, I'm having some problems with this, expired enrollment certificates doesn't work. I've found that code fragment (github.com/hyperledger/fabric/blob/master/common/deliver/acl.go) and I'm not sure if this is what you have added to the post. – Yeray Rodriguez Feb 14 '20 at 15:41
  • You can't send anything to a node using an expired certificate, but once it is inside a block then Fabric doesn't care if it is expired – yacovm Feb 14 '20 at 17:05