Adarsha Jha
Adarsha Jha

Reputation: 1850

Hypereldger fabric admin certs and tls certs expired

I noticed that HLf admincerts and tls certs, by default, have an expiration date of 1 year. In my case, they have expired and my orderer and peer nodes are giving me a bad certificate error. Is there any way to do certificate rotation? I don't want to loose any data as the network is in a production enviroment. I am using hyperledger fabric 1.4 version with the raft ordering service.

Upvotes: 0

Views: 1918

Answers (4)

Badr Bellaj
Badr Bellaj

Reputation: 12821

To renew the TLS an Entrollement certificates (TLS and MSP signgign certificates) we can reenroll all components.

As indicated in https://github.com/hyperledger/fabric-ca/releases/tag/v1.5.1 the newer versions of CA enable us to re-enroll with existing key even if certificate is expired. To be able to do it :

  • 1 Add to docker-compose-ca.yml for all CAs (orgs, orderer) - FABRIC_CA_SERVER_CA_REENROLLIGNORECERTEXPIRY = true
  • 2 you can change the same value within the container by editing /etc/hyperledger/fabric-ca-server-config.yaml and looking for REENROLLIGNORECERTEXPIRY:false change it to true.
  • 3 restart all containers : docker restart $(docker ps -a)
  • 4 remove CA tls expired certificate and use reenroll command with argument --ca.reenrollignorecertexpiry. Or copy reenroll.sh and renewal.sh into /test-network and run renewal.sh
  • 5 if you have a running app you can edit the connection.json file with the new certificate

Upvotes: 0

k.antipov
k.antipov

Reputation: 41

Our case: k8s, fabric v2.2, mutual tls requied for all hyperledger connections, certificates expired 3 days ago.

First of all we need to pass through expired tls. Add to the orderer config:

ORDERER_GENERAL_TLS_TLSHANDSHAKETIMESHIFT: 120h  
ORDERER_GENERAL_AUTHENTICATION_NOEXPIRATIONCHECKS: "true"  

The latest parameter will allow to use expired MSP entities later.
To skip tls checks on the peer side, use the --tlsHandshakeTimeShift 120h parameter.

After the connection was restored, we need to update certificates in the blockchain. Unfortunately there is no analog of the _NOEXPIRATIONCHECKS option for the peer, so we need to use a time-shifted environment. I didn't manage to run the one in the kubernetes, so I had to use a notebook with ntp disabled and port-forwarded orderer endpoint. Be aware that if your kubernetes authentication is token-based, it can stop working because of having the incorrect time. In Azure, this is fixed by getting admin config.

That environment should be enough for step-by-step replaying of your standard certificate rotating scripts. If you don't have any, dive into this issue.

Upvotes: 0

user8030553
user8030553

Reputation:

I am on fabric v2.3 and using Fabric CA.

When we re-enroll the peers, orderer or admin it will generate a new pair of certifcates.

Please correct me if i am wrong, these newly generated certificates needs to be updated in the channel configuration as well? At least this is what the doc says here

I tried to follow the doc and it does contains the root_certs and tls_certs which we need to replace. A usual sample config block after decoding it into json files looks something like this. The respective certs needs to replaced here which seems quite error prone since it's manual and a lot of certs needs to be replaced (depending on the number of peers, orderers, and organisations you've got). And, also not to forget these certs are referenced by the ccp.yaml and ccp.json as well which is used by the fabric sdk.

I am not sure if my understanding is correct about this, as I am struggling with this thing as well. I haven't been able to successfully pull this of as of now. It's strange that hyperledger fabric/Fabric CA doesn't really has a straightforward way of doing this.

Upvotes: 0

Kartik Chauhan
Kartik Chauhan

Reputation: 3068

You can change the default expiry time of an x509 certificate by changing its duration in the fabric-ca-server configuration file. You'll find this file inside CA's docker container.

Reference to the fabric-ca-server configuration file can be found here.

Change the value of expiry from 8760h to xxxx in the signing section of the file. signing section looks like this:

signing:
    default:
      usage:
        - digital signature
      expiry: 8760h
    profiles:
      ca:
         usage:
           - cert sign
           - crl sign
         expiry: 43800h
         caconstraint:
           isca: true
           maxpathlen: 0
      tls:
         usage:
            - signing
            - key encipherment
            - server auth
            - client auth
            - key agreement
         expiry: 8760h

After changing the value of expiry, you'll have to restart your CA container for the changes to take effect.

Once your container is restarted, re-enroll your admin to create a new x509 certificate with the updated expiry duration. You can read about reenrolling an identity from here.

If you want to avoid such scenarios in the future for any user, you can reenroll it before doing a transaction. You can perform the re-enroll operation if the certificate has already expired or going to expire in the next x amount of time.

Upvotes: 0

Related Questions