Merge pull request #589 from 125801169/release-2.0

Securing Communication With Transport Layer Security (TLS)

docs/source/enable_tls.rst

@@ -1,145 +1,101 @@
-Securing Communication With Transport Layer Security (TLS)
+使用传输层安全性（TLS）保护通信
 ==========================================================
 
-Fabric supports for secure communication between nodes using TLS.  TLS communication
-can use both one-way (server only) and two-way (server and client) authentication.
+Fabric支持使用TLS的节点之间的安全通信。 TLS通信可以使用单向（仅服务器）和双向（服务器和客户端）身份验证。
 
-Configuring TLS for peers nodes
+为peer节点配置TLS
 -------------------------------
 
-A peer node is both a TLS server and a TLS client. It is the former when another peer
-node, application, or the CLI makes a connection to it and the latter when it makes
-a connection to another peer node or orderer.
+peer节点既是TLS服务器又是TLS客户端。当另一个peer节点、应用程序或客户端与其建立连接时，它是前者；而当它与另一个peer节点或orderer节点建立连接时，则是后者。
 
-To enable TLS on a peer node set the following peer configuration properties:
+要在peer节点上启用TLS，需要设置以下配置属性：
 
  * ``peer.tls.enabled`` = ``true``
- * ``peer.tls.cert.file`` = fully qualified path of the file that contains the TLS server
-   certificate
- * ``peer.tls.key.file`` = fully qualified path of the file that contains the TLS server
-   private key
- * ``peer.tls.rootcert.file`` = fully qualified path of the file that contains the
-   certificate chain of the certificate authority(CA) that issued TLS server certificate
-
-By default, TLS client authentication is turned off when TLS is enabled on a peer node.
-This means that the peer node will not verify the certificate of a client (another peer
-node, application, or the CLI) during a TLS handshake. To enable TLS client authentication
-on a peer node, set the peer configuration property ``peer.tls.clientAuthRequired`` to
-``true`` and set the ``peer.tls.clientRootCAs.files`` property to the CA chain file(s) that
-contain(s) the CA certificate chain(s) that issued TLS certificates for your organization's
-clients.
-
-By default, a peer node will use the same certificate and private key pair when acting as a
-TLS server and client.  To use a different certificate and private key pair for the client
-side, set the ``peer.tls.clientCert.file`` and ``peer.tls.clientKey.file`` configuration
-properties to the fully qualified path of the client certificate and key file,
-respectively.
-
-TLS with client authentication can also be enabled by setting the following environment
-variables:
+ * ``peer.tls.cert.file`` = 包含TLS服务器证书的文件的标准路径
+ * ``peer.tls.key.file`` = 包含TLS服务器私钥的文件的标准路径
+ * ``peer.tls.rootcert.file`` = 包含颁发TLS服务器证书的证书颁发机构（CA）的链上证书文件的标准路径
+
+默认情况下，在peer节点上启用TLS时，TLS客户端身份验证是关闭的。这意味着在TLS握手期间，peer节点将不会验证客户端（另一个peer节点，应用程序或CLI）的证书。要在对等节点上启用TLS客户端身份验证，需要将peer配置中的属性``peer.tls.clientAuthRequired`` 设置为``true`` ，并将该``peer.tls.clientRootCAs.files`` 属性设置为包含CA证书链的CA链文件，该CA证书链为组织（organization）的客户端发布TLS证书。
+
+默认情况下，per节点在充当TLS服务器和客户端时将使用相同的证书和私钥对。要在客户端使用其他证书和私钥对，请将 ``peer.tls.clientCert.file``和 ``peer.tls.clientKey.file``配置属性分别设置为客户端证书和密钥文件的标准路径。
+
+也可以通过设置以下环境变量来启用具有客户端身份验证的TLS：
 
  * ``CORE_PEER_TLS_ENABLED`` = ``true``
