1. Utilizzo di Oracle Blockchain Platform
  2. Estendi la rete
  3. Aggiungi organizzazioni con certificati di terze parti alla rete

Aggiungi organizzazioni con certificati di terze parti alla rete

Questo argomento contiene informazioni sull'adesione di organizzazioni che utilizzano certificati di terze parti a una rete Oracle Blockchain Platform.

Workflow standard per entrare a far parte di un'organizzazione con certificati di terze parti in una rete Oracle Blockchain Platform

L'organizzazione con certificati emessi da un'autorità di certificazione (CA) di terze parti può aderire alla rete Oracle Blockchain Platform come partecipanti.

Organizzazioni solo client

Questi partecipanti sono organizzazioni solo clienti e non hanno pari o ordini. Non possono creare canali, unire peer o installare codice concatenato.

Dopo essere entrate a far parte della rete, queste organizzazioni possono utilizzare un SDK o un'interfaccia CLI Hyperledger Fabric per:
  • Distribuire, richiamare ed eseguire query sul codice concatenato se si è un amministratore dell'organizzazione client.
  • Richiama ed esegui query sul codice concatenato se non è un amministratore dell'organizzazione client.
Per controllare chi può distribuire e richiamare il codice concatenato quando le organizzazioni solo client fanno parte della rete:
  • Il proprietario del codice concatenato che installa il codice concatenato sui pari livello può decidere chi può distribuire il codice concatenato utilizzando il comando dei criteri di creazione delle istanze peer chaincode package -i di Hyperledger Fabric per impostare i criteri di creazione delle istanze per il codice concatenato.
  • Il creatore di istanze del codice concatenato può utilizzare il comando dei criteri di approvazione peer chaincode instantiate -P di Hyperledger Fabric per impostare il criterio di approvazione che controlla chi può richiamare il codice concatenato.
  • Il proprietario del canale può decidere chi può richiamare o eseguire query su un codice concatenato impostando la proposta del canale e la lista di controllo dell'accesso delle query. Vedere Hyperledger Fabric Access Control List.

Flusso di lavoro

Ecco i task che un'organizzazione con certificati di terze parti e il fondatore di Oracle Blockchain Platform devono eseguire per entrare a far parte dell'organizzazione in una rete Oracle Blockchain Platform.

Task Chi lo fa? Descrizione Ulteriori informazioni
Ottieni i certificati di terze parti Organizzazione certificati di terze parti (partecipante) Andare al server CA di terze parti e generare i file dei certificati richiesti. Formattare i file in base alle esigenze per l'importazione nella rete. Requisiti per certificati di terze parti
Creare il file dei certificati per l'importazione Organizzazione certificati di terze parti (partecipante) Trovare le informazioni sui certificati di amministrazione e CA del partecipante e utilizzarle per comporre un file di certificati JSON. Creare un file dei certificati di terze parti di un'organizzazione
Caricare un file di certificato per l'organizzazione di terze parti (partecipante) Organizzazione fondatrice Utilizzare la console per caricare e importare il file del certificato del partecipante per aggiungere il partecipante alla rete. Importa certificati per aggiungere organizzazioni alla rete
Esportare le impostazioni del servizio di ordinazione dal fondatore della rete e fornirle all'organizzazione di terze parti (partecipanti) Organizzazione fondatrice Inserisci le impostazioni dei servizi di ordinazione del fondatore in un file JSON e invia il file al partecipante.

Aprire il file delle impostazioni del servizio di ordinazione e trovare l'indirizzo e la porta del servizio di ordinazione e consegnarli al partecipante. Ad esempio:

"orderingServiceNodes": [
{
"address": "grpcs://example_address:7777"
...
}]
 Unisciti ai partecipanti o agli OSN a scalabilità orizzontale al servizio di ordinazione del fondatore
Creare il canale Fondatore Creare un nuovo canale e aggiungervi il partecipante. Crea un canale
Installa e distribuisci il codice concatenato Fondatore Nell'istanza del fondatore, carica, installa e distribuisci il codice concatenato. Scegliere i peer di rete su cui installare il codice concatenato.
Impostare l'ambiente dell'organizzazione di terze parti (partecipante) Organizzazione certificati di terze parti (partecipante) Per eseguire una query o richiamare i codici concatenati, il partecipante deve:
  • Aggiungi l'indirizzo e la porta del servizio di ordinazione del fondatore all'ambiente del partecipante.
  • Configurare l'ambiente per l'uso delle interfacce CLI o degli SDK di Hyperledger Fabric.
  • Installare il codice concatenato sui peer.
 Preparare l'ambiente di terze parti per l'utilizzo di Oracle Blockchain Platform Network

Requisiti per certificati di terze parti

Per accedere correttamente alla rete, un'organizzazione deve generare i certificati di terze parti richiesti. Le informazioni contenute in questi certificati vengono utilizzate per creare il file dei certificati dell'organizzazione, che viene quindi importato nell'istanza del fondatore.

Quali certificati devono fornire le organizzazioni?

