1. Utilisation d'Oracle Blockchain Platform
  2. Étendre le réseau
  3. Ajouter des organisations avec des certificats de tierce partie au réseau

Ajouter des organisations avec des certificats de tierce partie au réseau

Cette rubrique contient des informations sur l'adhésion d'organisations utilisant des certificats de tierce partie à un réseau Oracle Blockchain Platform.

Flux de travail type pour joindre une organisation avec des certificats de tierce partie à un réseau Oracle Blockchain Platform

L'organisation avec des certificats émis par une autorité de certification de tierce partie peut se joindre au réseau Oracle Blockchain Platform en tant que participants.

Organisations réservées aux clients

Ces participants sont des organisations réservées aux clients et n'ont pas de pairs ou de commandants. Ils ne peuvent pas créer de canaux, joindre des pairs ni installer du code de chaîne.

Après avoir rejoint le réseau, ces organisations peuvent utiliser une trousse SDK ou une interface de ligne de commande Hyperledger Fabric pour :
  • Déployer, appeler et interroger le code de chaîne s'il s'agit d'un administrateur de l'organisation client.
  • Appeler et interroger le code de chaîne s'il s'agit d'une organisation client non administrateur.
Pour contrôler qui peut déployer et appeler le code de chaîne lorsque des organisations côté client font partie du réseau :
  • Le responsable du code de chaîne qui installe le code de chaîne sur ses pairs peut décider qui peut déployer le code de chaîne à l'aide de la commande de politique d'instanciation Hyperledger Fabric peer chaincode package -i pour définir la politique d'instanciation du code de chaîne.
  • L'instanciateur de code de chaîne peut utiliser la commande de politique d'endossement Hyperledger Fabric peer chaincode instantiate -P pour définir la politique d'endossement qui contrôle qui peut appeler le code de chaîne.
  • Le responsable du canal peut décider qui peut appeler ou interroger un code de chaîne en définissant la proposition de canal et la liste de contrôle d'accès pour l'interrogation. Voir Listes de contrôle d'accès Hyperledger Fabric.

Flux de travail

Voici les tâches qu'une organisation avec des certificats de tierce partie et le fondateur d'Oracle Blockchain Platform doivent effectuer pour joindre l'organisation à un réseau Oracle Blockchain Platform.

Tâche Qui fait ça? Description Informations supplémentaires
Obtenir les certificats de tierce partie Organisation de certificats tiers (participant) Accédez au serveur AC tiers et générez les fichiers de certificats requis. Formatez les fichiers au besoin pour les importer dans le réseau. Exigences relatives aux certificats de tierce partie
Créer le fichier de certificats à importer Organisation de certificats tiers (participant) Recherchez les informations sur l'administrateur et le certificat de l'autorité de certification du participant et utilisez-les pour composer un fichier de certificats JSON. Créer le fichier de certificats de tierce partie 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. Importer des certificats pour ajouter des organisations au réseau
Exporter les paramètres du service de commande du fondateur du réseau et les fournir à l'organisation tierce (participante) Organisation fondatrice Sortir les paramètres des services de commande du fondateur dans un fichier JSON et envoyer le fichier au participant.

Ouvrez le fichier des paramètres du service de commande et recherchez l'adresse et le port du service de commande et donnez-les au participant. Par exemple :

"orderingServiceNodes": [
{
"address": "grpcs://example_address:7777"
...
}]
 Rejoignez le participant ou les OSN évolués au service de commande du fondateur
Créer le canal Fondateur Créez un nouveau canal et ajoutez-y le participant. Créer un canal
Installer et déployer le code de chaîne Fondateur Dans l'instance du fondateur, chargez, installez et déployez le code de chaîne. Sélectionner les pairs du réseau sur lesquels installer le code de chaîne.
Configurer l'environnement de l'organisation tierce (participant) Organisation de certificats tiers (participant) Pour interroger ou appeler des codes de chaîne, le participant doit :
  • Ajoutez l'adresse et le port du service de commande du fondateur à l'environnement du participant.
  • Configurez l'environnement pour utiliser l'interface de ligne de commande ou les trousses SDK Hyperledger Fabric.
  • Installer le code de chaîne sur des pairs.
 Préparer l'environnement de tierce partie pour utiliser le réseau Oracle Blockchain Platform

