1. Usando o Oracle Blockchain Platform
  2. Estenda a Rede
  3. Adicionar Organizações com Certificados de Terceiros à Rede

Adicionar Organizações com Certificados de Terceiros à Rede

Este tópico contém informações sobre a associação de organizações que usam certificados de terceiros a uma rede do Oracle Blockchain Platform.

Workflow Típico para Participar de uma Organização com Certificados de Terceiros em uma Rede do Oracle Blockchain Platform

A organização com certificados emitidos por uma autoridade de certificação (CA) de terceiros pode ingressar na rede do Oracle Blockchain Platform como participantes.

Organizações somente para clientes

Esses participantes são organizações somente para clientes e não têm colegas ou solicitantes. Eles não podem criar canais, unir pares ou instalar chaincode.

Depois de ingressar na rede, essas organizações podem usar um SDK ou uma CLI do Hyperledger Fabric para:
  • Implante, chame e consulte o chaincode se ele for um administrador da organização cliente.
  • Chame e consulte o chaincode se eles não forem administradores de uma organização cliente.
Para controlar quem pode implantar e chamar o chaincode quando organizações somente clientes fazem parte da rede:
  • O proprietário do chaincode que instala o chaincode nos pares pode decidir quem pode implantar o chaincode usando o comando da política de instanciação peer chaincode package -i do Hyperledger Fabric para definir a política de instanciação do chaincode.
  • O instanciador de chaincode pode usar o comando de política de endosso peer chaincode instantiate -P do Hyperledger Fabric para definir a política de endosso que controla quem pode chamar o chaincode.
  • O proprietário do canal pode decidir quem pode chamar ou consultar um chaincode definindo a proposta do canal e a lista de controle de acesso de consulta. Consulte Listas de Controle de Acesso do Hyperledger Fabric.

Fluxo de Trabalho

Estas são as tarefas que uma organização com certificados de terceiros e o fundador do Oracle Blockchain Platform precisam executar para ingressar na organização em uma rede do Oracle Blockchain Platform.

Tarefa Quem faz isso? Descrição Mais informações
Obtenha os certificados de terceiros Organização de certificados de terceiros (participante) Vá para o servidor CA de terceiros e gere os arquivos de certificados necessários. Formate os arquivos conforme necessário para importação na rede. Requisitos de Certificado de Terceiros
Criar o arquivo de certificados para importação Organização de certificados de terceiros (participante) Localize as informações de certificado Admin e CA do participante e use-as para compor um arquivo de certificados JSON. Criar o Arquivo de Certificados de Terceiros de uma Organização
Fazer upload de um arquivo de certificado para a organização de terceiros (participante) Organização fundadora Use a console para carregar e importar o arquivo de certificado do participante para adicionar o participante à rede. Importar Certificados para Adicionar Organizações à Rede
Exporte as configurações do serviço de pedido do fundador da rede e forneça-as à organização de terceiros (participante) Organização fundadora Envie as configurações de serviços de pedido do fundador para um arquivo JSON e envie o arquivo para o participante.

Abra o arquivo de configurações do serviço de pedido e encontre o endereço e a porta do serviço de pedido e entregue-os ao participante. Por exemplo:

"orderingServiceNodes": [
{
"address": "grpcs://example_address:7777"
...
}]
 Junte-se aos OSNs Participantes ou Escalonados ao Serviço de Pedidos do Fundador
Criar o canal Fundador Crie um novo canal e adicione o participante a ele. Criar um Canal
Instalar e implantar o chaincode Fundador Na instância do fundador, faça upload, instale e implante o chaincode. Escolha os pares de rede nos quais instalar o chaincode.
Configurar o ambiente da organização de terceiros (participante) Organização de certificados de terceiros (participante) Para consultar ou chamar chaincodes, o participante deve:
  • Adicione o endereço e a porta do serviço de pedido do fundador ao ambiente do participante.
  • Configure o ambiente para usar a CLI ou SDKs do Hyperledger Fabric.
  • Instale o chaincode nos pares.
 Preparar o Ambiente de Terceiros para Usar a Rede do Oracle Blockchain Platform

Requisitos de Certificado de Terceiros

Para ingressar com êxito na rede, uma organização deve gerar os certificados de terceiros necessários. As informações nesses certificados são usadas para criar o arquivo de certificados da organização, que é importado para a instância do fundador.

Quais Certificados as Organizações Precisam Fornecer?

Você deve gerar os seguintes certificados do seu servidor de CA:

  • Certificado Público do Cliente
  • Certificado Raiz da CA

