1. Oracle Blockchain Platform verwenden
  2. Netzwerk erweitern
  3. Organisationen mit Drittanbieterzertifikaten zum Netzwerk hinzufügen

Organisationen mit Drittanbieterzertifikaten zum Netzwerk hinzufügen

Dieses Thema enthält Informationen zum Verbinden von Organisationen, die Zertifikate von Drittanbietern mit einem Oracle Blockchain Platform-Netzwerk verwenden.

Typischer Workflow zum Beitritt zu einer Organisation mit Drittanbieterzertifikaten zu einem Oracle Blockchain Platform-Netzwerk

Organisationen mit Zertifikaten, die von einer externen Certificate Authority (CA) ausgestellt wurden, können als Teilnehmer dem Oracle Blockchain Platform-Netzwerk beitreten.

Nur-Kunden-Organisationen

Diese Teilnehmer sind reine Kundenorganisationen und haben keine Kollegen oder Auftragnehmer. Sie können keine Kanäle erstellen, Peers beitreten oder Chaincode installieren.

Nach dem Beitritt zum Netzwerk können diese Organisationen ein SDK oder eine Hyperledger Fabric-CLI verwenden, um:
  • Als Clientorganisationsadministrator können Sie Chaincode bereitstellen, aufrufen und abfragen.
  • Rufen Sie Chaincode auf, und fragen Sie ihn ab, wenn er kein Administrator der Clientorganisation ist.
So steuern Sie, wer Chaincode bereitstellen und aufrufen kann, wenn nur Clientorganisationen Teil des Netzwerks sind:
  • Der Chaincode-Eigentümer, der den Chaincode auf Peers installiert, kann entscheiden, wer den Chaincode bereitstellen kann, indem er den Instanziierungs-Policy-Befehl Hyperledger Fabric peer chaincode package -i verwendet, um die Instanziierungs-Policy für den Chaincode festzulegen.
  • Der Chaincode-Instantiator kann den Hyperledger Fabric peer chaincode instantiate -P-Befehl der Bestätigungs-Policy verwenden, um die Bestätigungs-Policy festzulegen, die kontrolliert, wer den Chaincode aufrufen kann.
  • Der Kanaleigentümer kann entscheiden, wer einen Chaincode aufrufen oder abfragen kann, indem er den Channelvorschlag und die Access Control-Liste abfragt. Siehe Hyperledger Fabric Access Control Lists.

Workflow

Im Folgenden werden die Aufgaben aufgeführt, die eine Organisation mit Zertifikaten von Drittanbietern und der Oracle Blockchain Platform-Gründer ausführen müssen, um der Organisation einem Oracle Blockchain Platform-Netzwerk beizutreten.

Aufgabe Wer macht das? Beschreibung Weitere Informationen
Erhalten Sie die Zertifikate von Drittanbietern Drittzahlungsempfänger (Teilnehmer) Rufen Sie den CA-Server eines Drittanbieters auf, und generieren Sie die erforderlichen Zertifikatsdateien. Formatieren Sie die Dateien nach Bedarf für den Import in das Netzwerk. Drittanbieter-Zertifikatsanforderungen
Zertifikatsdatei für Import erstellen Drittzahlungsempfänger (Teilnehmer) Suchen Sie die Admin- und CA-Zertifikatsinformationen des Teilnehmers, und erstellen Sie damit eine JSON-Zertifikatsdatei. Datei für Drittanbieterzertifikate einer Organisation erstellen
Zertifikatsdatei für die Fremdorganisation (Teilnehmer) hochladen Gründerorganisation Über die Konsole können Sie die Zertifikatsdatei des Teilnehmers hochladen und importieren, um den Teilnehmer dem Netzwerk hinzuzufügen. Zertifikate importieren, um Organisationen zum Netzwerk hinzuzufügen
Exportieren Sie die Einstellungen für den Bestellservice vom Netzwerkgründer, und stellen Sie sie der Drittanbieterorganisation (Teilnehmerorganisation) zur Verfügung Gründerorganisation Geben Sie die Einstellungen für den Bestellservice des Gründers in eine JSON-Datei aus, und senden Sie die Datei an den Teilnehmer.

