fabric-caの設定ファイルを取得する
ブロックチェーン基盤ソフトウェアであるHyperledger Fabricには，デジタル証明書を管理するfabric-caコンポーネントがある。
fabric-caをソースからビルドするのは簡単ではない。より簡単な方法として，dockerでfabric-caコンテナを起動して，設定ファイルを取得してから構成設定する方法がある。
ここでは，fabricコンテナからひな型となる設定ファイルを取得する方法を紹介する。
動作環境・対象のソフトウェア
- Vagrant 2.1.4
- Oracle VM VirtualBox 5.2.18
- CentOS 7
- docker 18.06.1-ce
- docker-compose 1.23.1
- Go 1.10.4
- Hyperledger Fabric 1.3.0
CentOS 7の仮想VM作成
- Vagrant + Oracle VM VirtualBoxを使用して，CentOS 7のゲストOSを起動
- dockerとdocker-composeをインストールする
- git，wget等をインストールする
Go言語をインストール
$ cd /opt
$ sudo wget https://dl.google.com/go/go1.10.4.linux-amd64.tar.gz
$ sudo tar zxvf go1.10.4.linux-amd64.tar.gz
作業用ディレクトリを作成
$ sudo mkdir /vagrant
$ sudo chown vagrant:vagrant /vagrant
GitHubリポジトリからfabric-samplesをclone
$ mkdir -p /vagrant/go/src/github.com/hyperledger
$ cd /vagrant/go/src/github.com/hyperledger
$ git clone https://github.com/hyperledger/fabric-samples.git
Fabricバイナリをインストール
fabric-samplesのscripts/bootstrap.shを使えば，Fabricのバイナリを取得できる。
bootstrap.shの引数はそれぞれ，Fabricのバージョン，Fabric-CAのバージョン，およびサードパーティのバージョン。
$ cd /vagrant/go/src/github.com/hyperledger/fabric-samples
$ ./scripts/bootstrap.sh 1.3.0 1.3.0 0.4.13
インストールに成功すると，次のディレクトリにコマンドが入る。
- /vagrant/go/src/github.com/hyperledger/fabric-samples/bin
また，次のdockerイメージもpullされる。
$ docker images
hyperledger/fabric-ca 1.3.0 …
hyperledger/fabric-ca latest …
hyperledger/fabric-tools 1.3.0 …
hyperledger/fabric-tools latest …
hyperledger/fabric-ccenv 1.3.0 …
hyperledger/fabric-ccenv latest …
hyperledger/fabric-orderer 1.3.0 …
hyperledger/fabric-orderer latest …
hyperledger/fabric-peer 1.3.0 …
hyperledger/fabric-peer latest …
hyperledger/fabric-zookeeper 0.4.13 …
hyperledger/fabric-zookeeper latest …
hyperledger/fabric-kafka 0.4.13 …
hyperledger/fabric-kafka latest …
hyperledger/fabric-couchdb 0.4.13 …
hyperledger/fabric-couchdb latest …
環境変数を設定
~/.bashrc ファイルの最後に，環境変数の設定を追加する。
.bashrc
export GOROOT=/opt/go
export GOPATH=/vagrant/go
export PATH=$PATH:$GOPATH/bin:$GOROOT/bin:$GOPATH/src/github.com/hyperledger/fabric-samples/bin
fabric-caのオリジナルの設定ファイルを取得
docker-composeを使って，fabric-caコンテナを起動させて，設定ファイルを取得する。
まず，そのためのディレクトリを作成する。
mkdir -p /vagrant/ca01/data
cd /vagrant/ca01
docker-compose.ymlを作成する。
docker-compose.yml
version: '2'
networks:
fabric-ca01:
services:
fabric-ca01:
container_name: fabric-ca01
image: hyperledger/fabric-ca
working_dir: "/etc/hyperledger/fabric-ca"
command: bash -c "fabric-ca-server init --boot ca01-admin:ca01-admin-pass && cp fabric-ca-server-config.yaml /data"
environment:
- FABRIC_CA_SERVER_HOME=/etc/hyperledger/fabric-ca
volumes:
- ./data:/data
networks:
- fabric-ca01
docker-composeでfabric-caコンテナを起動させ，後始末する。
$ docker-compose up
$ docker-compose down
正常に実行できたら， /vagrant/ca01/data/fabric-ca-server-config.yaml が生成されている。これが設定ファイルのひな型となる。これをもとにして，オリジナルのfabric-caを構築することができる。
なお，fabric-caコンテナを起動すると，コンテナ内で秘密鍵や証明書ファイルが生成されるが，正式なものではないので，本運用では使えないことに留意されたい。
fabric-ca 1.3.0の設定ファイルの内容
fabric-ca-server-config.yaml
#############################################################################
# This is a configuration file for the fabric-ca-server command.
#
# COMMAND LINE ARGUMENTS AND ENVIRONMENT VARIABLES
# ------------------------------------------------
# Each configuration element can be overridden via command line
# arguments or environment variables. The precedence for determining
# the value of each element is as follows:
# 1) command line argument
# Examples:
# a) --port 443
# To set the listening port
# b) --ca.keyfile ../mykey.pem
# To set the "keyfile" element in the "ca" section below;
# note the '.' separator character.
# 2) environment variable
# Examples:
# a) FABRIC_CA_SERVER_PORT=443
# To set the listening port
# b) FABRIC_CA_SERVER_CA_KEYFILE="../mykey.pem"
# To set the "keyfile" element in the "ca" section below;
# note the '_' separator character.
# 3) configuration file
# 4) default value (if there is one)
# All default values are shown beside each element below.
#
# FILE NAME ELEMENTS
# ------------------
# The value of all fields whose name ends with "file" or "files" are
# name or names of other files.
# For example, see "tls.certfile" and "tls.clientauth.certfiles".
# The value of each of these fields can be a simple filename, a
# relative path, or an absolute path. If the value is not an
# absolute path, it is interpretted as being relative to the location
# of this configuration file.
#
#############################################################################
# Version of config file
version: 1.3.0
# Server's listening port (default: 7054)
port: 7054
# Enables debug logging (default: false)
debug: false
# Size limit of an acceptable CRL in bytes (default: 512000)
crlsizelimit: 512000
#############################################################################
# TLS section for the server's listening port
#
# The following types are supported for client authentication: NoClientCert,
# RequestClientCert, RequireAnyClientCert, VerifyClientCertIfGiven,
# and RequireAndVerifyClientCert.
#
# Certfiles is a list of root certificate authorities that the server uses
# when verifying client certificates.
#############################################################################
tls:
# Enable TLS (default: false)
enabled: false
# TLS for the server's listening port
certfile:
keyfile:
clientauth:
type: noclientcert
certfiles:
#############################################################################
# The CA section contains information related to the Certificate Authority
# including the name of the CA, which should be unique for all members
# of a blockchain network. It also includes the key and certificate files
# used when issuing enrollment certificates (ECerts) and transaction
# certificates (TCerts).
# The chainfile (if it exists) contains the certificate chain which
# should be trusted for this CA, where the 1st in the chain is always the
# root CA certificate.
#############################################################################
ca:
# Name of this CA
name:
# Key file (is only used to import a private key into BCCSP)
keyfile:
# Certificate file (default: ca-cert.pem)
certfile:
# Chain file
chainfile:
#############################################################################
# The gencrl REST endpoint is used to generate a CRL that contains revoked
# certificates. This section contains configuration options that are used
# during gencrl request processing.
#############################################################################
crl:
# Specifies expiration for the generated CRL. The number of hours
# specified by this property is added to the UTC time, the resulting time
# is used to set the 'Next Update' date of the CRL.
expiry: 24h
#############################################################################
# The registry section controls how the fabric-ca-server does two things:
# 1) authenticates enrollment requests which contain a username and password
# (also known as an enrollment ID and secret).
# 2) once authenticated, retrieves the identity's attribute names and
# values which the fabric-ca-server optionally puts into TCerts
# which it issues for transacting on the Hyperledger Fabric blockchain.
# These attributes are useful for making access control decisions in
# chaincode.
# There are two main configuration options:
# 1) The fabric-ca-server is the registry.
# This is true if "ldap.enabled" in the ldap section below is false.
# 2) An LDAP server is the registry, in which case the fabric-ca-server
# calls the LDAP server to perform these tasks.
# This is true if "ldap.enabled" in the ldap section below is true,
# which means this "registry" section is ignored.
#############################################################################
registry:
# Maximum number of times a password/secret can be reused for enrollment
# (default: -1, which means there is no limit)
maxenrollments: -1
# Contains identity information which is used when LDAP is disabled
identities:
- name: ca01-admin
pass: ca01-admin-pass
type: client
affiliation: ""
attrs:
hf.Registrar.Roles: "*"
hf.Registrar.DelegateRoles: "*"
hf.Revoker: true
hf.IntermediateCA: true
hf.GenCRL: true
hf.Registrar.Attributes: "*"
hf.AffiliationMgr: true
#############################################################################
# Database section
# Supported types are: "sqlite3", "postgres", and "mysql".
# The datasource value depends on the type.
# If the type is "sqlite3", the datasource value is a file name to use
# as the database store. Since "sqlite3" is an embedded database, it
# may not be used if you want to run the fabric-ca-server in a cluster.
# To run the fabric-ca-server in a cluster, you must choose "postgres"
# or "mysql".
#############################################################################
db:
type: sqlite3
datasource: fabric-ca-server.db
tls:
enabled: false
certfiles:
client:
certfile:
keyfile:
#############################################################################
# LDAP section
# If LDAP is enabled, the fabric-ca-server calls LDAP to:
# 1) authenticate enrollment ID and secret (i.e. username and password)
# for enrollment requests;
# 2) To retrieve identity attributes
#############################################################################
ldap:
# Enables or disables the LDAP client (default: false)
# If this is set to true, the "registry" section is ignored.
enabled: false
# The URL of the LDAP server
url: ldap://<adminDN>:<adminPassword>@<host>:<port>/<base>
# TLS configuration for the client connection to the LDAP server
tls:
certfiles:
client:
certfile:
keyfile:
# Attribute related configuration for mapping from LDAP entries to Fabric CA attributes
attribute:
# 'names' is an array of strings containing the LDAP attribute names which are
# requested from the LDAP server for an LDAP identity's entry
names: ['uid','member']
# The 'converters' section is used to convert an LDAP entry to the value of
# a fabric CA attribute.
# For example, the following converts an LDAP 'uid' attribute
# whose value begins with 'revoker' to a fabric CA attribute
# named "hf.Revoker" with a value of "true" (because the boolean expression
# evaluates to true).
# converters:
# - name: hf.Revoker
# value: attr("uid") =~ "revoker*"
converters:
- name:
value:
# The 'maps' section contains named maps which may be referenced by the 'map'
# function in the 'converters' section to map LDAP responses to arbitrary values.
# For example, assume a user has an LDAP attribute named 'member' which has multiple
# values which are each a distinguished name (i.e. a DN). For simplicity, assume the
# values of the 'member' attribute are 'dn1', 'dn2', and 'dn3'.
# Further assume the following configuration.
# converters:
# - name: hf.Registrar.Roles
# value: map(attr("member"),"groups")
# maps:
# groups:
# - name: dn1
# value: peer
# - name: dn2
# value: client
# The value of the user's 'hf.Registrar.Roles' attribute is then computed to be
# "peer,client,dn3". This is because the value of 'attr("member")' is
# "dn1,dn2,dn3", and the call to 'map' with a 2nd argument of
# "group" replaces "dn1" with "peer" and "dn2" with "client".
maps:
groups:
- name:
value:
#############################################################################
# Affiliations section. Fabric CA server can be bootstrapped with the
# affiliations specified in this section. Affiliations are specified as maps.
# For example:
# businessunit1:
# department1:
# - team1
# businessunit2:
# - department2
# - department3
#
# Affiliations are hierarchical in nature. In the above example,
# department1 (used as businessunit1.department1) is the child of businessunit1.
# team1 (used as businessunit1.department1.team1) is the child of department1.
# department2 (used as businessunit2.department2) and department3 (businessunit2.department3)
# are children of businessunit2.
# Note: Affiliations are case sensitive except for the non-leaf affiliations
# (like businessunit1, department1, businessunit2) that are specified in the configuration file,
# which are always stored in lower case.
#############################################################################
affiliations:
org1:
- department1
- department2
org2:
- department1
#############################################################################
# Signing section
#
# The "default" subsection is used to sign enrollment certificates;
# the default expiration ("expiry" field) is "8760h", which is 1 year in hours.
#
# The "ca" profile subsection is used to sign intermediate CA certificates;
# the default expiration ("expiry" field) is "43800h" which is 5 years in hours.
# Note that "isca" is true, meaning that it issues a CA certificate.
# A maxpathlen of 0 means that the intermediate CA cannot issue other
# intermediate CA certificates, though it can still issue end entity certificates.
# (See RFC 5280, section 4.2.1.9)
#
# The "tls" profile subsection is used to sign TLS certificate requests;
# the default expiration ("expiry" field) is "8760h", which is 1 year in hours.
#############################################################################
signing:
default:
usage:
- digital signature
expiry: 8760h
profiles:
ca:
usage:
- cert sign
- crl sign
expiry: 43800h
caconstraint:
isca: true
maxpathlen: 0
tls:
usage:
- signing
- key encipherment
- server auth
- client auth
- key agreement
expiry: 8760h
###########################################################################
# Certificate Signing Request (CSR) section.
# This controls the creation of the root CA certificate.
# The expiration for the root CA certificate is configured with the
# "ca.expiry" field below, whose default value is "131400h" which is
# 15 years in hours.
# The pathlength field is used to limit CA certificate hierarchy as described
# in section 4.2.1.9 of RFC 5280.
# Examples:
# 1) No pathlength value means no limit is requested.
# 2) pathlength == 1 means a limit of 1 is requested which is the default for
# a root CA. This means the root CA can issue intermediate CA certificates,
# but these intermediate CAs may not in turn issue other CA certificates
# though they can still issue end entity certificates.
# 3) pathlength == 0 means a limit of 0 is requested;
# this is the default for an intermediate CA, which means it can not issue
# CA certificates though it can still issue end entity certificates.
###########################################################################
csr:
cn: fabric-ca-server
keyrequest:
algo: ecdsa
size: 256
names:
- C: US
ST: "North Carolina"
L:
O: Hyperledger
OU: Fabric
hosts:
- 2f6066770ff3
- localhost
ca:
expiry: 131400h
pathlength: 1
###########################################################################
# Each CA can issue both X509 enrollment certificate as well as Idemix
# Credential. This section specifies configuration for the issuer component
# that is responsible for issuing Idemix credentials.
###########################################################################
idemix:
# Specifies pool size for revocation handles. A revocation handle is an unique identifier of an
# Idemix credential. The issuer will create a pool revocation handles of this specified size. When
# a credential is requested, issuer will get handle from the pool and assign it to the credential.
# Issuer will repopulate the pool with new handles when the last handle in the pool is used.
# A revocation handle and credential revocation information (CRI) are used to create non revocation proof
# by the prover to prove to the verifier that her credential is not revoked.
rhpoolsize: 1000
# The Idemix credential issuance is a two step process. First step is to get a nonce from the issuer
# and second step is send credential request that is constructed using the nonce to the isuser to
# request a credential. This configuration property specifies expiration for the nonces. By default is
# nonces expire after 15 seconds. The value is expressed in the time.Duration format (see https://golang.org/pkg/time/#ParseDuration).
nonceexpiration: 15s
# Specifies interval at which expired nonces are removed from datastore. Default value is 15 minutes.
# The value is expressed in the time.Duration format (see https://golang.org/pkg/time/#ParseDuration)
noncesweepinterval: 15m
#############################################################################
# BCCSP (BlockChain Crypto Service Provider) section is used to select which
# crypto library implementation to use
#############################################################################
bccsp:
default: SW
sw:
hash: SHA2
security: 256
filekeystore:
# The directory used for the software file-based keystore
keystore: msp/keystore
#############################################################################
# Multi CA section
#
# Each Fabric CA server contains one CA by default. This section is used
# to configure multiple CAs in a single server.
#
# 1) --cacount <number-of-CAs>
# Automatically generate <number-of-CAs> non-default CAs. The names of these
# additional CAs are "ca1", "ca2", ... "caN", where "N" is <number-of-CAs>
# This is particularly useful in a development environment to quickly set up
# multiple CAs. Note that, this config option is not applicable to intermediate CA server
# i.e., Fabric CA server that is started with intermediate.parentserver.url config
# option (-u command line option)
#
# 2) --cafiles <CA-config-files>
# For each CA config file in the list, generate a separate signing CA. Each CA
# config file in this list MAY contain all of the same elements as are found in
# the server config file except port, debug, and tls sections.
#
# Examples:
# fabric-ca-server start -b admin:adminpw --cacount 2
#
# fabric-ca-server start -b admin:adminpw --cafiles ca/ca1/fabric-ca-server-config.yaml
# --cafiles ca/ca2/fabric-ca-server-config.yaml
#
#############################################################################
cacount:
cafiles:
#############################################################################
# Intermediate CA section
#
# The relationship between servers and CAs is as follows:
# 1) A single server process may contain or function as one or more CAs.
# This is configured by the "Multi CA section" above.
# 2) Each CA is either a root CA or an intermediate CA.
# 3) Each intermediate CA has a parent CA which is either a root CA or another intermediate CA.
#
# This section pertains to configuration of #2 and #3.
# If the "intermediate.parentserver.url" property is set,
# then this is an intermediate CA with the specified parent
# CA.
#
# parentserver section
# url - The URL of the parent server
# caname - Name of the CA to enroll within the server
#
# enrollment section used to enroll intermediate CA with parent CA
# profile - Name of the signing profile to use in issuing the certificate
# label - Label to use in HSM operations
#
# tls section for secure socket connection
# certfiles - PEM-encoded list of trusted root certificate files
# client:
# certfile - PEM-encoded certificate file for when client authentication
# is enabled on server
# keyfile - PEM-encoded key file for when client authentication
# is enabled on server
#############################################################################
intermediate:
parentserver:
url:
caname:
enrollment:
hosts:
profile:
label:
tls:
certfiles:
client:
certfile:
keyfile: