问题
Note: I am using the Go SDK, but this should apply to Node, Java, etc. SDKs.
I am using a fabric-ca
instance as my Certificate Authority, and for a realistic production environment I need to use a secure connection.
Based on the config-e2e.yaml
example configuration file [1], we should be able to use https
in the CA url. Example:
certificateAuthorities:
org1-ca:
url: https://localhost:7054
However, once https
is required, the SDK requires that the TLS cert/key filepath is added in the client
section [1]:
tlsCACerts:
# Comma-Separated list of paths
path: {filepath}
# Client key and cert for SSL handshake with Fabric CA
client:
key:
path: {filepath}
cert:
path: {filepath}
However, other docs [2] indicate that the tlsCACerts
section is for mutual TLS connections, and based on my limited understanding of TLS [3], mutual TLS should not be needed for an https
connection (most browsers don't use mutual TLS to secure the connection).
Can someone explain:
1) The most simplistic way to secure (https) a connection between the SDK (client) and the CA / peer / orderer?
2) Why we are hard-coding TLS cert/key filepaths into the config file when these should be refreshed very often when use in production?
NOTE: This question/answer seems to indicate that you don't need mutual TLS for a secure connection, but if I add https:
to my CA url, I get errors until I fill in the tlsCACerts
section.
[1] https://github.com/hyperledger/fabric-sdk-go/blob/master/test/fixtures/config/config_e2e.yaml
[2] (see "client authentication" vs. server-side TLS settings) https://hyperledger-fabric.readthedocs.io/en/release-1.2/enable_tls.html
[3] http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLSPrimer.html
回答1:
The answers below are w.r.t. the Node SDK but hope they shed some light on the question
1) The most simplistic way to secure (https) a connection between the SDK (client) and the CA / peer / orderer?
The node sdk does not support communicating with a fabric ca server that has clientauth (aka mutual TLS) enabled [1]
The TLS certificate provided by a (TLS enabled) server is validated against the certificate in tlsCACerts
. The validation process can be thought of as running below command:
openssl verify -CAfile <tlsCACerts> <cert-provided-by-server>
The tlsCACerts
property is set per peer, orderer and fabric ca server in the network-config.yaml file - all of them could use different tlsCACerts
if they wanted.
For the peer and orderer, the node sdk does support clientauth (or mutual TLS) but it has to be setup in code not the config file as described in [2] - see the section where they show how to use client.setTlsClientCertAndKey(cert, key)
The statement in the question that
tlsCACerts section is for mutual TLS connections
is wrong.
2) Why we are hard-coding TLS cert/key filepaths into the config file when these should be refreshed very often when use in production?
I don't think these would be refreshed very often. And if they were, then, ironically, config would be the right place IMO.
This statement in the question
mutual TLS should not be needed for an https connection (most browsers don't use mutual TLS to secure the connection).
is correct. Mutual TLS enables bi-directional verification i.e., the server also validates the client. In one-way TLS, it is only the client that validates the server.
来源:https://stackoverflow.com/questions/52263585/hyperledger-fabric-sdk-https-tls-cert-key