I am a bit confused about the consensus-based network administration.
In my understanding of hyperledger fabric, the CA server is a single point of administration. Even though it is possible to create organization-specific CA servers, there should be one main CA to verify the chain of trust.
For example, the one who administers the CA server can create the required number of identities to break the consensus.
Please clarify if I am wrong.
Thanks & Regards,
Akhil KM
#Akhil KM
CA server is not a complete administration in the fabric network
it is just giving certificates and the MSP is the complete administration and that to not to the whole consortium. Each entity can have different MSP means different CA's can issue certificates. One org can have more than one CA
CA in the fabric is exactly equivalent to normal CA in current all public-key cryptography like how browsers show us secure https by trusting the certificate
In fabric or in website world CA will never become an administrator. CA will have an administrator (To operate CA :) )
Related
In Hperledger caliper for benchmarking of fabric network, I have provided the connection profile with detail of CA. The transaction is successfully submitted to the network which is in the remote machine. I have checked the logs on peers, orderers, and CA. Only CA didn't have a log of requests to the CA server.
In my assumption, while submitting the transaction using fabric gateway the invoker identity must be verified by the CA. But this is not happing as a result of my configuration.
In which case CA server does not need to be enabled while submitting the transactions?
Edit: The question is edited to make the question specific to the involvement of CA while submitting the secure transaction on TLS enabled system.
Thank you!
It seems necessary to study the PKI and certificate(X.509) structure. Fabric-CA acts as an organization's CA and manages the identifiers of the each organization's member(orderer, peer, client...).
The authentication/authorization process for an identifier can be performed based on a certificate issued to a CA, but it does not need to be associated with a CA during the process.
In other words, during the P2P verification process, the CA is independent.
Taking the legacy system as an example, Facebook has issued a certificate from digicert, and the browser can verify the identifier through that certificate. (For Root CA verification, it is provided whitelisted at your browser or OS level level.)
It's like asking why you don't use digicert (Fabric-CA) when you say you do a transaction throughput benchmark for Facebook (peer/orderer).
Fabric-CA does not have a ledger and is not support for reading or storing transactions in the blockchain. it is just CA in Fabric Network, independent of the transaction processing benchmark.
If authentication/authorization for a resource has to be performed in the form of a live stream to a CA, it will have dependencies and cause big problems
(e.g. if digicert's system is paralyzed, Facebook will be paralyzed too)
in process, Fabric-CA issues an identifier on the network at the bootstrap stage before performing the benchmark, rather than verifying in the transaction processing process (if it has been created in advance through cryptogen, issuance. It can be seen as being.)
I want to know that is there any way in which I can use my hardware token containing digital signature (issued by my country CA) to sign a transaction in hyperledger fabric or any other blockchain framework.
I know that there is a concept of external CA in hyperledger fabric but that doesn't apply to a real world CA.
At Hyperledger Fabric, every agent has its own certificates. These certificates are always issued by a CA. So, yo can integrate the certificates issued by your country's CA.
For that, you have to define the corresponding MSP instances that you will use. Also, you will require the certificates for each of the agents that you will set up.
I am wondering if Fabric CA server must be run in 24hours. If so, do I need any server computer(cloud or physical)?
Is there no other way to resolve authentication issue by nodes autonomously without server cost?
No. The CA is only for users and nodes to be created. But once you have an certificate from the CA, you don't need it in order to transact on the Blockchain.
However, if you want to revoke a user/node you will need the CA to create a CRL.
I am trying to get an intermediate CA and use that to generate all the certs for a particular organization. I am currently using fabric-sample as a base reference.
Currently crypto-config.yaml, creates a root CA for each org and than use that to generate all certs for that org.
How can I change the crypto-config.yaml file, so that
either, it generate root CA and intermediate CA also for each org
and use that as signing CA for peer and admin certs.
or, it takes an already created root CA cert and key for each org, and than generate intermediate CA and use that as signing CA for peer and admin certs.
Then I will use docker-compose-e2e-template to start intermediate CA and all peers and orderer.
Is this approach is fine? If not, what is the easiest way to achieve the intermediate CA and use this CA to generate all peers and admin cert?
Thanks for any help!!
cryptogen is really just a tool for creating the crypto material for basic test networks and is really designed to be independent of of Fabric CA (although it's possible to start a Fabric CA using the root cert pair generated for each organization).
If you actually want to set up Fabric CA with root and intermediate CA's, I'd recommend using Fabric CA directly. Of course this means that you'll need to distribute / bootstrap all of your peer and admin certs yourself as well.
I'd recommend reading https://hyperledger-fabric-ca.readthedocs.io/en/release-1.2/users-guide.html#enrolling-an-intermediate-ca which explains how to set up intermediate CAs by pointing them at an already established root CA.
You can then follow https://hyperledger-fabric-ca.readthedocs.io/en/release-1.2/users-guide.html#registering-a-new-identity to enroll your admin identities against the intermediate CA and https://hyperledger-fabric-ca.readthedocs.io/en/release-1.2/users-guide.html#enrolling-a-peer-identity for enrolling your peer identity.
Note that you will need to add the admin public key to the admincerts folder of the MSP for the appropriate peer(s).
I went through documentation on fabric-ca
http://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html
I have below questions
1.When will be fabric-ca come into picture in hyperperledger for user authentication or in msp certs generation or in both
Can we use some other third party CA in place of fabric-ca
What should be the things to be kept in mind if we use some third party CA.
Is there any sample to understand it more(already went through balance-transfer)
fabric-ca comes into the picture for both authentication and MSP certs generation. The /enroll API requires basic authentication, and assuming success, will issue an enrollment certificate and populate the appropriate MSP directories.
You have the following choices when it comes to using a CA with fabric:
a) Use fabric CA to function as a root CA and/or intermediate CA.
b) Start fabric CA with an intermediate signing certificate which you
get from an external CA.
c) Don't use fabric CA at all and use an external CA completely.
With a & b, the fabric CA server can function as its own user registry,
or it can talk to an LDAP server as the user registry.
3) When using a 3rd party CA (#c above), you will need to think about
how you want to do access control in chaincode. One option is based
on the OU (Organizational Units) that a user's certificate has, which
means the 3rd party CA will need to be able to restrict which OU
values are issued to which users. When using the fabric CA server
to issue certificates, you can use Attribute-Based Access Control
(ABAC) to perform access control for chaincode.
4) There is a sample which is not merged yet at https://gerrit.hyperledger.org/r/#/c/13213/.
See the README.md for a description of how to run the sample and
an overview of how it works.