Öffnen Sie die Einstellungsdatei für den Bestellservice, suchen Sie die Adresse und den Port des Bestellservice, und geben Sie sie dem Teilnehmer. Beispiel:

"orderingServiceNodes": [
{
"address": "grpcs://example_address:7777"
...
}]
 Nehmen Sie an den teilnehmenden oder skalierten OSNs am Bestellservice des Gründers teil
Kanal erstellen Gründer Erstellen Sie einen neuen Kanal, und fügen Sie den Teilnehmer hinzu. Kanal erstellen
Installieren und Bereitstellen des Chaincodes Gründer Laden Sie den Chaincode in der Instanz des Gründers hoch, installieren und stellen Sie ihn bereit. Wählen Sie die Netzwerk-Peers, auf denen der Chaincode installiert werden soll.
Umgebung der Fremdorganisation (Teilnehmer) einrichten Drittzahlungsempfänger (Teilnehmer) Um Chaincodes abzufragen oder aufzurufen, muss der Teilnehmer:
  • Fügen Sie die Adresse und den Port des Bestellservice des Gründers zur Umgebung des Teilnehmers hinzu.
  • Konfigurieren Sie die Umgebung für die Verwendung der Hyperledger Fabric-CLI oder -SDKs.
  • Installieren Sie den Chaincode auf Peers.
 Drittanbieterumgebung für die Verwendung des Oracle Blockchain Platform-Netzwerks vorbereiten

Drittanbieter-Zertifikatsanforderungen

Um dem Netzwerk erfolgreich beizutreten, muss eine Organisation die erforderlichen Zertifikate von Drittanbietern generieren. Anhand der Informationen in diesen Zertifikaten wird die Zertifikatsdatei der Organisation erstellt, die dann in die Instanz des Gründers importiert wird.

Welche Zertifikate müssen Organisationen bereitstellen?

Sie müssen die folgenden Zertifikate von Ihrem CA-Server generieren:

  • Öffentliches Clientzertifikat
  • CA-Root-Zertifikat

Was sind die Anforderungen für diese Zertifikate?

Die Zertifikate müssen die folgenden Voraussetzungen erfüllen:

  • Wenn Sie den Private Key generieren, müssen Sie den Elliptic Curve Digital Signature Algorithm (ECDSA) verwenden. Dieser Algorithmus ist der einzige akzeptierte Algorithmus für Fabric MSP-Schlüssel.
  • Die Subjektschlüssel-ID (SKI) ist erforderlich, und Sie müssen sie in der Erweiterungsdatei als x509-Erweiterungen angeben.
  • Sie müssen die Schlüsseldateien vom .key-Format in das .pem-Format konvertieren.
  • Sie müssen die Zertifikate vom .crt-Format in das .pem-Format konvertieren.

Zertifikate erstellen

Die folgende Schritt-für-Schritt-Anleitung zeigt, wie Sie Ihre Zertifikate mit OpenSSL oder dem Hyperledger Fabric-Kryptogenutility generieren. Ausführliche Informationen zu den verwendeten Befehlen finden Sie unter:

So erstellen Sie Ihre Zertifikate mit OpenSSL:

  1. Erstellen Sie ein selbstsigniertes CA-Zertifikat/-Schlüssel:
    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
    Unsere Beispieldatei 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. Erstellen Sie ein Benutzerzertifikat/-schlüssel mit dem obigen CA-Schlüssel:
    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
    Unsere Beispieldatei 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
So erstellen Sie Ihre Zertifikate mit dem kryptogenen Dienstprogramm Hyperledger Fabric:
  • Die folgenden Kryptogenbefehle werden zum Erstellen von Hyperledger Fabric-Schlüsselmaterial verwendet:
    cryptogen generate --config=./crypto-config.yaml
    Unsere Beispieldatei 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

Weitere Schritte

