新增具有第三方憑證的組織至網路

本主題包含使用第三方憑證加入組織至 Oracle Blockchain Platform 網路的相關資訊。

將具有第三方憑證的組織加入 Oracle Blockchain Platform 網路的一般工作流程

擁有第三方憑證授權機構 (CA) 所發行憑證的組織可以將 Oracle Blockchain Platform 網路加入為參與者。

僅用戶端組織

這些參與者是僅限用戶端的組織，沒有同儕或訂購者。他們無法建立通道、加入對等或安裝鏈碼。

加入網路之後，這些組織可以使用 SDK 或 Hyperledger Fabric CLI 來：
  • 部署、呼叫及查詢鏈碼 (如果是用戶端組織管理員)。
  • 如果鏈碼是用戶端組織非管理員，則呼叫並查詢。
控制當僅限用戶端組織為網路的一部分時，可以部署和呼叫鏈碼的人員：
  • 將鏈碼安裝到對等體的鏈碼擁有者可以使用 Hyperledger Fabric peer chaincode package -i 建立原則命令來設定鏈碼的建立原則，決定誰可以部署鏈碼。
  • 鏈碼建立器可以使用 Hyperledger Fabric peer chaincode instantiate -P 背書原則命令來設定控制可呼叫鏈碼之人員的背書原則。
  • 通路擁有者可藉由設定通路提案與查詢存取控制清單，來決定誰可以呼叫或查詢鏈碼。請參閱 Hyperledger Fabric 存取控制清單。

Workflow

以下是組織透過第三方憑證和 Oracle Blockchain Platform 創辦人將組織加入 Oracle Blockchain Platform 網路所需的任務。

作業 這是誰？ 描述 其他資訊
取得第三方憑證 第三方憑證 (參與者) 組織 移至協力廠商 CA 伺服器並產生必要的憑證檔案。將匯入網路所需的檔案格式化。 第三方憑證需求
建立要匯入的憑證檔案 第三方憑證 (參與者) 組織 尋找參與者的「管理員」和 CA 憑證資訊，然後使用它來撰寫 JSON 憑證檔案。 建立組織的協力廠商憑證檔案
上傳第三方 (參與者) 組織的憑證檔案 創始人組織 您可以使用主控台來上傳與匯入參與者的憑證檔案，將參與者新增至網路。 匯入憑證以新增組織至網路
從網路創始人匯出訂購服務設定，並將其提供給第三方 (參與者) 組織 創始人組織 將創辦人的訂購服務設定值輸出至 JSON 檔案，並將檔案傳送給參與者。

開啟訂購服務設定值檔案，並尋找訂購服務的地址與連接埠，並將其提供給參與者。舉例而言：

"orderingServiceNodes": [
{
"address": "grpcs://example_address:7777"
...
}]
 將參與者或橫向擴展 OSN 加入創辦人的訂購服務
建立通道 創建者 建立新管道並將參與者新增至該管道。 建立管道
安裝並部署鏈碼 創建者 在創始人的執行個體中，上傳、安裝和部署鏈碼。選擇要安裝鏈碼的網路對等體。 使用快速部署
設定協力廠商 (參與者) 組織的環境 第三方憑證 (參與者) 組織 若要查詢或呼叫鏈碼，參與者必須：
  • 將創始人的訂購服務的地址和港口添加到參與者的環境。
  • 將環境設定為使用 Hyperledger Fabric CLI 或 SDK。
  • 在對等上安裝鏈碼。
 準備使用 Oracle Blockchain Platform Network 的第三方環境

第三方憑證需求

如果要成功加入網路，組織必須產生所需的第三方憑證。這些憑證中的資訊可用來建立組織的憑證檔案，然後匯入創辦人的執行處理中。

組織需要提供哪些憑證？

您必須從 CA 伺服器產生下列憑證：

  • 從屬端公用憑證
  • CA 根憑證

這些憑證有哪些要求？

