What is the purpose of csr.hosts in fabric-ca-server-config.yaml ?
For ex, see below
csr:
cn: ca-org1
names:
- C: US
ST: "New York"
L: "New York"
O: ca-org1
OU: ca-org1
hosts:
- localhost
- example.com
- ca-org1
ca:
expiry: 131400h
pathlength: 1
Are they used to assign a domain name to the CA server itself or used to point node hostnames which are trying to register or enroll ca identities using CA server as fabric-ca client?
Thanks in advance
I came here looking for the answer but eventually found it myself.
According to the docs:
All of the fields above pertain to the X.509 signing key and certificate which is generated by the fabric-ca-server init.
So as I understand it, hosts correspond to the hosts that the CA certificate is valid for.
If run the server binary fabric-ca-server init --help, one of the flags descriptions is the csr.hosts provided below:
--csr.hosts strings A list of comma-separated host names in a certificate signing request to a parent fabric-ca-server.
So assuming another Root CA sign this CA's csr, csr.hosts tells the Root CA which hosts are valid.
Related
What is the procedure of replacing a root CA cert with another one of a different key pair.
Q-1 : Is that required to follow config update steps to do as we do in add/remove org, since RCA need to change?
(Understood that changing the RCA require to reCreate all peers,nodes, identities as well)
When we use the default setup of fabric CA, then
it bootstraps the fabric ca server with bootstrap administrator - 'fabric-ca-server start -b admin:adminpw -d'
On enrolling the bootstrap administrator -
It creates the following in msp : cacerts, Keystore, sign certs (Set-A)
now when we have to create identities then it uses Set-A, and all such stuff also got bind to the genesis block as well, as certificate got configured via ConfigTX file, and that got stored in the config channel of fabric.
Q-2 : Now If we have to change the RCA's cacerts, Keystore, sign certs (Set-B), then what is the procedure to do that ?
Not found any guidelines or documents on this, It's just logically understood if that is possible then maybe follow the similar steps as we do in add/remove orgs.
Q-3: But even to replace all identities with new RCA along with RCA's cert, key pair etc, then I don't think existing data may work?
if the live network already has x data, but RCA's cacerts, Keystore, sign certs and all identities got changed and also updated the config file with config-update way as we do in add/remove orgs so it has new certificate info ?
To simulate the MSP and certificate expiry of nodes [orderer & peer], I updated the expiry time to 1h (the default is 8760h which is 1 year in hours) in the fabric-ca-server-config.yaml file. I am not sure, if this is the correct way to do it?
Please feel free to correct me
Hyperledger Fabric v2.3 and Fabric CA v.1.5.0
fabric-ca-server-config.yaml: Org1 - the Org1 Fabric CA server is using this config
signing:
default:
usage:
- digital signature
expiry: 1h
profiles:
ca:
usage:
- cert sign
- crl sign
expiry: 43800h
caconstraint:
isca: true
maxpathlen: 0
tls:
usage:
- signing
- key encipherment
- server auth
- client auth
- key agreement
expiry: 1h
Right before the expiry time, I successfully (did not get any error) reenrolled the MSP and TLS certs of all using the fabric-ca-client reenroll command along with --csr.keyrequest.reusekey. More info on the command usage can be found here
I checked the logs in all the nodes and the peer nodes were spitting logs as:
2021-07-27 13:51:11.747 UTC [core.comm] ServerHandshake -> ERRO 0e9 Server TLS handshake failed in 1.807206ms with error remote error: tls: bad certificate server=PeerServer remoteaddress=172.26.0.9:49338
Also, I was not able to transact on the network, which is obvious because of the above error. I believe this affects the MSP and TLS certs generated for the organization admin and user as well.
Could anyone be kind enough to shed some lights on the
fabric-ca-server-config.yaml and how to reenroll or re-issue the
certificates so the fabric-network can function normally?
After the certificates are expired already, the reenroll command is giving error - not a valid certificate. The certificate which is referred in the --tls.certfiles flag is the root CA tls certificate. The root tls certificate of the CA should not expire??
This is a theoretical question about certificate validation in Hyperledger Fabric. How does Fabric handle a scenario like a compromised certificate authority? Does it monitor public log servers to ensure a certificate is valid?
Certificate Revocation Lists
A Certificate Revocation List (CRL) is easy to understand — it’s just a list of references to certificates that a CA knows to be revoked for one reason or another. If you recall the store scenario, a CRL would be like a list of stolen credit cards.
When a third party wants to verify another party’s identity, it first checks the issuing CA’s CRL to make sure that the certificate has not been revoked. A verifier doesn’t have to check the CRL, but if they don’t they run the risk of accepting a compromised identity.
Using a CRL to check that a certificate is still valid. If an impersonator tries to pass a compromised digital certificate to a validating party, it can be first checked against the issuing CA’s CRL to make sure it’s not listed as no longer valid.
link: https://hyperledger-fabric.readthedocs.io/en/release-2.2/identity/identity.html#certificate-revocation-lists
Generating a CRL (Certificate Revocation List)
After a certificate is revoked in the Fabric CA server, the appropriate MSPs in Hyperledger Fabric must also be updated. This includes both local MSPs of the peers as well as MSPs in the appropriate channel configuration blocks. To do this, PEM encoded CRL (certificate revocation list) file must be placed in the crls folder of the MSP. The fabric-ca-client gencrl command can be used to generate a CRL. Any identity with hf.GenCRL attribute can create a CRL that contains serial numbers of all certificates that were revoked during a certain period. The created CRL is stored in the /crls/crl.pem file.
The following command will create a CRL containing all the revoked certficates (expired and unexpired) and store the CRL in the ~/msp/crls/crl.pem file.
export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl -M ~/msp
The next command will create a CRL containing all certificates (expired and unexpired) that were revoked after 2017-09-13T16:39:57-08:00 (specified by the –revokedafter flag) and before 2017-09-21T16:39:57-08:00 (specified by the –revokedbefore flag) and store the CRL in the ~/msp/crls/crl.pem file.
export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl --caname "" --revokedafter 2017-09-13T16:39:57-08:00 --revokedbefore 2017-09-21T16:39:57-08:00 -M ~/msp
The –caname flag specifies the name of the CA to which this request is sent. In this example, the gencrl request is sent to the default CA.
The –revokedafter and –revokedbefore flags specify the lower and upper boundaries of a time period. The generated CRL will contain certificates that were revoked in this time period. The values must be UTC timestamps specified in RFC3339 format. The –revokedafter timestamp cannot be greater than the –revokedbefore timestamp.
By default, ‘Next Update’ date of the CRL is set to next day. The crl.expiry CA configuration property can be used to specify a custom value.
The gencrl command will also accept –expireafter and –expirebefore flags that can be used to generate a CRL with revoked certificates that expire during the period specified by these flags. For example, the following command will generate a CRL that contains certificates that were revoked after 2017-09-13T16:39:57-08:00 and before 2017-09-21T16:39:57-08:00, and that expire after 2017-09-13T16:39:57-08:00 and before 2018-09-13T16:39:57-08:00
export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl --caname "" --expireafter 2017-09-13T16:39:57-08:00 --expirebefore 2018-09-13T16:39:57-08:00 --revokedafter 2017-09-13T16:39:57-08:00 --revokedbefore 2017-09-21T16:39:57-08:00 -M ~/msp
link: https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html#generating-a-crl-certificate-revocation-list
Besides that, Hyperledger Fabric provides Pluggable Consensus Protocol and the security is depends on your plugable MSP too.
I'm following this tutorial and app works, but certificates I created with my server key works
I understand that I need to pass ca option with certificates my server accepts, but I don't know how to specify what I need.
I would like to accept certificates from other CA, not only the ones signed with my server key.
[The peer's certificate must be chainable to a CA trusted by the server for the connection to be authenticated. When using certificates that are not chainable to a well-known CA, the certificate's CA must be explicitly specified as a trusted or the connection will fail to authenticate.][1]
const opts = {
key: fs.readFileSync('server_key.pem'),
cert: fs.readFileSync('server_cert.pem'),
requestCert: true,
rejectUnauthorized: false,
ca: [ fs.readFileSync('server_cert.pem') ],
}
How can I do this?
It depends on how you're validating, but at the very least you would need to have a .CER copy of the other CA certs installed in your machines certificate store in the trusted root certification authorities folder. After that it'd all fall down to validation. Some validation methods automatically query your machines cert store for the certificate. Or you can programmatic it to pull the CA from your certificate store and construct the chain yourself.
The .CER version of the certificate refers to the public copy that does not contain the private keys used for signing a certificate. This cert can validate other certificates that were issued by it, but it cannot sign a certificate.
If you're on a windows machine, you can access your certificate store through the Microsoft Management Console. Open a cmd prompt and type MMC.
Go to file > Add or Remove Snap In > Certificates and select Add. This will prompt you for the specific certificate store you want. If you click the drop down, you'll see additional folders. This will show all trusted certificate authorities in the given store. You will need to add copies of the other CA signing certs here.
I am trying to implement Root CA and intermediate CAs for my network setup. I have already created Root CA and intermediate CA and have already registered and enrolled all the members of the organisation i.e. orderer, peer, admin, users.
Everything is working fine as I have seen the logs of CAs and they are working properly but when I tried to start docker container of peers and orderers they are not getting up, and by looking at the logs of the orderer and peer I am getting these logs:
certificate has expired or is not yet valid yet.
Can anyone help me with this as I have tried few times but everytime I am getting this error only.
Okay I have got the solution here:
https://jira.hyperledger.org/browse/FABC-832
The starting validity period i.e. Not Before of peers is approximately 5 minutes earlier than that of intermediate CA. This is because Fabric CA, by default, backdates the signing of certificates by 5 minutes. So now I have set backdate to 1 second in fabric-ca-config.yaml file:
signing:
default:
usage:
- digital signature
expiry: 8760h
backdate: 1s
profiles:
ca:
backdate: 1s
usage:
- cert sign
- crl sign
expiry: 43800h
caconstraint:
isca: true
maxpathlen: 0
tls:
backdate: 1s
usage:
- signing
- key encipherment
- server auth
- client auth
- key agreement
expiry: 8760h
It seems more like it is a problem with generating of certificates and not with expiring. So they are either haven't been generated yet or where put in a wrong place.
Try to completely restart the docker at first.
Then, add some buffer time after key generation. You can add sleep 300 after cryptogen and configtxgen have been called but before the actual docker containers get spun up.
If it doesn't help, try to trace where the certificates are and where are you try to take them from.