- * ``CORE_PEER_TLS_CERT_FILE`` = fully qualified path of the server certificate
- * ``CORE_PEER_TLS_KEY_FILE`` = fully qualified path of the server private key
- * ``CORE_PEER_TLS_ROOTCERT_FILE`` = fully qualified path of the CA chain file
+ * ``CORE_PEER_TLS_CERT_FILE`` = 服务器证书的标准路径
+ * ``CORE_PEER_TLS_KEY_FILE`` = 服务器私钥的标准路径
+ * ``CORE_PEER_TLS_ROOTCERT_FILE`` = CA链文件的标准路径
  * ``CORE_PEER_TLS_CLIENTAUTHREQUIRED`` = ``true``
- * ``CORE_PEER_TLS_CLIENTROOTCAS_FILES`` = fully qualified path of the CA chain file
- * ``CORE_PEER_TLS_CLIENTCERT_FILE`` = fully qualified path of the client certificate
- * ``CORE_PEER_TLS_CLIENTKEY_FILE`` = fully qualified path of the client key
+ * ``CORE_PEER_TLS_CLIENTROOTCAS_FILES`` = CA链文件的标准路径
+ * ``CORE_PEER_TLS_CLIENTCERT_FILE`` = 客户证书的标准路径
+ * ``CORE_PEER_TLS_CLIENTKEY_FILE`` = 客户端密钥的标准路径
+
+
 
-When client authentication is enabled on a peer node, a client is required to send its
-certificate during a TLS handshake. If the client does not send its certificate, the
-handshake will fail and the peer will close the connection.
+在peer节点上启用客户端身份验证后，要求客户端在TLS握手期间发送其证书。如果客户端未发送其证书，则握手将失败，并且peer节点将关闭连接。
 
-When a peer joins a channel, root CA certificate chains of the channel members are
-read from the config block of the channel and are added to the TLS client and server
-root CAs data structure. So, peer to peer communication, peer to orderer communication
-should work seamlessly.
+当peer节点加入通道时，将从通道的配置区块中读取通道成员的CA根证书链，并将其添加到TLS客户端和服务器CA数据结构中。因此，peer节点间通信和peer节点与orderer节点间通信应该无缝地工作。
 
-Configuring TLS for orderer nodes
+
+为orderer节点配置TLS
 ---------------------------------
 
-To enable TLS on an orderer node, set the following orderer configuration properties:
+要在orderer节点上启用TLS，需要设置orderer节点的配置属性:
 
  * ``General.TLS.Enabled`` = ``true``
- * ``General.TLS.PrivateKey`` = fully qualified path of the file that contains the server
-   private key
- * ``General.TLS.Certificate`` = fully qualified path of the file that contains the server
-   certificate
- * ``General.TLS.RootCAs`` = fully qualified path of the file that contains the certificate
-   chain of the CA that issued TLS server certificate
+ * ``General.TLS.PrivateKey`` = 包含服务器私钥的文件的标准路径
+ * ``General.TLS.Certificate`` = 包含服务器证书的文件的标准路径
+ * ``General.TLS.RootCAs`` = 包含颁发TLS服务器证书的CA的证书链的文件的标准路径
 
-By default, TLS client authentication is turned off on orderer, as is the case with peer.
-To enable TLS client authentication, set the following config properties:
+默认情况下，与peer节点一样，orderer节点上的TLS客户端身份验证处于关闭状态。要启用TLS客户端身份验证，需要设置以下配置属性：
 
  * ``General.TLS.ClientAuthRequired`` = ``true``
- * ``General.TLS.ClientRootCAs`` = fully qualified path of the file that contains the
-   certificate chain of the CA that issued the TLS server certificate
+ * ``General.TLS.ClientRootCAs`` = 包含颁发TLS服务器证书的CA的证书链的文件的标准路径
 
-TLS with client authentication can also be enabled by setting the following environment
-variables:
+也可以通过设置以下环境变量来启用具有客户端身份验证的TLS：
 
  * ``ORDERER_GENERAL_TLS_ENABLED`` = ``true``