Quais São os Requisitos para Esses Certificados?

Os certificados devem atender aos seguintes requisitos:

  • Ao gerar a chave privada, você deve usar o Algoritmo de Assinatura Digital da Curva Elíptica (ECDSA). Esse algoritmo é o único algoritmo aceito para chaves MSP do Fabric.
  • O Identificador de Chave de Assunto (SKI) é obrigatório e você deve indicá-lo como extensões x509 no arquivo de extensão.
  • Você deve converter os arquivos de chave do .key para o formato .pem.
  • Você deve converter os certificados do .crt para o formato .pem.

Criando os Certificados

O passo a passo a seguir é um exemplo de como usar o OpenSSL ou o utilitário de criptografia Hyperledger Fabric para gerar seus certificados. Para obter informações detalhadas sobre os comandos usados, consulte:

Para criar seus certificados usando OpenSSL:

  1. Criar um certificado/chave de CA autoassinado:
    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
    Nosso arquivo opensslca.conf de exemplo:
    [ 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. Crie um certificado/chave de usuário usando a chave CA acima:
    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
    Nosso arquivo openssl.conf de exemplo:
    [ 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 criar seus certificados usando o utilitário de criptografia do Hyperledger Fabric:
  • Os seguintes comandos criptógenos são usados para criar o material da chave do Hyperledger Fabric:
    cryptogen generate --config=./crypto-config.yaml
    Nosso arquivo crypto-config.yaml de exemplo:
    # 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

O Que Vem a Seguir?

Depois de confirmar que você gerou e atualizou os arquivos apropriados, você poderá criar o arquivo de certificados para importação na rede do Oracle Blockchain Platform. Consulte Criar o Arquivo de Certificados de Terceiros de uma Organização.

Criar o Arquivo de Certificados de Terceiros de uma Organização

Para ingressar em uma rede do Oracle Blockchain Platform, a organização deve gravar um arquivo de certificados contendo suas informações de admincert e cacert. O fundador da rede importa esse arquivo para adicionar a organização à rede.

Vá para os arquivos de certificados que você gerou do servidor de CA para encontrar as informações necessárias para criar o arquivo de certificados. Consulte Requisitos de Certificado de Terceiros.

O arquivo de certificados deve estar escrito em JSON e conter os seguintes campos:

  • mspid - Especifica o nome da organização.
  • tipo - Indica que a organização é um participante da rede. Esse valor deve ser Participante.
  • admincert - Contém o conteúdo do arquivo de certificados administrativos da organização. Ao copiar as informações de certificados para o arquivo JSON, você deve substituir cada nova linha por \n.
  • cacert - Contém o conteúdo do arquivo de certificados CA da organização. Ao copiar as informações de certificados para o arquivo JSON, você deve substituir cada nova linha por \n.
É assim que o arquivo precisa ser estruturado: 
{
  "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"
 }
}

Preparar o Ambiente de Terceiros para Usar a Rede do Oracle Blockchain Platform

Você deve configurar o ambiente da organização de terceiros para que ela possa usar a rede do Oracle Blockchain Platform.

Confirme se as tarefas de pré-requisito a seguir foram concluídas. Para obter informações, consulte Workflow Típico para Participar de uma Organização com Certificados de Terceiros em uma Rede do Oracle Blockchain Platform.

  • O arquivo de certificado da organização de terceiros foi criado e enviado ao fundador da rede do Oracle Blockchain Platform.
  • O fundador da rede fez upload do arquivo de certificados para adicionar a organização de terceiros à rede.
  • O fundador da rede exportou as configurações do serviço do solicitante e deu o endereço e a porta do serviço para a organização de terceiros e a organização as adicionou ao ambiente.
  • O fundador da rede criou um novo canal e adicionou a organização de terceiros a ele.
  • O fundador da rede instalou e instanciou o chaincode.

Configurar o Ambiente da organização

Para que a organização de terceiros possa usar com sucesso a rede do Oracle Blockchain Platform, ela deve configurar seu ambiente para usar a CLI ou SDKs do Hyperledger Fabric. Consulte a documentação do Hyperledger Fabric.

Instalar o Chaincode

A organização de terceiros deve instalar o chaincode nos pares. Esses pares devem ser unidos ao canal para que o chaincode possa ser chamado.

Implantar o Chaincode

Se necessário, as organizações de terceiros podem implantar o chaincode no canal. Por exemplo:

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

Chamar o Chaincode

Organizações de terceiros usam a CLI ou SDKs do Hyperledger Fabric para chamar o chaincode. Por exemplo:

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