Nachdem Sie bestätigt haben, dass Sie die richtigen Dateien ausgegeben und aktualisiert haben, können Sie die Zertifikatsdatei für den Import in das Oracle Blockchain Platform-Netzwerk erstellen. Siehe Zertifikatsdatei für Drittparteien einer Organisation erstellen.

Datei für Drittanbieterzertifikate einer Organisation erstellen

Um einem Oracle Blockchain Platform-Netzwerk beizutreten, muss die Organisation eine Zertifikatsdatei mit den Admincert- und Cacert-Informationen schreiben. Der Netzwerkgründer importiert diese Datei, um die Organisation zum Netzwerk hinzuzufügen.

Gehen Sie zu den Zertifikatsdateien, die Sie vom CA-Server generiert haben, um die Informationen zu finden, die Sie zum Erstellen der Zertifikatsdatei benötigen. Siehe Voraussetzungen für Drittanbieterzertifikate.

Die Zertifikatsdatei muss in JSON geschrieben sein und die folgenden Felder enthalten:

  • mspid - Gibt den Namen der Organisation an.
  • Typ - Gibt an, dass die Organisation ein Netzwerkteilnehmer ist. Dieser Wert muss Teilnehmer sein.
  • admincert - Enthält den Inhalt der Admin-Zertifikatsdatei des Unternehmens. Wenn Sie die Zertifikatsinformationen in die JSON-Datei kopieren, müssen Sie jede neue Zeile durch \n ersetzen.
  • cacert - Enthält den Inhalt der CA-Zertifikatsdatei des Unternehmens. Wenn Sie die Zertifikatsinformationen in die JSON-Datei kopieren, müssen Sie jede neue Zeile durch \n ersetzen.
So muss die Datei strukturiert werden: 
{
  "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"
 }
}

Drittanbieterumgebung für die Verwendung des Oracle Blockchain Platform-Netzwerks vorbereiten

Sie müssen die Umgebung der Drittanbieterorganisation einrichten, bevor sie das Netzwerk Oracle Blockchain Platform verwenden kann.

Bestätigen Sie, dass die folgenden Voraussetzungsaufgaben abgeschlossen wurden. Weitere Informationen finden Sie unter Typischer Workflow zum Beitritt einer Organisation mit Drittanbieterzertifikaten zu einem Oracle Blockchain Platform-Netzwerk.

  • Die Zertifikatsdatei der Drittanbieterorganisation wurde erstellt und an den Oracle Blockchain Platform-Netzwerkgründer gesendet.
  • Der Netzwerkgründer hat die Zertifikatsdatei hochgeladen, um die Drittanbieterorganisation zum Netzwerk hinzuzufügen.
  • Der Netzwerkgründer exportierte die Einstellungen des Orderer-Service und gab die Adresse und den Port des Service an die Drittanbieterorganisation weiter. Die Organisation fügte sie der Umgebung hinzu.
  • Der Netzwerkgründer hat einen neuen Kanal erstellt und die Drittanbieterorganisation hinzugefügt.
  • Der Netzwerk-Gründer installierte und instanziierte den Chaincode.

Organisationsumgebung einrichten

Bevor die Drittorganisation das Oracle Blockchain Platform-Netzwerk erfolgreich verwenden kann, muss sie ihre Umgebung für die Verwendung der Hyperledger Fabric-CLI oder -SDKs einrichten. Weitere Informationen finden Sie in der Dokumentation zu Hyperledger Fabric.

Kettencode installieren

Die Drittorganisation muss den Chaincode auf den Peers installieren. Diese Peers müssen dann mit dem Channel verknüpft werden, damit der Chaincode aufgerufen werden kann.

Chaincode bereitstellen

Bei Bedarf können Drittanbieter den Chaincode auf dem Kanal bereitstellen. Beispiel:

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

Chaincode aufrufen

Drittanbieterunternehmen verwenden die Hyperledger Fabric-CLI oder SDKs, um den Chaincode aufzurufen. Beispiel:

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