È necessario generare dal server CA i seguenti certificati:

  • Certificato pubblico client
  • Certificato root CA

Quali sono i requisiti per questi certificati?

I certificati devono soddisfare i seguenti requisiti:

  • Quando si genera la chiave privata, è necessario utilizzare l'algoritmo di firma digitale a curva ellittica (ECDSA). Questo algoritmo è l'unico algoritmo accettato per le chiavi MSP Fabric.
  • L'identificativo chiave oggetto (SKI) è obbligatorio ed è necessario indicarlo come estensione x509 nel file di estensione.
  • È necessario convertire i file chiave dal formato .key al formato .pem.
  • È necessario convertire i certificati da .crt in formato .pem.

Creazione dei certificati

Di seguito è riportato un esempio di come utilizzare OpenSSL o l'utilità di crittografia Hyperledger Fabric per generare i certificati. Per informazioni dettagliate sui comandi utilizzati, consultare:

Per creare i certificati utilizzando OpenSSL:

  1. Creare un certificato/chiave CA autofirmato:
    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
    Il nostro file opensslca.conf di esempio:
    [ 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. Creare un certificato/chiave utente utilizzando la chiave CA sopra riportata:
    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
    Il nostro file openssl.conf di esempio:
    [ 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
Per creare i certificati utilizzando la utility crittogen Hyperledger Fabric:
  • Per creare il materiale chiave Hyperledger Fabric vengono utilizzati i seguenti comandi di crittografia:
    cryptogen generate --config=./crypto-config.yaml
    Il nostro file crypto-config.yaml di esempio:
    # 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

Operazione successiva?

Dopo aver confermato di aver eseguito l'output e aggiornato i file appropriati, è possibile creare il file dei certificati da importare nella rete Oracle Blockchain Platform. Vedere Creazione di un file di certificati di terze parti di un'organizzazione.

Creare un file dei certificati di terze parti di un'organizzazione

Per entrare in una rete Oracle Blockchain Platform, l'organizzazione deve scrivere un file di certificati contenente le relative informazioni su admincert e cacert. Il fondatore della rete importa questo file per aggiungere l'organizzazione alla rete.

Accedere ai file dei certificati generati dal server CA per trovare le informazioni necessarie per creare il file dei certificati. Vedere Requisiti dei certificati di terze parti.

Il file dei certificati deve essere scritto in formato JSON e contenere i campi riportati di seguito.

  • mspid: specifica il nome dell'organizzazione.
  • tipo: indica che l'organizzazione è un partecipante di rete. Questo valore deve essere Partecipante.
  • admincert: contiene il contenuto del file dei certificati di amministrazione dell'organizzazione. Quando si copiano le informazioni sui certificati nel file JSON, è necessario sostituire ogni nuova riga con \n.
  • cacert: contiene il contenuto del file dei certificati CA dell'organizzazione. Quando si copiano le informazioni sui certificati nel file JSON, è necessario sostituire ogni nuova riga con \n.
Ecco come deve essere strutturato il file: 
{
  "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"
 }
}

Preparare l'ambiente di terze parti per l'utilizzo della rete Oracle Blockchain Platform

Prima di poter utilizzare la rete Oracle Blockchain Platform, è necessario impostare l'ambiente dell'organizzazione di terze parti.

Confermare che i seguenti task prerequisiti sono stati completati. Per informazioni, vedere Flusso di lavoro tipico per l'adesione di un'organizzazione con certificati di terze parti a una rete Oracle Blockchain Platform.

  • Il file di certificato dell'organizzazione di terze parti è stato creato e inviato al fondatore della rete Oracle Blockchain Platform.
  • Il fondatore della rete ha caricato il file dei certificati per aggiungere l'organizzazione di terze parti alla rete.
  • Il fondatore della rete ha esportato le impostazioni del servizio ordinante e ha fornito l'indirizzo e la porta del servizio all'organizzazione di terze parti e l'organizzazione le ha aggiunte all'ambiente.
  • Il fondatore della rete ha creato un nuovo canale e ha aggiunto l'organizzazione di terze parti ad esso.
  • Il fondatore della rete ha installato e creato un'istanza del codice concatenato.

Impostazione dell'ambiente dell'organizzazione

Affinché l'organizzazione di terze parti possa utilizzare correttamente la rete Oracle Blockchain Platform, è necessario impostare il proprio ambiente in modo che utilizzi l'interfaccia CLI o gli SDK Hyperledger Fabric. Consulta la documentazione di Hyperledger Fabric.

Installa il codice concatenato

L'organizzazione di terze parti deve installare il codice concatenato sui peer. Questi peer devono quindi essere uniti al canale per poter richiamare il codice concatenato.

Distribuisci il codice concatenato

Se necessario, le organizzazioni di terze parti possono distribuire il codice concatenato sul canale. Ad esempio:

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

Richiama il codice concatenato

Le organizzazioni di terze parti utilizzano l'interfaccia CLI o gli SDK Hyperledger Fabric per richiamare il codice concatenato. Ad esempio:

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