Aggiungi organizzazioni con certificati di terze parti alla rete

Questo argomento contiene informazioni su come unire le 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

Le organizzazioni con certificati emessi da un'autorità di certificazione (CA) di terze parti possono aderire alla rete Oracle Blockchain Platform come partecipanti.

Organizzazioni solo client

Questi partecipanti sono organizzazioni solo clienti e non hanno colleghi o committenti. Non possono creare canali, unire pari livello o installare il codice concatenato.

Dopo essere entrati nella rete, queste organizzazioni possono utilizzare un SDK o un'interfaccia CLI di Hyperledger Fabric per completare i task riportati di seguito.
  • Distribuire, richiamare ed eseguire query sul codice concatenato se si tratta di un amministratore dell'organizzazione client.
  • Richiama ed esegue una query sul codice concatenato se non è un amministratore dell'organizzazione client.
Gli utenti riportati di seguito possono eseguire operazioni 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 nei peer può decidere chi può distribuire il codice concatenato utilizzando il comando dei criteri di creazione delle istanze di Hyperledger Fabric peer chaincode package -i per impostare il criterio di creazione delle istanze per il codice concatenato.
  • L'istanziatore del codice concatenato può utilizzare il comando dei criteri di approvazione di Hyperledger Fabric peer chaincode instantiate -P per impostare il criterio di approvazione che controlla chi può richiamare il codice concatenato.
  • Il proprietario del canale può decidere chi può chiamare o interrogare un codice concatenato impostando la proposta del canale e l'elenco di controllo dell'accesso alle query. Per ulteriori informazioni, vedere Hyperledger Fabric Access Control List.

Flusso di lavoro

L'organizzazione con certificati di terze parti e il fondatore di Oracle Blockchain Platform devono completare le seguenti attività per entrare nell'organizzazione in una rete Oracle Blockchain Platform.

Task Chi lo fa? Descrizione Ulteriori informazioni
Ottenere 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 importarli nella rete. Requisiti certificati di terze parti
Creare il file dei certificati per l'importazione Organizzazione certificati di terze parti (partecipante) Trovare le informazioni sul certificato amministratore e CA del partecipante e utilizzarle per comporre un file di certificati JSON. Creare il 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
Esporta le impostazioni del servizio di ordinazione dal fondatore della rete e forniscile all'organizzazione di terze parti (partecipante) Organizzazione fondatrice Scrivere le impostazioni dei servizi di ordinazione del fondatore in un file JSON e inviare 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, come mostrato nell'esempio seguente:

"orderingServiceNodes": [
{
"address": "grpcs://example_address:7443"
...
}]
 Unisciti alle OSN partecipanti o ridimensionate al servizio di ordinazione del fondatore
Crea il canale Organizzazione fondatrice Creare un canale e aggiungervi il partecipante. Crea un canale
Installare e distribuire il codice concatenato Organizzazione fondatrice Nell'istanza del fondatore, caricare, installare e distribuire il codice concatenato. Scegliere i peer di rete su cui installare il codice concatenato. Usa distribuzione rapida
Impostare l'ambiente dell'organizzazione di terze parti (partecipante) Organizzazione certificati di terze parti (partecipante) Per eseguire query o chiamare i codici concatenati, il partecipante deve completare i passi riportati di seguito.
  • Aggiungere l'indirizzo e la porta del servizio di ordinazione del fondatore all'ambiente del partecipante.
  • Configurare l'ambiente per l'uso dell'interfaccia CLI o degli SDK di Hyperledger Fabric.
  • Installare il codice concatenato sui peer.
 Preparare l'ambiente di terze parti per utilizzare la rete Oracle Blockchain Platform

Requisiti certificati di terze parti

Per entrare correttamente nella 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 i seguenti certificati dal server CA (Certificate Authority):

  • Certificato pubblico client
  • Certificato radice 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 ECDSA (Elliptic Curve Digital Signature Algorithm). ECDSA è l'unico algoritmo accettato per le chiavi MSP (Membership Service Provider) di Hyperledger Fabric.
  • L'identificativo chiave soggetto (SKI) è obbligatorio e nel file di estensione è necessario indicarlo come estensioni x509.
  • È necessario convertire i file chiave dal formato .key al formato .pem.
  • È necessario convertire i certificati dal formato .crt al formato .pem.

Creazione dei certificati

Gli esempi seguenti mostrano come utilizzare OpenSSL o la utility Hyperledger Fabric cryptogen per generare i certificati. Per ulteriori informazioni sui comandi utilizzati, vedere i seguenti siti Web:

Per creare i certificati con OpenSSL, attenersi alla procedura seguente.

  1. Eseguire i comandi seguenti per creare un certificato e una chiave CA autofirmati:
    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 testo seguente mostra un esempio di file 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. Eseguire i comandi seguenti per creare un certificato e una chiave utente utilizzando la chiave CA precedente.
    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 testo seguente mostra un esempio di file 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
Per creare i certificati utilizzando la utility Hyperledger Fabric cryptogen, eseguire il comando seguente.
cryptogen generate --config=./crypto-config.yaml
Il testo seguente mostra un esempio di file 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

Operazioni successive

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

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

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

Andare 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 JSON e contenere i seguenti campi:

  • mspid: specifica il nome dell'organizzazione.
  • tipo: indica che l'organizzazione è un partecipante alla 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 utilizzare la rete Oracle Blockchain Platform

È necessario impostare l'ambiente dell'organizzazione di terze parti prima che possa utilizzare la rete Oracle Blockchain Platform.

Confermare che i seguenti task prerequisiti sono stati completati. Per informazioni, vedere Workflow tipico per l'adesione a 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 dato 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 gli ha aggiunto l'organizzazione di terze parti.
  • Il fondatore della rete ha installato e creato un'istanza del codice concatenato.

Impostazione dell'ambiente dell'organizzazione

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

Installa Chaincode

L'organizzazione di terze parti deve installare il codice concatenato sui peer. Questi peer devono quindi essere uniti al canale in modo che il codice concatenato possa essere richiamato.

Distribuire 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 codice concatenato

Le organizzazioni di terze parti utilizzano l'interfaccia CLI o gli SDK di 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"]}'