- * ``ORDERER_GENERAL_TLS_PRIVATEKEY`` = fully qualified path of the file that contains the
-   server private key
- * ``ORDERER_GENERAL_TLS_CERTIFICATE`` = fully qualified path of the file that contains the
-   server certificate
- * ``ORDERER_GENERAL_TLS_ROOTCAS`` = fully qualified path of the file that contains the
-   certificate chain of the CA that issued TLS server certificate
+ * ``ORDERER_GENERAL_TLS_PRIVATEKEY`` = 包含服务器私钥的文件的标准路径
+ * ``ORDERER_GENERAL_TLS_CERTIFICATE`` = 包含服务器证书的文件的标准路径
+ * ``ORDERER_GENERAL_TLS_ROOTCAS`` = 包含颁发TLS服务器证书的CA的证书链的文件的标准路径
  * ``ORDERER_GENERAL_TLS_CLIENTAUTHREQUIRED`` = ``true``
- * ``ORDERER_GENERAL_TLS_CLIENTROOTCAS`` = fully qualified path of the file that contains
-   the certificate chain of the CA that issued TLS server certificate
+ * ``ORDERER_GENERAL_TLS_CLIENTROOTCAS`` = 包含颁发TLS服务器证书的CA的证书链的文件的标准路径
 
-Configuring TLS for the peer CLI
+为CLI节点配置TLS
 --------------------------------
 
-The following environment variables must be set when running peer CLI commands against a
-TLS enabled peer node:
+针对启用了TLS的peer节点运行CLI命令时，必须设置以下环境变量：
 
 * ``CORE_PEER_TLS_ENABLED`` = ``true``
-* ``CORE_PEER_TLS_ROOTCERT_FILE`` = fully qualified path of the file that contains cert chain
-  of the CA that issued the TLS server cert
+* ``CORE_PEER_TLS_ROOTCERT_FILE`` = 包含颁发TLS服务器证书的CA的证书链的文件的标准路径
 
-If TLS client authentication is also enabled on the remote server, the following variables
-must to be set in addition to those above:
+如果在远程服务器上也启用了TLS客户端身份验证，则除上述变量外，还必须设置以下变量：
 
 * ``CORE_PEER_TLS_CLIENTAUTHREQUIRED`` = ``true``
-* ``CORE_PEER_TLS_CLIENTCERT_FILE`` = fully qualified path of the client certificate
-* ``CORE_PEER_TLS_CLIENTKEY_FILE`` = fully qualified path of the client private key
+* ``CORE_PEER_TLS_CLIENTCERT_FILE`` = 客户端证书的标准路径
+* ``CORE_PEER_TLS_CLIENTKEY_FILE`` = 客户端私钥的标准路径
 
-When running a command that connects to orderer service, like `peer channel <create|update|fetch>`
-or `peer chaincode <invoke>`, following command line arguments must also be specified
-if TLS is enabled on the orderer:
+当运行连接到orderer节点的命令时，例如`peer channel <create|update|fetch>`或 `peer chaincode <invoke>`，如果在orderer节点上启用了TLS，则还必须指定以下命令行参数：
 
 * --tls
-* --cafile <fully qualified path of the file that contains cert chain of the orderer CA>
+* --cafile <包含订购者CA的证书链的文件的标准路径>
 
-If TLS client authentication is enabled on the orderer, the following arguments must be specified
-as well:
+如果在orderer节点上启用了TLS客户端身份验证，则还必须指定以下参数：
 
 * --clientauth
-* --keyfile <fully qualified path of the file that contains the client private key>
-* --certfile <fully qualified path of the file that contains the client certificate>
+* --keyfile <包含客户端私钥的文件的标准路径>
+* --certfile <包含客户端证书的文件的标准路径>
 
 
-Debugging TLS issues
+调试TLS问题
 --------------------
 
