Ajout d'organisations avec des certificats tiers au réseau
Cette rubrique contient des informations sur l'adhésion d'organisations utilisant des certificats tiers à un réseau Oracle Blockchain Platform.
Workflow standard pour rejoindre une organisation disposant de certificats tiers sur un réseau Oracle Blockchain Platform
Les organisations disposant de certificats émis par une autorité de certification tierce peuvent rejoindre le réseau Oracle Blockchain Platform en tant que participants.
Organisations client uniquement
Ces participants sont des organisations client uniquement et n'ont ni homologues ni donneurs d'ordre. Ils ne peuvent pas créer de canaux, joindre d'homologues ni installer de code chaîne.
- Déployer, appeler et interroger le code chaîne s'il s'agit d'un administrateur d'organisation client.
- Appeler et interroger le code chaîne s'il s'agit d'un non-administrateur d'une organisation client.
- Le propriétaire du code chaîne qui installe le code chaîne sur ses pairs peut décider qui peut déployer le code chaîne à l'aide de la commande de stratégie d'instanciation
peer chaincode package -i
d'Hyperledger Fabric afin de définir la stratégie d'instanciation du code chaîne. - L'instanciateur de code chaîne peut utiliser la commande de stratégie d'approbation Hyperledger Fabric
peer chaincode instantiate -P
pour définir la stratégie d'approbation contrôlant qui peut appeler le code chaîne. - Le propriétaire du canal peut décider qui peut appeler ou interroger un code chaîne en définissant la proposition de canal et la liste de contrôle d'accès des requêtes. Reportez-vous à Listes de contrôle d'accès Hyperledger Fabric.
Workflow
Voici les tâches qu'une entreprise disposant de certificats tiers et le fondateur d'Oracle Blockchain Platform doivent effectuer pour rejoindre l'entreprise sur un réseau Oracle Blockchain Platform.
Tâche | Qui fait ça ? | Description | En savoir plus |
---|---|---|---|
Obtenir les certificats tiers | Organisation de certificats tiers (participant) | Accédez au serveur CA tiers et générez les fichiers de certificats requis. Formatez les fichiers selon vos besoins pour les importer dans le réseau. | Exigences relatives aux certificats tiers |
Créer le fichier de certificats à importer | Organisation de certificats tiers (participant) | Recherchez les informations de certificat d'autorité de certification et d'administration du participant et utilisez-les pour créer un fichier de certificats JSON. | Création du fichier de certificats tiers d'une organisation |
Charger un fichier de certificat pour l'organisation tierce (participant) | Organisation fondatrice | Utilisez la console pour charger et importer le fichier de certificat du participant afin d'ajouter le participant au réseau. | Importation de certificats pour ajouter des organisations au réseau |
Exportez les paramètres du service de commande à partir du fondateur du réseau et fournissez-les à l'organisation tierce (participante). | Organisation fondatrice | Envoyez les paramètres de services de commande du fondateur dans un fichier JSON et envoyez le fichier au participant.
Ouvrez le fichier de paramètres du service de commande et recherchez l'adresse et le port du service de commande et donnez-les au participant. Exemple :
|
Rejoindre le participant ou les OSN mis à l'échelle au service de commande du fondateur |
Créer le canal | Fondateur | Créez un canal et ajoutez-y le participant. | Création d'un canal |
Installer et déployer le code de chaîne | Fondateur | Dans l'instance du fondateur, télécharger, installer et déployer le code chaîne. Choisissez les homologues du réseau sur lesquels installer le code chaîne. | Utiliser le déploiement rapide |
Paramétrer l'environnement de l'organisation tierce (participante) | Organisation de certificats tiers (participant) | Pour interroger ou appeler des codes chaîne, le participant doit :
|
Préparation de l'environnement tiers pour l'utilisation du réseau Oracle Blockchain Platform |
Exigences relatives aux certificats tiers
Pour rejoindre le réseau, une organisation doit générer les certificats tiers requis. Les informations contenues dans ces certificats sont utilisées pour créer le fichier de certificats de l'organisation, qui est ensuite importé dans l'instance du fondateur.
Quels certificats les organisations doivent-elles fournir ?
Vous devez générer les certificats suivants à partir de votre serveur CA :
- Certificat public du client
- Certificat racine CA
Quelles sont les conditions requises pour ces certificats ?
Les certificats doivent répondre aux exigences suivantes :
- Lors de la génération de la clé privée, vous devez utiliser l'algorithme de signature numérique de courbe elliptique (ECDSA). Cet algorithme est le seul algorithme accepté pour les clés MSP Fabric.
- L'identifiant de clé de sujet (SKI) est obligatoire et vous devez l'indiquer en tant qu'extensions x509 dans le fichier d'extension.
- Vous devez convertir les fichiers de clés du format .key au format .pem.
- Vous devez convertir les certificats du format .crt au format .pem.
Création des certificats
Pour créer vos certificats à l'aide de OpenSSL, procédez comme suit :
- Créez une clé/un certificat d'autorité de certification signé par vous-même :
Notre exemple de fichieropenssl 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
- Créez un certificat/une clé utilisateur à l'aide de la clé CA ci-dessus :
Notre exemple de fichieropenssl 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
- Les commandes cryptogénétiques suivantes sont utilisées pour créer le matériel de clé Hyperledger Fabric :
Notre exemple de fichiercryptogen 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
Etapes suivantes
Après avoir confirmé que vous avez sorti et mis à jour les fichiers appropriés, vous pouvez créer le fichier de certificats à importer dans le réseau Oracle Blockchain Platform. Reportez-vous à Création d'un fichier de certificats tiers d'une organisation.
Création du fichier de certificats tiers d'une organisation
Pour rejoindre un réseau Oracle Blockchain Platform, l'organisation doit écrire un fichier de certificats contenant ses informations d'administrateur et de certificat. Le fondateur du réseau importe ce fichier pour ajouter l'organisation au réseau.
Accédez aux fichiers de certificats générés à partir du serveur CA pour trouver les informations dont vous avez besoin pour créer le fichier de certificats. Reportez-vous à la section Exigences relatives aux certificats tiers.
Le fichier de certificats doit être écrit au format JSON et contenir les champs suivants :
- mspid — Spécifie le nom de l'organisation.
- type — Indique que l'organisation est un participant du réseau. Cette valeur doit être Participant.
- admincert — Contient le contenu du fichier de certificats Admin de l'organisation. Lorsque vous copiez les informations de certificat dans le fichier JSON, vous devez remplacer chaque nouvelle ligne par \n.
- cacert — Contient le contenu du fichier de certificats CA de l'organisation. Lorsque vous copiez les informations de certificat dans le fichier JSON, vous devez remplacer chaque nouvelle ligne par \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"
}
}
Préparation de l'environnement tiers pour l'utilisation du réseau Oracle Blockchain Platform
Vous devez configurer l'environnement de l'organisation tierce pour pouvoir utiliser le réseau Oracle Blockchain Platform.
Vérifiez que les tâches prérequises suivantes ont été effectuées. Pour plus d'informations, reportez-vous à Workflow standard de jointure d'une organisation avec des certificats tiers à un réseau Oracle Blockchain Platform.
- Le fichier de certificat de l'organisation tierce a été créé et envoyé au fondateur de réseau Oracle Blockchain Platform.
- Le fondateur du réseau a chargé le fichier de certificats pour ajouter l'organisation tierce au réseau.
- Le fondateur du réseau a exporté les paramètres du service donneur d'ordre et a donné l'adresse et le port du service à l'organisation tierce et l'organisation les a ajoutés à l'environnement.
- Le fondateur du réseau a créé un nouveau canal et y a ajouté l'organisation tierce.
- Le fondateur du réseau a installé et instancié le code chaîne.
Configurer l'environnement de l'organisation
Pour que l'organisation tierce puisse utiliser avec succès le réseau Oracle Blockchain Platform, elle doit configurer son environnement pour utiliser la CLI ou les SDK Hyperledger Fabric. Reportez-vous à la documentation Hyperledger Fabric.
Installer le code de chaîne
L'organisation tierce doit installer le code chaîne sur les pairs. Ces homologues doivent ensuite être joints au canal pour que le code chaîne puisse être appelé.
Déployer le code chaîne
Si nécessaire, les organisations tierces peuvent déployer le code chaîne sur le canal. Exemple :
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"]}'
Appeler le code de chaîne
Les organisations tierces utilisent la CLI ou les SDK Hyperledger Fabric pour appeler le code chaîne. Exemple :
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"]}'