In a scenario where the root CA certificate gets compromised, if I revoke the certificate with serial number and AKI in fabric CA, will it automatically revoke all the certificates created by the root certificate also? Or should I individually revoke each certificate?
MSPs explicitly enumerate the root and intermediate CA certificates, as well as the CRL. Rather than attempt to add the CA certificate to the CRL, simply remove the CA certificate from the configuration.
In the case of the local MSP, simply delete the PEM file from MSP directory structure and restart the process.
In the case of the channel MSP definitions, simply remove the certificate from the list of root_certs or intermediate_certs in the channel config.
Once the certificate is no longer in the MSP config, no certs issued by that CA (or its intermediaries) will be considered valid, so there is no need to explicitly list the certs it issued in the CRL.
Related
What is the recommendation to deal with an expired peer certificate? Must the network admin periodically update the local MSP of peer with renewed certificate?
MSP identities never expire.
It is important to note that MSP identities never expire; they can only be revoked by adding them to the appropriate CRLs. Additionally, there is currently no support for enforcing revocation of TLS certificates.
https://hyperledger-fabric.readthedocs.io/en/latest/msp.html
Background:
Fabric documentation says that MSP optionally might have a folder with Intermediate CAs (ICA) as shown below.
Question:
What is the purpose of having this folder? From what I understand each ICA cert is signed with root CA cert, and root CA cert is added to MSP configuration. So it seems that even if fabric MSP does not have folder with ICA it anyway has means to validate the incoming request (because it has root cert.)
I may assume that having ICA might be used not for validation but for some configuration and giving different roles to identities signed by different ICAs, but it is vague for me how exactly it can be used.
Documentation:
Here is related part of Hyperledger Fabric documentation:
Intermediate CAs: This folder contains a list of X.509 certificates of
the Intermediate CAs trusted by this organization. Each certificate
must be signed by one of the Root CAs in the MSP or by an Intermediate
CA whose issuing CA chain ultimately leads back to a trusted Root CA.
An intermediate CA may represent a different subdivision of the
organization (like ORG1-MANUFACTURING and ORG1-DISTRIBUTION do for
ORG1), or the organization itself (as may be the case if a commercial
CA is leveraged for the organization’s identity management). In the
latter case intermediate CAs can be used to represent organization
subdivisions. Here you may find more information on best practices for
MSP configuration. Notice, that it is possible to have a functioning
network that does not have an Intermediate CA, in which case this
folder would be empty.
Like the Root CA folder, this folder defines the CAs from which
certificates must be issued to be considered members of the
organization.
One of the primary reasons that I can think of setting up an intermediate CA is to protect your root of trust. Your organization or sub organization may be allocated a certificate of identity that you want to protect dearly. So, you safe guard it by deriving/generating one or more intermediate certificates and setting up the corresponding CAs so that your root certificate can stay in a safe zone (say DMZ) and you can stil obtain the benefits of verification & signing using your intermediate certificates and CAs. Verification would still remain unaffected as your intermediate certs and CAs chain to the single root of trust from where it was issued.
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 am trying to implement the OPC UA verification of certificates with OpenSSL in C. Therefore I have multiple certificates which are stored in different directories.
The directories are:
CertificateTrustListDir: The folder where certificates of trusted CAs are stored.
CertificateRevocationListDir: The folder where the revocation lists for the trusted CAs are stored.
IssuersCertificatesDir: The folder where issuer certificates are stored. Issuer certificates are CA certificates necessary for the verification of the full trust chain of CA certificates in the trust list.
IssuersRevocationListDir: The folder where revocation lists for issuer CAs should be stored.
I was looking into this example and discovered the function SSL_CTX_load_verify_locations. Unfortunately I can only set the location of the trusted CAs with this method.
Is there a way to tell OpenSSL to use the directories in the supposed way?
Regards,
ckmk14
I am not entirely sure but this is how I have done:
With the X509_STORE_CTX_init function I can pass a X509_STORE with the trusted certificates (CertificateTrustListDir) and the CRLS (CertificateRevocationListDir + IssuersRevocationListDir).
The certificates of the IssuersCertificatesDir can be passed as stack with the chain-parameter of the X509_STORE_CTX_init function.
What exactly is difference between enrolling and registering a certificate in Hyperledger Fabric CA. I am new to cryptography and i am really confused about the working of Fabric CA. Also how are certificates generated via cryptogen is diffrent from certificates generated via Fabric CA.
So from what i understand when you "enrol" an identity you get the certificates and private keys for it. When you "register" the identity, you are simply creating the user name and password for that identity with the CA server.
The certificates that the cryptogen tool generate are not any different to the ones generated by the Fabric CA, the cryptogen tool is there for convenience in development. It should not be used in a live / production environment. Under the hood the cryptogen tool actually spins up a fabric ca server locally.
Here is a link to the latest documentation for Fabric CA:
https://hyperledger-fabric-ca.readthedocs.io/en/latest/
"Registration" is done by the CA admin. A username and password is assigned to an identity, along with attributes (will the identity be an admin or a node, for example?). This registration places the username and password, along with the relevant other information about the identity, in the database of the CA. No certificates have been generated at this point. The identity has simply been registered.
"Enrollment" is the process where certificates are created and given to the user of the identity. The username and password is given to this user out of band, and they use the name and password as part of a fabric-ca-client call to the CA. The public and private keys --- encoded with the relevant attributes registered with the CA --- are then generated.
The reason for the separate between registration and enrollment is to ensure that only the user of an identity receives their private key.
The certificates created by a CA are identical to those created by cryptogen --- an x.509 certificate is an x.509 certificate --- but cryptogen is a tool for quickly creating certs in a test environment, not a true method for creating certificates for anything resembling production.
Registering identity means adding its details in Fabric CA.
Enrolling means process when registered identity connects to CA and sends Certificate Signing Request (CSR) to it. CA checks if the identity is registered and performs some other validations, if checks are successful then it returns signed certificate to the identity. Since the certificate is signed by CA trusted by blockchain network, the identity has now means to interact with the network using this certificate.
So, to make the identity being able to interact with the network it must pass two steps in this particular sequence:
Be registered on CA
Be enrolled
Admin is preregistered in CA using when it is started
fabric-ca-server start -b admin:adminpw
The details are here:
https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html
also you can refer to source
The concept of first register(Saving username,password and other attributes in CA's DB) then registered identity can enroll to get certificates is the same in the latest version of Fabric CA as it was previously.
Refer to the latest link:
https://hyperledger-fabric.readthedocs.io/en/latest/deployment_guide_overview.html#step-four-use-the-ca-to-create-identities-and-msps
"Register and enroll an admin identity and create an MSP. After the CA that will be associated with an organization has been created, it can be used to first register a user and then enroll an identity (producing the certificate pair used by all entities on the network). In the first step, a username and password for the identity is assigned by the admin of the CA."