Fabric CA集群高可用部署规范及证书配置疑问咨询

First off, let’s address why using the same cert/key pair for both ca0 and ca1 is a bad idea—even if it seems to work initially:

• No Isolation of Risk: If that single shared credential pair gets compromised, every CA node in your cluster is instantly vulnerable. There’s no way to contain the breach to one instance.
• Breaks Auditability: Fabric CA’s design relies on each node having a unique identity. Sharing credentials means you can’t trace which CA node issued a specific certificate or handled a client request—critical for compliance and troubleshooting.
• Potential for Operational Conflicts: While it might run smoothly at first, shared keys can lead to race conditions during signing operations. For example, two nodes trying to sign the same CSR simultaneously could produce inconsistent results, or cause sync issues with the shared database.

Fabric CA clusters use a shared database (your MySQL instance) to sync state between nodes, but each node needs its own unique TLS and signing credentials. Here’s how to do it right:

1. Generate Unique Credentials for Each CA Node #

Every CA instance needs two unique pairs:

• A TLS cert/key for securing client-node communication
• A signing cert/key for issuing certificates to network entities (peers, orderers, users)
  Use the fabric-ca-client tool to generate these for each node, making sure to use unique hostnames in the CSR:

# Enroll CA0 with its unique hostname
fabric-ca-client enroll -u http://admin:adminpw@localhost:7054 --csr.hosts=ca0.yourdomain.com
# Enroll CA1 with its unique hostname
fabric-ca-client enroll -u http://admin:adminpw@localhost:7054 --csr.hosts=ca1.yourdomain.com

2. Configure All Nodes to Use the Shared MySQL Database #

Update each CA node’s fabric-ca-server-config.yaml to point to your MySQL instance—this is how nodes sync registrations, CRLs, and configs:

db:
  type: mysql
  datasource: your-mysql-user:your-password@tcp(mysql-server-ip:3306)/fabric_ca_db?parseTime=true
  tls:
    enabled: false # Set to true if you have TLS enabled for MySQL

3. Start CA Nodes with Cluster-Enabled Flags #

Use either --ca-count or --cafile to enable clustering and ensure nodes trust each other:

Option 1: Using --ca-count (Auto-Discovery) #

This flag tells each CA node how many total instances are in the cluster. Nodes will auto-discover each other via the shared database:

# Start CA0
fabric-ca-server start -b admin:adminpw -d --ca-count 2
# Start CA1
fabric-ca-server start -b admin:adminpw -d --ca-count 2

Option 2: Using --cafile (Explicit Trust) #

If you want to explicitly define which CA nodes are trusted, create a file containing all cluster CA signing certificates, then pass it to each node:

# Combine CA0 and CA1 signing certs into a single file
cat ca0-signcert.pem ca1-signcert.pem > cluster-trust-certs.pem
# Start CA0 with the trust file
fabric-ca-server start -b admin:adminpw -d --cafile cluster-trust-certs.pem
# Start CA1 with the same trust file
fabric-ca-server start -b admin:adminpw -d --cafile cluster-trust-certs.pem

4. Add a Load Balancer (Optional but Highly Recommended) #

To distribute client traffic evenly across CA nodes and handle failover, place a load balancer (like Nginx or HAProxy) in front of the cluster. Configure health checks to automatically remove unhealthy nodes from the pool.

Sharing cert/key pairs might seem like a quick win, but it undermines the security and reliability Fabric CA is designed to provide. The proper setup gives each node unique credentials, syncs state via your MySQL backend, and uses clustering flags to maintain trust between nodes. This approach ensures your CA cluster is highly available, auditable, and secure.

内容的提问来源于stack exchange，提问作者Karthick V