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

本主題包含將使用第三方憑證的組織加入 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 網路。請參閱 Create an Organization's Third-Party Certificates File

建立組織的第三方憑證檔案

若要加入 Oracle Blockchain Platform 網路,組織必須撰寫包含其 admincert 和 cacert 資訊的憑證檔案。網路創始人匯入此檔案以新增組織至網路。

移至您從 CA 伺服器產生的憑證檔案,尋找建立憑證檔案所需的資訊。請參閱 Third-Party Certificate Requirements

憑證檔案必須以 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 文件

安裝鏈碼

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

部署鏈碼

如有需要,第三方組織可以在通道上部署鏈碼。舉例而言:

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"]}'