-Before debugging TLS issues, it is advisable to enable ``GRPC debug`` on both the TLS client
-and the server side to get additional information. To enable ``GRPC debug``, set the
-environment variable ``FABRIC_LOGGING_SPEC`` to include ``grpc=debug``. For example, to
-set the default logging level to ``INFO`` and the GRPC logging level to ``DEBUG``, set
-the logging specification to ``grpc=debug:info``.
-
-If you see the error message ``remote error: tls: bad certificate`` on the client side, it
-usually means that the TLS server has enabled client authentication and the server either did
-not receive the correct client certificate or it received a client certificate that it does
-not trust. Make sure the client is sending its certificate and that it has been signed by one
-of the CA certificates trusted by the peer or orderer node.
-
-If you see the error message ``remote error: tls: bad certificate`` in your chaincode logs,
-ensure that your chaincode has been built using the chaincode shim provided with Fabric v1.1
-or newer.
+在调试TLS问题之前，建议同时在TLS客户端和服务器端启用 ``GRPC debug`` 以获取附加信息。要启用 ``GRPC debug``，需要在环境变量``FABRIC_LOGGING_SPEC`` 中加入 ``grpc=debug`` 。例如，如要将默认日志记录级别设置为``INFO`` ，将GRPC日志记录级别设置为 ``DEBUG``，则需先将日志记录规范设置为 ``grpc=debug:info``。
+
+如果您在客户端看到错误消息``remote error: tls: bad certificate`` ，则通常表示TLS服务器已启用客户端身份验证，并且该服务器未收到正确的客户端证书，或者收到了不信任的客户端证书。确保客户端正在发送其证书，并且该证书已被peer节点或orderer节点信任的CA证书所签名。
+
+如果在链码日志中看到错误消息``remote error: tls: bad certificate`` ，请确保链码是使用Fabric v1.1或更高版本的程序构建的。
+
 
 .. Licensed under Creative Commons Attribution 4.0 International License
    https://creativecommons.org/licenses/by/4.0/

docs/source/logging-control.rst

@@ -1,29 +1,19 @@
-Logging Control
+日志
 ===============
 
-Overview
+综述
 --------
 
-Logging in the ``peer`` and ``orderer`` is provided by the
-``common/flogging`` package. This package supports
+``peer`` 和 ``orderer`` 中的日志是由 ``common/flogging`` 包提供的，这个包支持：
 
--  Logging control based on the severity of the message
--  Logging control based on the software *logger* generating the message
--  Different pretty-printing options based on the severity of the
-   message
+-  根据消息的严重性进行日志记录控制
+-  基于生成消息的软件记录器的记录控制
+-  根据消息的严重性，提供不同的漂亮打印选项
 
-All logs are currently directed to ``stderr``. Global and logger-level
-control of logging by severity is provided for both users and developers.
-There are currently no formalized rules for the types of information
-provided at each severity level. When submitting bug reports, developers
-may want to see full logs down to the DEBUG level.
+目前所有日志都指向 ``stderr``，为用户和开发人员提供了按严重性对日志进行全局和日志级别的控制。目前没有针对每个严重性级别提供信息类型的正式规则。提交错误报告时，开发人员可能希望在 DEBUG 级别查看完整的日志
+
+在正常打印的日志中，日志记录级别由不同颜色的四个字符的代码表示，例如，"ERRO" 表示错误，"DEBU" 表示调试，等等。在日志记录上下文中，*记录器*是由开发人员对相关消息组的命名（字符串）。在下面的正常打印的实施例中，记录器 ``ledgermgmt``, ``kvledger``, 和 ``peer`` 都在生成日志。
 
-In pretty-printed logs the logging level is indicated both by color and
-by a four-character code, e.g, "ERRO" for ERROR, "DEBU" for DEBUG, etc. In
-the logging context a *logger* is an arbitrary name (string) given by
-developers to groups of related messages. In the pretty-printed example
-below, the loggers ``ledgermgmt``, ``kvledger``, and ``peer`` are
-generating logs.
 
 ::
 
@@ -34,80 +24,62 @@ generating logs.
    2018-11-01 15:32:38.357 UTC [peer] func1 -> INFO 006 Auto-detected peer address: 172.24.0.3:7051
    2018-11-01 15:32:38.357 UTC [peer] func1 -> INFO 007 Returning peer0.org1.example.com:7051
 
-An arbitrary number of loggers can be created at runtime, therefore there is
-no "master list" of loggers, and logging control constructs can not check
-whether logging loggers actually do or will exist.
 
