| Table of Contents |
|---|
Key Points
...
Potential Value Opportunities
Potential Challenges
Dealing with expired certs is indeed difficult. Use a blockchain service that has experience with preventing and resolving cert expirations.
How to manage key rotations to make ledger queries easier
Dave >>
I’ll also say that a cert rotation test using a single orderer node is not representative of production environments. Orderer nodes use the certs in the consenter section to identify each other. If there is only one orderer node it doesn’t have any other orderer nodes to identify! Everything else validates against the org-level issuing CAs configured in the channel MSPs, and since both the old and new certs were issued by the CAs configured in the channel MSPs, they are all still valid.
Baohua >>
It's normal as the old certs are still considered valid by the network.
When it's expired, the transactions signed with old credentials will be blocked.
On Tue, Mar 28, 2023 at 6:03 PM Vijaya Bhaskar <acvbhaskar94@gmail.com> wrote:
Hi All,
I am trying to renew the certificates (identity and tls) of the network.
Following are the steps i have followed.
1)created the network (on kubernetes)
2)executed some transactions and verified it in couch db
3) generated new set of certificates for orderer and peers (i have one orderer and one peer( one peer org))
4) since i have 2 channels , one system channel and one application channel,
a)did a system update (replacing the base64 of newly generated cert in the consenter section) for system channel
b) did another syatem update for application channel
now, before swapping the new certs, i tried to execute a transaction which went through successfully (the old certs are still not expired).
is this normal or am i missing something?
Candidate Solutions
Create a Fabric Write and Read channels for better performance, history
Fabric v2+ has 16 possible channels for separated ledgers
The limitations of the system channel have been eliminated
A performance option - create a fast write channel, automatically copy new blocks to a read channel
The write ledger can be shorter using purge and archive
Using block events, copy the latest block and write to the read channel
The read ledger can have more history
Implementing CQRS - command query responsibility segregation
Run GraphQL queries against the read historical ledger for traceability queries ( vs World State queries )
It may be more efficient to ‘replay’ the blocks/transactions rather than use the chaincode APIs. See the sample of how to process all prior blocks/transactions using block events:
https://github.com/hyperledger/fabric-samples/tree/main/off_chain_data
Your block/transaction re-processing could for example write to a new chain. You could write the original state data as well as some of the original transaction metadata to the new chain to preserve as much historical record as possible.
Dealing with expired certs is indeed difficult. I would highly recommend using a blockchain service that has experience with preventing and resolving cert expirations.
Step-by-step guide for Example
...