憑證必須滿足以下需求：

  • 產生私密金鑰時，您必須使用橢圓曲線數位簽章演算法 (ECDSA)。此演算法是 Fabric MSP 金鑰唯一接受的演算法。
  • 「主旨鍵識別碼 (SKI)」為必要項目，您必須在擴充檔案中將它指定為 x509 副檔名。
  • 您必須將 .key 的金鑰檔案轉換為 .pem 格式。
  • 您必須將 .crt 的憑證轉換成 .pem 格式。

建立憑證

下列逐步解說是如何使用 OpenSSL 或 Hyperledger Fabric 加密公用程式來產生憑證的範例。如需所使用指令的詳細資訊，請參閱：

若要使用 OpenSSL 建立憑證，請執行下列動作：

  1. 建立自行簽署的 CA 憑證 / 金鑰：
    openssl ecparam -name prime256v1 -genkey -out ca.key
openssl pkcs8 -topk8 -inform PEM -in ca.key -outform pem -nocrypt -out ca-key.pem
openssl req -new -key ca-key.pem -out ca.csr
openssl x509 -req -days 365 -in ca.csr -signkey ca-key.pem -out ca.crt -extensions x509_ext -extfile opensslca.conf
openssl x509 -in ca.crt -out ca.pem -outform PEM
    我們的範例 opensslca.conf 檔案：
    [ req ]
default_bits        = 2048
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only
 
 
[ subject ]
countryName         = CN
#countryName_default     = US
 
 
stateOrProvinceName     = Beijing
#stateOrProvinceName_default = NY
 
localityName            = Beijing
#localityName_default        = New York
 
organizationName         = thirdpartyca, LLC
#organizationName_default    = Example, LLC
 
# Use a friendly name here because its presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName          = thirdpartyca
#commonName_default      = Example Company
 
emailAddress            = ca@thirdpartyca.com
 
 
 
# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]
 
 
subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer
 
# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints        = CA:TRUE
keyUsage            = Certificate Sign, CRL Sign, digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"
 
# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage  = serverAuth, clientAuth
 
# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]
 
subjectKeyIdentifier        = hash
 
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"
 
# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage  = serverAuth, clientAuth
 
[ alternate_names ]
 
DNS.1       = localhost
DNS.2       = thirdpartyca.com
#DNS.3       = mail.example.com
#DNS.4       = ftp.example.com
 
# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1
  2. 使用以上的 CA 金鑰建立使用者憑證 / 金鑰：
    openssl ecparam -name prime256v1 -genkey -out user.key
openssl pkcs8 -topk8 -inform PEM -in user.key -outform pem -nocrypt -out user-key.pem
openssl req -new -key user-key.pem -out user.csr
openssl x509 -req -days 365 -sha256 -CA ca.pem -CAkey ca-key.pem -CAserial ca.srl -CAcreateserial -in user.csr -out user.crt -extensions x509_ext -extfile openssl.conf
openssl x509 -in user.crt -out user.pem -outform PEM
    我們的範例 openssl.conf 檔案：
    [ req ]
default_bits        = 2048
default_keyfile     = tls-key.pem
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only

# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
# Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName         = CN
#countryName_default     = US

stateOrProvinceName     = Beijing
#stateOrProvinceName_default = NY

localityName            = Beijing
#localityName_default        = New York

organizationName         = thirdpartyca, LLC
#organizationName_default    = Example, LLC

# Use a friendly name here because its presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you 
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName          = admin@thirdpartyca.com
#commonName_default      = Example Company

emailAddress            = admin@thirdpartyca.com
#emailAddress_default        = test@example.com

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]
subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment

subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
#extendedKeyUsage  = Any Extended Key Usage
#extendedKeyUsage = serverAuth, clientAuth


# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ x509_ca_ext ]
subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer


# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints        = CA:TRUE
keyUsage            = Certificate Sign, CRL Sign, digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"


# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
#extendedKeyUsage  = Any Extended Key Usage
extendedKeyUsage = serverAuth, clientAuth


# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]
subjectKeyIdentifier        = hash
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"


# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
#extendedKeyUsage  = Any Extended Key Usage
#extendedKeyUsage = serverAuth, clientAuth

[ alternate_names ]
DNS.1       = localhost
DNS.3       = 127.0.0.1
DNS.4       = 0.0.0.0
# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1
# IPv6 localhost
# DNS.8     = ::1
若要使用 Hyperledger Fabric 加密公用程式建立憑證，請執行下列動作：
  • 下列為用來建立 Hyperledger Fabric 金鑰資料的加密命令：
    cryptogen generate --config=./crypto-config.yaml
    我們的範例 crypto-config.yaml 檔案：
    # Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
  # ---------------------------------------------------------------------------
  # Org1
  # ---------------------------------------------------------------------------
  - Name: Org1
    Domain: org1.example.com
    EnableNodeOUs: true
    # ---------------------------------------------------------------------------
    # "Specs"
    # ---------------------------------------------------------------------------
    # Uncomment this section to enable the explicit definition of hosts in your
    # configuration.  Most users will want to use Template, below
    #
    # Specs is an array of Spec entries.  Each Spec entry consists of two fields:
    #   - Hostname:   (Required) The desired hostname, sans the domain.
    #   - CommonName: (Optional) Specifies the template or explicit override for
    #                 the CN.  By default, this is the template:
    #
    #                              "{{.Hostname}}.{{.Domain}}"
    #
    #                 which obtains its values from the Spec.Hostname and
    #                 Org.Domain, respectively.
    # ---------------------------------------------------------------------------
    # Specs:
    #   - Hostname: foo # implicitly "foo.org1.example.com"
    #     CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above
    #   - Hostname: bar
    #   - Hostname: baz
    # ---------------------------------------------------------------------------
    # "Template"
    # ---------------------------------------------------------------------------
    # Allows for the definition of 1 or more hosts that are created sequentially
    # from a template. By default, this looks like "peer%d" from 0 to Count-1.
    # You may override the number of nodes (Count), the starting index (Start)
    # or the template used to construct the name (Hostname).
    #
    # Note: Template and Specs are not mutually exclusive.  You may define both
    # sections and the aggregate nodes will be created for you.  Take care with
    # name collisions
    # ---------------------------------------------------------------------------
    Template:
      Count: 2
      # Start: 5
      # Hostname: {{.Prefix}}{{.Index}} # default
    # ---------------------------------------------------------------------------
    # "Users"
    # ---------------------------------------------------------------------------
    # Count: The number of user accounts _in addition_ to Admin
    # ---------------------------------------------------------------------------
    Users:
      Count: 1
  # ---------------------------------------------------------------------------
  # Org2: See "Org1" for full specification
  # ---------------------------------------------------------------------------
  - Name: Org2
    Domain: org2.example.com
    EnableNodeOUs: true
    Template:
      Count: 2
    Users:
      Count: 1

後續工作?

確認您已輸出並更新正確檔案之後，就可以建立要匯入 Oracle Blockchain Platform 網路的憑證檔案。請參閱建立組織的協力廠商憑證檔案。

建立組織的協力廠商憑證檔案

若要加入 Oracle Blockchain Platform 網路，組織必須撰寫包含其管理憑證和憑證資訊的憑證檔案。網路管理員匯入此檔案，將組織新增至網路。

移至您從 CA 伺服器產生的憑證檔案，尋找建立憑證檔案所需的資訊。請參閱第三方憑證需求。

憑證檔案必須以 JSON 撰寫，並包含下列欄位：

  • mspid — 指定組織的名稱。
  • type — 指示組織為網路參與者。此值必須是參與者。
  • admincert — 包含組織之「管理」憑證檔案的內容。將憑證資訊複製到 JSON 檔案中時，必須以 \n 取代每一行。
  • cacert — 包含組織 CA 憑證檔案的內容。將憑證資訊複製到 JSON 檔案中時，必須以 \n 取代每一行。