-Logging specification
+可以在运行时创建任意数量的记录器，因此没有记录器的“主列表”，并且记录控件构造无法检查记录器是否确实存在或将存在。
+
+记录规范
 ---------------------
 
-The logging levels of the ``peer`` and ``orderer`` commands are controlled
-by a logging specification, which is set via the ``FABRIC_LOGGING_SPEC``
-environment variable.
+``peer`` 和 ``orderer`` 命令的日志记录级别由日志记录规范控制，该规范是通过``FABRIC_LOGGING_SPEC`` 环境变量设置的。 
 
-The full logging level specification is of the form
+完整的日志记录级别规范具有以下形式：
 
 ::
 
     [<logger>[,<logger>...]=]<level>[:[<logger>[,<logger>...]=]<level>...]
 
-Logging severity levels are specified using case-insensitive strings
-chosen from
-
+日志记录严重性级别使用不区分大小写的字符串指定
 ::
 
    FATAL | PANIC | ERROR | WARNING | INFO | DEBUG
 
 
-A logging level by itself is taken as the overall default. Otherwise,
-overrides for individual or groups of loggers can be specified using the
+日志记录级别本身被视为整体默认值。否则，可以使用如下语法来重写某个或某组记录器
 
 ::
 
     <logger>[,<logger>...]=<level>
 
-syntax. Examples of specifications:
+示例如下：
 
 ::
 
     info                                        - Set default to INFO
     warning:msp,gossip=warning:chaincode=info   - Default WARNING; Override for msp, gossip, and chaincode
     chaincode=info:msp,gossip=warning:warning   - Same as above
 
-Logging format
+
+记录格式
 --------------
 
-The logging format of the ``peer`` and ``orderer`` commands is controlled
-via the ``FABRIC_LOGGING_FORMAT`` environment variable. This can be set to
-a format string, such as the default
+ ``peer`` 和 ``orderer`` 命令的日志记录格式是通过 ``FABRIC_LOGGING_FORMAT`` 环境变量控制的。可以将其设置为格式字符串，例如下例以人类可读的默认控制台格式打印日志。也可以将其设置为 ``json`` 以按照 JSON 格式输出日志。
 
 ::
 
    "%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}"
 
-to print the logs in a human-readable console format. It can be also set to
-``json`` to output logs in JSON format.
 
 
-Chaincode
+链码
 ---------
 
-**Chaincode logging is the responsibility of the chaincode developer.**
+**链码记录是链码开发人员的责任。**
 
-As independently executed programs, user-provided chaincodes may technically
-also produce output on stdout/stderr. While naturally useful for “devmode”,
-these channels are normally disabled on a production network to mitigate abuse
-from broken or malicious code. However, it is possible to enable this output
-even for peer-managed containers (e.g. “netmode”) on a per-peer basis
-via the CORE_VM_DOCKER_ATTACHSTDOUT=true configuration option.
+作为独立执行的程序，技术上用户提供的链码也可以在 stdout / stderr 上生成输出。虽然这些通道天然地可以调用 “devmode”，但通常会在生产网络上将其禁用，以减轻破坏性代码或恶意代码的滥用。然而，可以通过配置 CORE_VM_DOCKER_ATTACHSTDOUT = true 选项，在每个 peer 节点管理容器（例如，“ netmode”）上启用此输出。
 
-Once enabled, each chaincode will receive its own logging channel keyed by its
-container-id. Any output written to either stdout or stderr will be integrated
-with the peer’s log on a per-line basis. It is not recommended to enable this
-for production.
+一旦启用，每个链码都将收到由其自身容器ID键入密钥的日志记录通道。写入到 stdout 或 stderr 的任何输出都将逐行集成到 peer 节点的日志中。不建议将其用于生产。
 
-Stdout and stderr not forwarded to the peer container can be viewed from the
-chaincode container using standard commands for your container platform.
+可以使用适用于容器平台的标准命令，从链码容器查看未转发到 peer 容器的 Stdout 和 stderr。
 
 ::