Organisationen mit Drittanbieterzertifikaten zum Netzwerk hinzufügen
Dieses Thema enthält Informationen zum Verbinden von Organisationen, die Zertifikate von Drittanbietern verwenden, mit einem Oracle Blockchain Platform-Netzwerk.
Typischer Workflow zum Beitritt zu einer Organisation mit Zertifikaten von Drittanbietern 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.
Kundenorganisationen
Diese Teilnehmer sind reine Kundenorganisationen und haben keine Kollegen oder Auftragnehmer. Sie können keine Kanäle erstellen, Peers beitreten oder Chaincode installieren.
- Chaincode bereitstellen, aufrufen und abfragen, wenn es sich um einen Administrator der Clientorganisation handelt
- Rufen Sie Chaincode auf, und fragen Sie ihn ab, wenn es sich um eine Kundenorganisation ohne Administrator handelt.
- Der Chaincode-Eigentümer, der den Chaincode auf Peers installiert, kann mithilfe des Instanziierungs-Policy-Befehls Hyperledger Fabric
peer chaincode package -i
entscheiden, wer den Chaincode bereitstellen kann, um die Instanziierungs-Policy für den Chaincode festzulegen. - Die Chaincode-Instanziator-Komponente kann den Hyperledger Fabric
peer chaincode instantiate -P
-Befehl für die Bestätigungsrichtlinie verwenden, um die Bestätigungsrichtlinie festzulegen, die kontrolliert, wer den Chaincode aufrufen kann. - Der Kanaleigentümer kann entscheiden, wer einen Chaincode aufrufen oder abfragen kann, indem er den Kanalvorschlag und die Access Control-Liste abfragt. Siehe Hyperledger Fabric Access Control-Listen.
Workflow
Im Folgenden werden die Aufgaben aufgeführt, die eine Organisation mit Zertifikaten von Drittanbietern und dem Oracle Blockchain Platform-Gründer ausführen muss, um der Organisation mit einem Oracle Blockchain Platform-Netzwerk beizutreten.
Aufgabe | Wer macht das? | Beschreibung | Weitere Informationen |
---|---|---|---|
Erhalten Sie die Zertifikate von Drittanbietern | Drittanbieterzertifikate (Teilnehmer) - Organisation | Wechseln Sie zum CA-Server eines Drittanbieters, und generieren Sie die erforderlichen Zertifikatsdateien. Formatieren Sie die Dateien nach Bedarf für den Import in das Netzwerk. | Anforderungen für Drittanbieterzertifikate |
Erstellen Sie die Zertifikatsdatei für den Import | Drittanbieterzertifikate (Teilnehmer) - Organisation | Suchen Sie die Admin- und CA-Zertifikatsinformationen des Teilnehmers, und erstellen Sie damit eine JSON-Zertifikatsdatei. | Drittanbieterzertifikatsdatei einer Organisation erstellen |
Laden Sie eine Zertifikatsdatei für die Drittanbieterorganisation (Teilnehmer) hoch | Gründerorganisation | Verwenden Sie die Konsole, um die Zertifikatsdatei des Teilnehmers hochzuladen und zu importieren, um den Teilnehmer zum Netzwerk hinzuzufügen. | Zertifikate importieren, um Organisationen zum Netzwerk hinzuzufügen |
Exportieren Sie die Ordering Service-Einstellungen vom Netzwerkgründer, und stellen Sie sie der Drittanbieterorganisation (Teilnehmer) zur Verfügung | Gründerorganisation | Ausgabe der Ordering Services-Einstellungen des Gründers in eine JSON-Datei und Senden der 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:
|
Nehmen Sie an den teilnehmenden oder skalierten OSNs beim Ordering Service des Gründers teil |
Kanal erstellen | Gründer | Erstellen Sie einen neuen Kanal, und fügen Sie den Teilnehmer hinzu. | Kanal erstellen |
Chaincode installieren und bereitstellen | Gründer | Laden Sie in der Instanz des Gründers den Chaincode hoch, installieren und bereitstellen Sie ihn. Wählen Sie die Netzwerkpeers aus, auf denen der Chaincode installiert werden soll. | Schnell-Deployment verwenden |
Umgebung der Fremdfirma (Teilnehmer) einrichten | Drittanbieterzertifikate (Teilnehmer) - Organisation | Um Chaincodes abzufragen oder aufzurufen, muss der Teilnehmer:
|
Umgebung von Drittanbietern für die Verwendung des Oracle Blockchain Platform-Netzwerks vorbereiten |
Anforderungen für Drittanbieterzertifikate
Um dem Netzwerk erfolgreich beizutreten, muss eine Organisation die erforderlichen Drittanbieterzertifikate generieren. Die Informationen in diesen Zertifikaten werden verwendet, um die Zertifikatsdatei der Organisation zu erstellen, die dann in die Instanz des Gründers importiert wird.
Welche Zertifikate müssen Unternehmen bereitstellen?
Sie müssen die folgenden Zertifikate vom CA-Server generieren:
- Öffentliches Clientzertifikat
- CA-Root-Zertifikat
Was sind die Voraussetzungen für diese Zertifikate?
Die Zertifikate müssen die folgenden Voraussetzungen erfüllen:
- Bei der Generierung des Private Keys 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 Subject Key Identifier (SKI) ist erforderlich, und Sie müssen sie als x509-Erweiterungen in der Erweiterungsdatei angeben.
- Sie müssen die Schlüsseldateien vom Schlüssel in das .pem-Format konvertieren.
- Sie müssen die Zertifikate vom .crt-Format in das .pem-Format konvertieren.
Zertifikate erstellen
So erstellen Sie Zertifikate mit OpenSSL:
- Erstellen Sie ein selbstsigniertes CA-Zertifikat/-Schlüssel:
Unsere Beispieldateiopenssl 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
- Erstellen Sie ein Benutzerzertifikat/einen Benutzerschlüssel mit dem obigen CA-Schlüssel:
Unsere Beispieldateiopenssl 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
- Die folgenden kryptogenen Befehle werden verwendet, um Hyperledger Fabric-Schlüsselmaterial zu erstellen:
Unsere Beispieldateicryptogen 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
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 Drittzertifikatsdatei einer Organisation erstellen.
Drittanbieterzertifikatsdatei einer Organisation erstellen
Um einem Oracle Blockchain Platform-Netzwerk beizutreten, muss die Organisation eine Zertifikatsdatei schreiben, die ihre Admincert- und Cacert-Informationen enthält. Der Netzwerkgründer importiert diese Datei, um die Organisation zum Netzwerk hinzuzufügen.
Rufen Sie die Zertifikatsdateien auf, die Sie vom CA-Server generiert haben, um nach den Informationen zu suchen, 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.
- type - Gibt an, dass die Organisation ein Netzwerkteilnehmer ist. Dieser Wert muss Teilnehmer sein.
- admincert — Enthält den Inhalt der Admin-Zertifikatsdatei der Organisation. 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 der Organisation. Wenn Sie die Zertifikatsinformationen in die JSON-Datei kopieren, müssen Sie jede neue Zeile durch \n ersetzen.
{
"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"
}
}
Umgebung von Drittanbietern für die Verwendung des Oracle Blockchain Platform-Netzwerks vorbereiten
Sie müssen die Umgebung der Drittanbieterorganisation einrichten, bevor sie das Oracle Blockchain Platform-Netzwerk verwenden kann.
Bestätigen Sie, dass die folgenden Voraussetzungsaufgaben abgeschlossen wurden. Weitere Informationen finden Sie unter Typischer Workflow zum Verbinden einer Organisation mit Drittanbieterzertifikaten mit einem Oracle Blockchain Platform-Netzwerk.
- Die Zertifikatsdatei der Drittanbieterorganisation wurde erstellt und an den Netzwerkgründer von Oracle Blockchain Platform 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, und 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 hat den Chaincode installiert und instanziiert.
Organisationsumgebung einrichten
Bevor die Drittanbieterorganisation 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 Hyperledger Fabric-Dokumentation.
Chaincode installieren
Die Drittorganisation muss den Chaincode auf den Peers installieren. Diese Peers müssen dann mit dem Kanal verbunden 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
Drittanbieter 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"]}'