2

In reference to this article HYPERLEDGER FABRIC CERTIFICATE AUTHORITY(CA), I am trying to understand the relationship between the Fabric-CA Root server and the Fabric-CA Intermediate server. Is it correct to say that, in the entire article, what has been discussed is – How to setup an “Intermediate” server? If so, where is the Root server located? How does the Intermediate server discover / communicate with the Root server?

[Diagram from the article] [enter image description here]2

Amarsh
  • 11,214
  • 18
  • 53
  • 78

1 Answers1

2

First and foremost I would suggest you to refer to the Fabric Official documentation : http://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#overview

Any changes and corrections would be always reflected to the official documentation.

The entire article has been explained on how to setup a Hyperledger Fabric CA Server cluster. (Ref: Difference between Fabric CA server and CA Client) If you look at the diagram closely, you would be able to recognize that there is indeed a Root CA server. The reason the root CA is kept aside is because of security reasons. In case the root CA server/Root of Trust is compromised, the entire network will be compromised. Protecting the root of trust is of utmost importance in PKI and this is a standard practice of setting up a PKI (Public Key Infrastructure)

The role of one or more intermediate CA servers is to act as Certification Authorities to register, issue E-Certs/T-Certs, renewal and revocation of certs on behalf of the root CA having the same root of trust.

The diagram shows a cluster of Intermediate CA servers in Highly Available configuration using HA-Proxy coupled with a relational database (you can again opt for using a HA cluster of your database) to store all the user information.

You can enroll an intermediate CA server just like you would do for normal users (peer/app) :

fabric-ca-server start -b admin:adminpw -u http://<enrollmentID>:<secret>@<parentserver>:<parentport>

For more reference you can refer : http://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#enrolling-an-intermediate-ca

arnabkaycee
  • 1,634
  • 13
  • 26
  • Thanks Arnab. In this regards, I am playing with the balance-transfer example ( https://github.com/hyperledger/fabric-samples/tree/release/balance-transfer ). Will that be right to say that the CA servers they are starting (using https://github.com/hyperledger/fabric-samples/blob/release/balance-transfer/artifacts/docker-compose.yaml ) are all Root servers? – Amarsh Jan 04 '18 at 22:52
  • Yes they are solo root CA servers. One for each org. – arnabkaycee Jan 05 '18 at 03:59
  • Thanks again. Another question then ... if two orgs OrgA and OrgB have a CA each (CA-A and CA-B), and these two CAs are not connected to each other, then can a message signed by the private key issued by CA-A be decrypted by a client in OrgB? My understanding of how it works with the web for HTTPS is that all browsers have a root certificates (provided by a Root CA like Verisign), hence the browsers can talk to servers etc. In our case, is CA-A also connected to CA-B through a Root CA? Or is this the case that CA-A is only suppose to auth clients within OrgA and not inter-Org communication? – Amarsh Jan 05 '18 at 05:56
  • 1
    All peer organizations are bound by the orderer organization. If you talk about the balance-transfer example, it is example.com. So the root of trust of the orderer org helps to decrypt the messages from the peer orgs. All of Fabric works on the concept of PKI which utilizes the concept of root of trust. – arnabkaycee Jan 05 '18 at 09:14