Fabric CA is at the core of the entire certificate management process. When deploying in a production environment, it must be considered from multiple aspects to fully ensure indicators such as safety, reliability, and standardization.
1. Root certificate generation
The root certificate can currently be applied from an authority (including GolbalSign, VeriSign), or generated by self-signed. Technically speaking, both can complete the deployment process and both guarantee the same security. However, both have their pros and cons in different scenarios, as summarized in the table below
Comparing issued by authority and self-signed
Therefore, if the application scenario not only includes the private network, but also requires a reliable certificate mechanism, it is recommended to use the root certificate issued by an authority; if it is only for the private network scenario and the technical team has rich certificate management experience, you can use the self-signed certificate Method for deployment.
2. Layered deployment structure
In actual deployment, PKI recommends a hierarchical structure, that is, the root CA does not directly issue certificates, but through intermediate CAs or even lower CAs (collectively referred to as intermediate CAs) issued by the root CA, to achieve access to server entities and users For certificate management, Fabric CA supports this function well. Hierarchical CA as shown
The hierarchical structure is adopted because the CA's private key is required to sign the CA's certificate. Once the CA's private key is leaked or the issued certificate is destroyed, the trustworthiness of the CA will be destroyed. The CA and all the security mechanisms that depend on it are rebuilt (it is conceivable that replacing a root CA (Root CA) will bring a lot of changes and challenges).
Therefore, through the hierarchical structure, the risk of damage can be isolated. Even if the private key is leaked, it will only affect an intermediate CA. Moreover, once the CA has a problem, its own certificate can easily be revoked by the upper CA. At the same time, in the case of a hierarchical structure, the root certificate private key can be offline for the strongest level of protection (such as a hardware-based mechanism) to ensure security.
3. TLS mechanism
Fabric CA uses certificates to identify identities in the network and further controls permissions. The TLS certificate protects the communication in the network from another dimension.
The TLS certificate also uses a certificate mechanism for identity recognition when the two communicating parties establish a secure connection. The most common situation is that the server enables the TLS mechanism. In this case, the client will obtain the server's certificate in advance, and request the server to send a signed message, which will be authenticated with a trusted server certificate. Conversely, TLS authentication can also be performed on the client, so as to ensure that all users connected to the server are pre-approved users.
It should be noted that the certificate and TLS certificate in Fabric are at two levels: the former manages the identity of the network; the latter ensures secure connections. In order to achieve a more secure level, it is recommended to enable both mechanisms at the same time.