Adición de organizaciones con certificados de terceros a la red

En este tema se incluye información sobre la unión de organizaciones que utilizan certificados de terceros a una red de Oracle Blockchain Platform.

Flujo de trabajo típico para unirse a una organización con certificados de terceros en una red de Oracle Blockchain Platform

Las organizaciones con certificados emitidos por una autoridad de certificación (CA) de terceros pueden unirse a la red de Oracle Blockchain Platform como participantes.

Organizaciones Sólo Cliente

Estos participantes son organizaciones solo para clientes y no tienen iguales ni solicitantes. No pueden crear canales, unirse a iguales ni instalar código de cadenas.

Después de unirse a la red, estas organizaciones pueden utilizar un SDK o una CLI de Hyperledger Fabric para:
  • Despliegue, llame y consulte el código de cadenas si es un administrador de la organización del cliente.
  • Llame y consulte el código de cadenas si es una organización de cliente que no es administrador.
Para controlar quién puede desplegar y llamar al código de cadenas cuando las organizaciones que solo son clientes forman parte de la red:
  • El propietario del código de cadena que instala el código de cadena en los peers puede decidir quién puede desplegar el código de cadena mediante el comando de la política de instanciación peer chaincode package -i de Hyperledger Fabric para definir la política de instanciación para el código de cadena.
  • El instanciador de código de cadena puede utilizar el comando de política de endoso peer chaincode instantiate -P de Hyperledger Fabric para definir la política de endoso que controla quién puede llamar al código de cadena.
  • El propietario del canal puede decidir quién puede llamar o consultar un código de cadenas definiendo la propuesta de canal y la lista de control de acceso de consulta. Consulte Listas de control de acceso de Hyperledger Fabric.

Flujo de trabajo

Estas son las tareas que una organización con certificados de terceros y el fundador de Oracle Blockchain Platform deben realizar para unirse a la organización en una red de Oracle Blockchain Platform.

Tarea ¿Quién hace esto? Descripción Más información
Obtener los certificados de terceros Organización de certificados de terceros (participante) Vaya al servidor de CA de terceros y genere los archivos de certificados necesarios. Formatee los archivos según sea necesario para importarlos en la red. Requisitos de certificado de terceros
Crear el archivo de certificados para la importación Organización de certificados de terceros (participante) Busque la información del certificado de administrador y CA del participante y utilícela para componer un archivo de certificados JSON. Creación del archivo de certificados de terceros de una organización
Cargar un archivo de certificado para la organización de terceros (participante) Organización fundadora Utilice la consola para cargar e importar el archivo de certificado del participante para agregar el participante a la red. Importación de certificados para agregar organizaciones a la red
Exportar la configuración del servicio de pedido del fundador de la red y proporcionarla a la organización de terceros (participante) Organización fundadora Realice la salida de la configuración de los servicios de pedido del fundador en un archivo JSON y envíelo al participante.

Abra el archivo de configuración del servicio de pedido y busque la dirección y el puerto del servicio de pedido y dárselo al participante. Por ejemplo:

"orderingServiceNodes": [
{
"address": "grpcs://example_address:7777"
...
}]
 Unirse a los OSN participantes o escalados al servicio de pedidos del fundador
Crear el canal Fundador Cree un nuevo canal y agregue el participante. Crear Canal
Instalar y desplegar el código de cadena Fundador En la instancia del fundador, cargue, instale y despliegue el código de cadenas. Seleccione los peers de red en los que desea instalar el código de cadenas. Uso de despliegue rápido
Configurar el entorno de la organización de terceros (participante) Organización de certificados de terceros (participante) Para consultar o llamar a los códigos de cadenas, el participante debe:
  • Agregue la dirección y el puerto del servicio de pedidos del fundador al entorno del participante.
  • Configure el entorno para utilizar la CLI o los SDK de Hyperledger Fabric.
  • Instale el código de cadena en los peers.
 Preparación del entorno de terceros para utilizar la red de Oracle Blockchain Platform

Requisitos de certificado de terceros

Para unirse correctamente a la red, una organización debe generar los certificados de terceros necesarios. La información de estos certificados se utiliza para crear el archivo de certificados de la organización, que luego se importa a la instancia del fundador.

¿Qué certificados deben proporcionar las organizaciones?

Debe generar los siguientes certificados desde el servidor de CA:

  • Certificado público de cliente
  • Certificado raíz de CA

