About the use of FABRIC-CA

Root CA
CAs are generally grouped by organization, that is, ORG1,ORG2,ORG3 have their own CAs.
When the CA is started, two environment variables, fabric_ca_server_ca_certfile and Fabric_ca_server_ca_keyfile, are set.
What happens if you don't set these two up? In fact, if not set, the CA server will generate these two files on its own according to the default CA CONFIG.
This time the CA is called the ROOTCA.
· Fabric_ca_server_ca_certfile is the certificate of the current CA (public key)
· Fabric_ca_server_ca_keyfile is the private key of the current CA
The CA certificate (public key) is based on the contents of the CSR domain in Fabric-ca-server-config.yaml to generate the request, and then use the contents of the signing domain for self authentication, generated files.
The CA's private key is a file generated from the contents of the BCCSP domain within FABRIC-CA-SERVER-CONFIG.YAML.
The default is to generate Ca-cert.pem and Ca-key.pem and msp/keystore files, if config is configured, except for config and DB files,
The other is deleted, then execute the following command, will follow your profile, generate root and root private key certificate
Fabric-ca-server Init-b ADMIN:ADMINPW

--------------------------------------------------------------------------------------------------------------- -----------

The following is an example of how to take advantage of a CA-generated key and certificate (starting from the initial state)

1.ca server startup, or by default, i.e. (Fabric_ca_server_ca_certfile, fabric_ca_server_ca_keyfile) using Ca/msp files under peer
2.CA-CLI Start, Register Admin user
Fabric-ca-client enroll-u http://admin:adminpw@ca.org1.example.com:7054-m Admin/msp
3. Register with Admin user Peer0
Fabric-ca-client register-m Admin/msp--id.name peer0--id.type peer--id.affiliation org1--id.secret peer0pw-u http:// ca.org1.example.com:7054
Fabric-ca-client enroll-u http://peer0:peer0pw@ca.org1.example.com:7054-m Peer0/msp
4. Replace the default file generated by generateartifacts.sh
In fact, there are 3 of files generated in Ca-client
Admin/msp/cacerts/ca-org1-example-com-7054.pem
Admin/msp/keystore/xxxx_sk
Admin/msp/signcerts/cert.pem
CA-ORG1-EXAMPLE-COM-7054.PEM, which is set at CA server startup Fabric_ca_server_ca_certfile
Such a dozen need to replace the other two with the contents of the corresponding folder can be
Replace admin's content
Crypto-config/peerorganizations/org1.example.com/msp/admincerts
Crypto-config/peerorganizations/org1.example.com/peers/peer0.org1.example.com/msp/admincerts
Crypto-config/peerorganizations/org1.example.com/peers/peer1.org1.example.com/msp/admincerts
Crypto-config/peerorganizations/org1.example.com/users/admin@org1.example.com/msp/admincerts
Crypto-config/peerorganizations/org1.example.com/users/admin@org1.example.com/msp/keystore
Crypto-config/peerorganizations/org1.example.com/users/admin@org1.example.com/msp/signcerts
Replace the contents of Peer0
Crypto-config/peerorganizations/org1.example.com/peers/peer0.org1.example.com/msp/keystore
Crypto-config/peerorganizations/org1.example.com/peers/peer0.org1.example.com/msp/signcerts
5. Make the first piece of creation
6. Start all nodes
7. Implementation of the E2E example
Everything OK no problem

### #发现的问题 #

1 when the host, CA container, SQLite three times are synchronized, do the creation of the first block, the following error occurred

Crit 002 Setting up the MSP Manager failed, err the supplied identity is not valid, Verify () returned x509:certificate ha s expired or is not yet valid

The reason is that after the CA container starts, the issued certificate is a few minutes earlier than the Cryptogen generation certificate. Temporary solution, let the CA server start 5 minutes after the admin enroll

2 The following error occurred while executing the E2E example

Erro 001 Error trying to connect to local peer:x509:certificate signed by unknown authority (possibly because of "x509: ECDSA verification Failure "while trying to" Verify candidate Authority Certificate "tlsca.org1.example.com")

The reason is not to delete the container after the last execution ....

--------------------------------------------------------------------------------------------------------------- -----------
Other

1, it is strongly recommended not to Cryptogen and CA cross use, from the beginning to use the CA to do all the key and certificate.
Because, with the admin to send peer certificate, to replace peer you have to replace the admin, so good trouble.

2,fabric-ca-server-config.yaml is used to define the CA server's own private key and certificate
Fabric-ca-client-config.yaml is used to define the parameters needed to execute the register and enroll at the Ca-cli end, such as the CN of the request book CSR.

3.ca servers should be grouped according to organization.

4.HF. The value inside the registrar.roles can be defined arbitrarily.

5. If you are enroll again, after placing the new certificate in the appropriate path, restart all peer nodes, remembering that all, that is, all peer nodes within the same channel,

Otherwise, a gossip communication exception will occur. Reboot is not restart, it is to stop first and then start again.

6. With regard to the use of Tlsca, when you use OpenSSL to generate TLS files, you need to sign, this time you can use Tlsca.
Tlsca can be generated through the CA server, can also be OpenSSL, with OpenSSL, is a self-signed certificate.
There is also a saying that the TLS folder is used for the server side, and that Tlsca is used for CLI clients.

7. This is required when the CA uses TLS.
Before the ①CA server starts, configure the CA server configuration file as follows
---------------------------------------
Tls:
Enabled:true
Certificate of CERTFILE:CA Server
KEYFILE:CA the private key of the server
ClientAuth:
Type:noclientcert
Certfiles:
Ca:
Name
KEYFILE:CA the private key of the server
Certificate of CERTFILE:CA Server
Chainfile:
---------------------------------------
➁ca Server Startup
③ Copy CA Root certificate generated by CA server to a location that CA clients can access
④CA client boot, boot parameters inside Fabric_ca_client_tls_certfiles=ca root certificate, other do not configure
⑤fabric-ca-client Regrister Enroll
※ The important place is Noclientcert, if you set other values, you need to use other tools to generate the TLS file, and then configure to the CA client

The admins defined by

8.fabric-samples/balance-transfer/config.json
is org's admin, which is used to register Jim users, this admin and CA Config inside the definition of the Registry.identities admin must be consistent.
Additionally, when the CA server is started, a boot user is needed, which is the Admin user of the CA and has no relationship with admin in Registry.identities.

9. When the custom CA server's TLS setting is true, Balance-transfer will make an error registering Jim. The
countermeasure is that when the CA server starts, the following four values are set, the first two without special settings, the CA server's configuration file is used,
the root certificate and private key are automatically generated, and the last two files generated by Cryptogen are used as TLS files.
fabric_ca_server_ca_certfile
fabric_ca_server_ca_keyfile
fabric_ca_server_tls_certfile
·fabric _ca_server_tls_keyfile