這就是檔案的結構方式： 
{
  "mspID": "examplemspID",
  "type":  "Participant",  
  "certs": { 
   "admincert": "-----BEGIN CERTIFICATE-----\nexample_certificate\nexample_certificate==\n-----END CERTIFICATE-----\n",
   "cacert": "-----BEGIN CERTIFICATE-----\nexample_certificate\nexample_certificate==\n-----END CERTIFICATE-----\n"
 }
}

準備使用 Oracle Blockchain Platform 網路的第三方環境

您必須先設定第三方組織的環境，才能使用 Oracle Blockchain Platform 網路。

確認下列先決條件作業已完成。如需詳細資訊，請參閱將含有第三方憑證的組織加入 Oracle Blockchain Platform Network 的典型工作流程。

  • 第三方組織的憑證檔案已建立並傳送給 Oracle Blockchain Platform 網路創始人。
  • 網路管理員已上傳憑證檔案，將第三方組織新增至網路。
  • 網路創始人匯出訂購者服務的設定，並將服務的地址和連接埠提供給第三方組織，組織會將它們加入環境。
  • 網路創始人建立新的通路，並將第三方組織新增至該通路。
  • 網路創始人安裝並建立鏈碼。

設定組織的環境

在協力廠商組織成功使用 Oracle Blockchain Platform 網路之前，必須先設定環境以使用 Hyperledger Fabric CLI 或 SDK。請參閱 Hyperledger Fabric 文件。

安裝 Chaincode

第三方組織必須在對等上安裝鏈碼。然後，這些對等體必須結合至通道，才能呼叫鏈碼。

部署 Chaincode

如有需要，第三方組織可以在通路上部署鏈碼。舉例而言：

export  CORE_PEER_TLS_ENABLED=true
export  CORE_PEER_TLS_ROOTCERT_FILE=$PWD/tls-ca.pem
export  CORE_PEER_MSPCONFIGPATH=$PWD/crypto-config/peerOrganizations/customerorg1.com/users/Admin@customerorg1.com/msp
export  CORE_PEER_LOCALMSPID="customerorg1" 

### gets channel name from input###
CHANNEL_NAME=$1

echo "######### going to instantiate chaincode on channel ${CHANNEL_NAME} ##########"
CORE_PEER_ADDRESS=${peer_host}:${port} peer chaincode instantiate
-o ${peer_host}:${port}  --tls $CORE_PEER_TLS_ENABLED --cafile 
./tls-ca.pem -C ${CHANNEL_NAME}  -n obcs-example02 -v v0 -c '{"Args":["init","a","100","b","200"]}'

呼叫鏈碼

第三方組織使用 Hyperledger Fabric CLI 或 SDK 來呼叫鏈碼。舉例而言：

export CORE_PEER_TLS_ENABLED=true
export CORE_PEER_TLS_ROOTCERT_FILE=$PWD/tls-ca.pem
export CORE_PEER_MSPCONFIGPATH=$PWD/crypto-config/peerOrganizations/customerorg1.com/users/User1@customerorg1.com/msp
export CORE_PEER_LOCALMSPID="customerorg1"

### gets channel name from input ###
CHANNEL_NAME=$1

#### do query or invoke on chaincode ####

CORE_PEER_ADDRESS=${peer_host}:${port} peer chaincode query -C
${CHANNEL_NAME} -n $2 -c '{"Args":["query","a"]}'

CORE_PEER_ADDRESS=${peer_host}:${port} peer chaincode invoke -o
${peer_host}:${port} --tls $CORE_PEER_TLS_ENABLED --cafile ./tls-
ca.pem -C ${CHANNEL_NAME} -n $2 -c '{"Args":["invoke","a","b","10"]}'