Exigences relatives aux certificats de tierce partie

Pour se joindre au réseau, une organisation doit générer les certificats de tierce partie 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 d'autorité de certification :

  • Certificat public du client
  • Certificat racine de l'autorité de certification

Quelles sont les exigences pour ces certificats?

Les certificats doivent satisfaire aux exigences suivantes :

  • Lors de la génération de la clé privée, vous devez utiliser l'algorithme de signature numérique à courbe elliptique (ECDSA). Cet algorithme est le seul algorithme accepté pour les clés MSP Fabric.
  • L'identificateur de clé de sujet (SKI) est obligatoire et vous devez l'indiquer comme extension x509 dans le fichier d'extension.
  • Vous devez convertir les fichiers de clé du .key au format .pem.
  • Vous devez convertir les certificats du format .crt au format .pem.

Création des certificats

La procédure pas à pas suivante illustre l'utilisation de OpenSSL ou de l'utilitaire cryptogen Hyperledger Fabric pour générer vos certificats. Pour plus d'informations sur les commandes utilisées, reportez-vous à :

Pour créer vos certificats à l'aide de OpenSSL :

  1. Créez un certificat ou une clé d'autorité de certification auto-signé :
    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
    Notre exemple de fichier 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. Créez un certificat ou une clé d'utilisateur à l'aide de la clé de l'autorité de certification ci-dessus :
    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
    Notre exemple de fichier 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
Pour créer vos certificats à l'aide de l'utilitaire cryptogen Hyperledger Fabric :
  • Les commandes cryptogéniques suivantes sont utilisées pour créer le matériel de clé Hyperledger Fabric :
    cryptogen generate --config=./crypto-config.yaml
    Notre exemple de fichier 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

Étape suivante

Après avoir confirmé que vous avez sorti et mis à jour les fichiers appropriés, vous pouvez ensuite créer le fichier de certificats à importer dans le réseau Oracle Blockchain Platform. Voir Créer le fichier de certificats de tierce partie d'une organisation.

Créer le fichier de certificats de tierce partie d'une organisation

Pour se joindre à un réseau Oracle Blockchain Platform, l'organisation doit écrire un fichier de certificats contenant ses informations d'administration et de certificat. Le fondateur du réseau importe ce fichier pour ajouter l'organisation au réseau.

Accédez aux fichiers de certificats que vous avez générés à partir du serveur d'autorité de certification pour trouver les informations dont vous avez besoin pour créer le fichier de certificats. Voir Exigences relatives aux certificats de tierce partie.

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 au réseau. Cette valeur doit être Participant.
  • admincert - Contient le contenu du fichier de certificats d'administration de l'organisation. Lorsque vous copiez les informations sur les certificats dans le fichier JSON, vous devez remplacer chaque nouvelle ligne par \n.
  • cacert - Contient le contenu du fichier de certificats AC de l'organisation. Lorsque vous copiez les informations sur les certificats dans le fichier JSON, vous devez remplacer chaque nouvelle ligne par \n.
Voici comment le fichier doit être structuré : 
{
  "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éparez l'environnement de tierce partie à utiliser le 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éalables suivantes sont terminées. Pour plus d'informations, voir Flux de travail type pour joindre une organisation avec des certificats de tierce partie à un réseau Oracle Blockchain Platform.

  • Le fichier de certificat de l'organisation tierce a été créé et envoyé au fondateur du 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 de commande 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 de 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 l'interface de ligne de commande Hyperledger Fabric ou les trousses SDK. Consultez la documentation sur Hyperledger Fabric.

Installer le code de chaîne

L'organisation tierce doit installer le code de chaîne sur les pairs. Ces pairs doivent ensuite être joints au canal afin que le code de chaîne puisse être appelé.

Déployer le code de chaîne

Si nécessaire, les organisations tierces peuvent déployer le code de chaîne sur le canal. Par 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 l'interface de ligne de commande ou les trousses SDK Hyperledger Fabric pour appeler le code de chaîne. Par 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"]}'