¿Cuáles son los requisitos para estos certificados?

Los certificados deben cumplir los siguientes requisitos:

  • Al generar la clave privada, debe utilizar el algoritmo de firma digital de curva elíptica (ECDSA). Este algoritmo es el único algoritmo aceptado para claves de Fabric MSP.
  • El identificador de clave de asunto (SKI) es obligatorio y debe indicarlo como extensiones x509 en el archivo de extensión.
  • Debe convertir los archivos de claves del formato .key al formato .pem.
  • Debe convertir los certificados del formato .crt al formato .pem.

Creación de los certificados

El siguiente repaso es un ejemplo de cómo utilizar OpenSSL o la utilidad de cifrado de Hyperledger Fabric para generar los certificados. Para obtener información detallada sobre los comandos utilizados, consulte:

Para crear los certificados mediante OpenSSL:

  1. Cree una clave/certificado de CA autofirmada:
    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
    Nuestro archivo opensslca.conf de ejemplo:
    [ 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. Cree un certificado/clave de usuario con la clave de CA anterior:
    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
    Nuestro archivo openssl.conf de ejemplo:
    [ 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
Para crear los certificados mediante la utilidad de cifrado de Hyperledger Fabric:
  • Los siguientes comandos de cifrado se utilizan para crear material de claves de Hyperledger Fabric:
    cryptogen generate --config=./crypto-config.yaml
    Nuestro archivo crypto-config.yaml de ejemplo:
    # 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

Siguiente paso

Después de confirmar que ha generado y actualizado los archivos adecuados, puede crear el archivo de certificados para importar en la red de Oracle Blockchain Platform. Consulte Creación del archivo de certificados de terceros de una organización.

Creación del archivo de certificados de terceros de una organización

Para unirse a una red de Oracle Blockchain Platform, la organización debe escribir un archivo de certificados que contenga su información de administrador y cacerte. El fundador de la red importa este archivo para agregar la organización a la red.

Vaya a los archivos de certificados que ha generado desde el servidor de CA para buscar la información necesaria para crear el archivo de certificados. Consulte Third-Party Certificate Requirements.

El archivo de certificados debe estar escrito en JSON y contener los siguientes campos:

  • mspid: especifica el nombre de la organización.
  • type (Tipo): indica que la organización es un participante de la red. Este valor debe ser Participante.
  • admincert: contiene el contenido del archivo de certificados de administrador de la organización. Al copiar la información de certificados en el archivo JSON, debe sustituir cada línea nueva por \n.
  • cacert: contiene el contenido del archivo de certificados de CA de la organización. Al copiar la información de certificados en el archivo JSON, debe sustituir cada línea nueva por \n.
Así es como se debe estructurar el archivo: 
{
  "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"
 }
}

Preparación del entorno de terceros para utilizar la red de Oracle Blockchain Platform

Debe configurar el entorno de la organización de terceros para que pueda utilizar la red de Oracle Blockchain Platform.

Confirme que se hayan completado las siguientes tareas previas necesarias. Para obtener más información, consulte Typical Workflow to Join an Organization With Third-Party Certificates to an Oracle Blockchain Platform Network.

  • El archivo de certificado de la organización de terceros se creó y envió al fundador de la red de Oracle Blockchain Platform.
  • El fundador de la red cargó el archivo de certificados para agregar la organización de terceros a la red.
  • El fundador de la red exportó la configuración del servicio del solicitante y dio la dirección y el puerto del servicio a la organización de terceros y la organización los agregó al entorno.
  • El fundador de la red creó un nuevo canal y le agregó la organización de terceros.
  • El fundador de la red instaló e instanció el código de cadenas.

Configurar entorno de organización

Para que la organización de terceros pueda utilizar correctamente la red de Oracle Blockchain Platform, debe configurar su entorno para utilizar la CLI o los SDK de Hyperledger Fabric. Consulte la documentación de Hyperledger Fabric.

Instalar el código de cadena

La organización de terceros debe instalar el código de cadenas en los iguales. A continuación, estos peers se deben unir al canal para que se pueda llamar al código de cadenas.

Despliegue del código de cadenas

Si es necesario, las organizaciones de terceros pueden desplegar el código de cadenas en el canal. Por ejemplo:

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

Llamar al código de cadena

Las organizaciones de terceros utilizan la CLI o los SDK de Hyperledger Fabric para llamar al código de cadenas. Por ejemplo:

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