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.
Related
I noticed that HLf admincerts and tls certs, by default, have an expiration date of 1 year. In my case, they have expired and my orderer and peer nodes are giving me a bad certificate error.
Is there any way to do certificate rotation? I don't want to loose any data as the network is in a production enviroment. I am using hyperledger fabric 1.4 version with the raft ordering service.
You can change the default expiry time of an x509 certificate by changing its duration in the fabric-ca-server configuration file. You'll find this file inside CA's docker container.
Reference to the fabric-ca-server configuration file can be found here.
Change the value of expiry from 8760h to xxxx in the signing section of the file. signing section looks like this:
signing:
default:
usage:
- digital signature
expiry: 8760h
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: 8760h
After changing the value of expiry, you'll have to restart your CA container for the changes to take effect.
Once your container is restarted, re-enroll your admin to create a new x509 certificate with the updated expiry duration. You can read about reenrolling an identity from here.
If you want to avoid such scenarios in the future for any user, you can reenroll it before doing a transaction. You can perform the re-enroll operation if the certificate has already expired or going to expire in the next x amount of time.
I am on fabric v2.3 and using Fabric CA.
When we re-enroll the peers, orderer or admin it will generate a new pair of certifcates.
Please correct me if i am wrong, these newly generated certificates needs to be updated in the channel configuration as well? At least this is what the doc says here
I tried to follow the doc and it does contains the root_certs and tls_certs which we need to replace. A usual sample config block after decoding it into json files looks something like this. The respective certs needs to replaced here which seems quite error prone since it's manual and a lot of certs needs to be replaced (depending on the number of peers, orderers, and organisations you've got). And, also not to forget these certs are referenced by the ccp.yaml and ccp.json as well which is used by the fabric sdk.
I am not sure if my understanding is correct about this, as I am struggling with this thing as well. I haven't been able to successfully pull this of as of now. It's strange that hyperledger fabric/Fabric CA doesn't really has a straightforward way of doing this.
Our case: k8s, fabric v2.2, mutual tls requied for all hyperledger connections, certificates expired 3 days ago.
First of all we need to pass through expired tls. Add to the orderer config:
ORDERER_GENERAL_TLS_TLSHANDSHAKETIMESHIFT: 120h
ORDERER_GENERAL_AUTHENTICATION_NOEXPIRATIONCHECKS: "true"
The latest parameter will allow to use expired MSP entities later.
To skip tls checks on the peer side, use the --tlsHandshakeTimeShift 120h parameter.
After the connection was restored, we need to update certificates in the blockchain. Unfortunately there is no analog of the _NOEXPIRATIONCHECKS option for the peer, so we need to use a time-shifted environment. I didn't manage to run the one in the kubernetes, so I had to use a notebook with ntp disabled and port-forwarded orderer endpoint. Be aware that if your kubernetes authentication is token-based, it can stop working because of having the incorrect time. In Azure, this is fixed by getting admin config.
That environment should be enough for step-by-step replaying of your standard certificate rotating scripts. If you don't have any, dive into this issue.
I want 4 intermediate CAs for a peer organization: ICA1, ICA2, ICA3 and ICA4 - one for every Node OU (peer, orderer, admin and client).
Let's say if I place ICA1 as the cacerts attribute in the Peer Node OU of the channel configuration, then will a peer identity under a different ICA (ICA2, ICA3 or ICA4), be able to satisfy a policy which says signature of "OrgMSP.peer"?
If yes, then how can I make sure that only the set of roles under a specific department can satisfy a policy given by OrgMSP.<role>? I do not wish to create an MSP definition for every department or team in the organization. So, is it achievable without that?
If no, then can I also specify a group of ICAs in the Node OU configuration of the channel for a particular OU so that I can leverage very complex policies like "Signature of one-of 'OrgMSP.peer'" and let's say that here, cacerts property for the peer OU will be ICA1 and ICA3. Is this achievable?
When you specify the nodeOU configuration, you may simply supply the OU name corresponding to the role (it sounds like this is what you've done), or you may specify the OU name and an issuing certificate. This could be a root CA, or an intermediate CA, but in either case, in order to satisfy that role, the certificate must have both the OU specified and be issued by the specified CA.
Note: Each role/certificate pair informs the MSP of a valid issuer for certificates satisfying a role. So, if you have CA1, CA2, ICA1, and ICA2, you may specify a given role twice, once for CA1 and once for ICA2. Then only certificates (directly) issued by either CA1 or ICA2 may satisfy the role.
If you look in the sample MSP configuration, you can see that certificate may be specified, but is omitted by default.
You can see more details about how this certificate is used in the actual proto documentation.
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'm trying to send a pkcs10 CSR to a CA but need to define the life/validity of the certificate and override the profile information created in the CA. I'm using BouncyCastle 1.55 and org.bouncycastle.pkcs.PKCS10CertificationRequestBuilder.
Thanks in advance of the help!
pKCS#10 may set some attributes that CA could include (or not) in the certificate. But the validity of the certificate is not one af those fields. You can see the list of.available in the PKCS#9 RFC
The information about the validity period (lifetime) is not part of the certificate signing request - also not listed as optional attribute in PKCS#9.
Extract requested validity period from a Certificate Signing Request using OpenSSL
These two actions seem to do the same:
using the Basic Constraints extension in a X.509 Certificate to signify that it is a CA certificate and
using the Key Usage extension e.g. to signify that the public key can be used for certificate signining.
What is the difference between these extensions?
Do they serve same purpose or complement each other?
"Key Usage" defines what can be done with the key contained in the certificate. Examples of usage are: ciphering, signature, signing certificates, signing CRLs.
"Basic Constraints" identifies if the subject of certificates is a CA who is allowed to issue child certificates.
For a certificate that can be used to sign certificates, the info is in some sense duplicated:
X509v3 Basic Constraints: CA: TRUE --- Can sign certificates
X509v3 Key Usage: Key Cert Sign --- Can sign certificates
But "Basic Constraints" will also specify the maximum depth of valid certification chain.
Though it is duplicated, you need to specify both, according to RFC 3280 --- X.509.
This is the relevant paragraph from the RFC (page 29):
The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on public key certificates. If the
keyCertSign bit is asserted, then the cA bit in the basic
constraints extension (section 4.2.1.10) MUST also be asserted.
Key Usage describes intended purposes of the certificate.
Basic Constraints extension describes how deep the certificate chain that has the certificate as it's top can be. In other words, this extension is used by CAs to restrict activity of their sub-CAs when the sub-CA certificate is issued. If toplevel CA gets a sub-CA , it allows sub-CA to issue end-user certificates, but doesn't allow sub-CA have it's own sub-CAs.