Hyperledger Fabric CA 유저 가이드

HH·2022년 1월 9일
Hyperledger Fabric CA

Hyperledger Fabric CA

목록 보기
1/7

Hyperledger Fabric CA 유저 가이드

Hyperledger Fabric CA는 Hyperledger Fabric을 위한 인증기관으로, 다음과 같은 기능들을 제공한다:

  • 신원 기재(registration), 또는 사용자 레지스트리로 쓰이는 LDAP와의 연결
  • 등록(enrollment) 인증서 발급
  • 인증서 갱신과 폐지
    Hyperledger Fabric CA는 이 문서에서 추후 설명될 서버와 클라이언트 컴포넌트들로 구성되어있다.

목차

  1. 개요
  2. 시작하기
    1. 사전 요구사항
    2. 설치
    3. Fabric CA CLI 살펴보기
  3. 구성 설정
    1. 파일 경로에 대한 단어
  4. Fabric CA 서버
    1. 서버 초기화하기
    2. 서버 시작하기
    3. 데이터베이스 구성하기
    4. LDAP 구성하기
    5. 클러스터 설정하기
    6. 여러 CA 설정하기
    7. 중간 CA 등록하기
    8. 서버 업그레이드하기
    9. 운영 서비스
  5. Fabric CA 클라이언트
    1. 부트스트랩 신원(identity) 등록하기
    2. 새 신원 기재하기
    3. 피어 신원 등록하기
    4. Identity Mixer 인증서 얻기
    5. Idemix CRI(Certificate Revocation Information; 인증서 폐지 정보) 얻기
    6. 신원 재등록하기
    7. 인증서 또는 신원 취소시키기
    8. CRL(인증서 폐지 목록) 생성하기
    9. 속성 기반 접근 제어
    10. 동적 서버 구성 업데이트
    11. TLS 활성화
    12. 특정 CA 인스턴스에 접근
  6. HSM 구성
    1. 예시
  7. 파일 포맷
    1. Fabric CA 서버의 구성 파일 포맷
    2. Fabric CA 클라이언트의 구성 파일 포맷
  8. 문제 해결

개요


아래 다이어그램은 Hyperledger Fabric CA 서버가 전체 Hyperledger Fabric 아키텍처에 어떻게 부합하는지 설명한다.

Fabric CA 다이어그램

Hyperledger Fabric CA 서버와 상호작용하는 방법은 두 가지가 있다. Hyperledger Fabric CA 클라이언트를 통하거나 Fabric SDK들 중 하나를 통하는 것이다. Hyperledger Fabric CA 서버를 향한 모든 커뮤니케이션은 REST API를 통한다. 이 REST API들에 대한 swagger문서는 fabric-ca/swagger/swagger-fabric-ca.json에서 참조할 수 있다. 이 문서는 swagger 온라인 에디터에서 볼 수 있다.

Hyperledger Fabric CA 클라이언트나 SDK는 Hyperledger Fabric CA 서버 클러스트의 서버에 연결할 수 있다. 이것은 위 다이어그램의 오른쪽 위에 묘사되어 있다. 클라이언트는 fabric-ca-server 클러스터 구성원 중 하나에게 전송되는 트래픽을 로드밸런싱하는 HA 프록시 엔드포인트로 라우팅한다.

클러스터의 모든 Hyperledger Fabric CA 서버는 ID와 인증서를 추적하기 위해 동일한 DB를 공유한다. 만약 LDAP가 구성되면 ID정보는 DB가 아닌 LDAP에 저장된다.

한 서버는 여러 CA를 가질 수 있다. 각 CA는 루트 CA거나 중간 CA이다. 각 중간 CA는 루트 CA이거나 중간 CA인 부모 CA를 가진다.


시작하기


사전 요구사항

  • Go 1.10+ 설치
  • GOPATH 환경 변수가 올바르게 설정되어 있어야 한다
  • libtool과 libtdhl-dev 패키지 설치

Ubuntu에서는 아래 명령어를 따라 libtool dependencies를 설치할 수 있다 : 

sudo apt install libtool libltdl-dev

MacOSX에서는 아래 명령어를 사용할 수 있다 :


brew install libtool

참고 :

Homebrew를 통해 libtool를 다운받았다면 MacOSX에 libtldl-dev를 반드시 설치할 필요가 없다.

libtool에 대한 더 많은 정보를 보려면 https://www.gnu.org/software/libtool를 참고해라.
libltdl-dev에 대한 더 많은 정보를 보려면 https://www.gnu.org/software/libtool/manual/html_node/Using-libltdl.html를 참고해라.


설치


아래 명령어는 fabric-ca-server와 fabric-ca-client바이너리를 $GOPATH/bin에 설치한다. 
go get -u github.com/hyperledger/fabric-ca/cmd/...

참고:

만약 fabric-ca 리포지토리를 이미 다운받았다면, 위 go get 명령을 실행하기 전에 현재 위치가 마스터 브런치인지 확인해야 한다. 만약 아니라면 다음과 같은 오류를 볼 수 있다: 


<gopath>/src/github.com/hyperledger/fabric-ca; git pull --ff-only
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=<remote>/<branch> tlsdoc

package github.com/hyperledger/fabric-ca/cmd/fabric-ca-client: exit status 1

네이티브로 서버 실행

다음 명령어는 fabric-ca-server를 디폴트 설정으로 시작한다.

fabric-ca-server start -b admin:adminpw

-b옵션은 부트스트랩 관리자를 위해 등록 ID와 암호를 제공한다. 이 옵션은 "ldap.enabled" 설정으로 LDAP이 활성화되지 않은 경우에 필요하다.

디폴트 설정 파일은 로컬 디렉토리에 fabric-ca-server-config.yaml라는 이름으로 만들어지고 사용자 정의가 가능하다.


도커를 통한 서버 실행

https://hub.docker.com/r/hyperledger/fabric-ca/tags/ 로 가라.

pull하고자 하는 버전의 fabric-ca 및 아키텍처와 일치하는 태그를 찾아라.

docker-compose.yml 파일을 아래와 같이 만들어라. image 를 앞서 찾은 태그에 맞춰 변경해라.

fabric-ca-server:
  image: hyperledger/fabric-ca:amd64-1.4.7
  container_name: fabric-ca-server
  ports:
    - "7054:7054"
  environment:
    - FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
  volumes:
    - "./fabric-ca-server:/etc/hyperledger/fabric-ca-server"
  command: sh -c 'fabric-ca-server start -b admin:adminpw'

docker-compose.yml 파일과 같은 디렉토리에서 터미널을 열고 아래 명령을 실행해라 : 

# docker-compose up -d

이 명령어는 선택된 fabric-ca 이미지가 존재하지 않는 경우 compose 파일에 fabric-ca 이미지를 pull하고, fabric-ca server의 인스턴스를 시작한다.


도커 이미지 빌딩

아래처럼 Docker Compose를 통해 서버를 빌드하고 시작할 수 있다.

cd $GOPATH/src/github.com/hyperledger/fabric-ca
make docker
cd docker/server
docker-compose up -d

hyperledger/fabric-ca 도커 이미지는 fabric-ca-server와 the fabric-ca-client를 포함하고 있다.

# cd $GOPATH/src/github.com/hyperledger/fabric-ca
# FABRIC_CA_DYNAMIC_LINK=true make docker
# cd docker/server
# docker-compose up -d

Fabric CA CLI 살펴보기

이 섹션에서는 편의를 위해 Fabric CA server와 client의 사용 메시지를 간단히 제공한다. 추가적인 사용 정보는 뒤따르는 세션에서 제공된다.

서버 커맨드 라인

클라이언트 커맨드 라인

string slice들 (list들) 인 커맨드 라인 옵션은 반점으로 구분된 리스트 요소로 지정될 수 있다. 또는 옵션을 여러번 지정할 수도 있다.

예를 들어, host1과 host2를 csr.hosts 옵션으로 지정하려면, --csr.hosts 'host1,host2'나 --csr.hosts host1 --csr.hosts host2를 사용할 수 있다. 전자 형식을 사용할 때는 반점 앞뒤에 공백이 없어야 한다.


구성 설정

Fabric CA는 Fabric CA server와 client에 구성을 설정하는 방법 세 가지를 제공한다. 우선순위는 다음과 같다:

  1. CLI 플래그
  2. 환경변수
  3. 구성 파일

이 문서의 나머지 부분에서는 구성 파일을 바꾸는 방법을 사용할 것이다. 하지만, 구성 파일은 환경변수나 CLI플래그에 의해 오버라이딩 될 수 있다.

예를 들어, 다음과 같은 클라이언트 구성 파일이 있다면 : 

tls:
  # Enable TLS (default: false)
  enabled: false

  # TLS for the client's listenting port (default: false)
  certfiles:
  client:
    certfile: cert.pem
    keyfile:

다음 환경변수가 구성파일의 cert.pem 설정을 오버라이딩 할 수 있다.

export FABRIC_CA_CLIENT_TLS_CLIENT_CERTFILE=cert2.pem

만약 환경변수와 구성파일 모두를 오버라이딩 하고 싶다면 커맨드라인 플래그를 쓸 수 있다.

fabric-ca-client enroll --tls.client.certfile cert3.pem

접두사로 FABRIC_CA_CLIENT 대신 FABRIC_CA_SERVER가 사용되는 것을 제외하면 fabric-ca-server에도 같은 접근이 가능하다.


파일 경로에 대한 단어

Fabric CA 서버와 클라이언트 구성 파일에서 파일 이름을 지정하는 모든 속성은 절대경로와 상대경로를 지원한다. 상대경로는 구성 파일이 위치한 config 디렉토리와 관련이 있다. 예를 들어, 만약 config 디렉토리가 ~/config이고 TLS 섹션이 아래와 같다면, Fabric CA 서버 또는 클라이언트는 ~/config 에서 root.pem파일을 찾을 것이고 ~/config/cert에서 cert.pem 파일을, /abs/path 에서 key.pem 파일을 찾을 것이다.

tls:
  enabled: true
  certfiles:
    - root.pem
  client:
    certfile: certs/cert.pem
    keyfile: /abs/path/key.pem

Fabric CA 서버

이 섹션은 Fabric CA 서버를 설명한다.

Fabric CA 서버를 시작하기 전에 초기화할 수 있다. 초기화를 하면 기본 구성 파일을 생성해 서버를 시작하기 전에 살펴보고 사용자 설정을 정의할 수 있다. Fabric CA의 home directory는 다음에 따라 정해진다:

  • 만약 -home 커맨드 라인 옵션이 설정되어 있다면 그 값을 사용한다.
  • 아니라면, FABRIC_CA_SERVER_HOME 환경변수 값을 사용한다.
  • 아니라면, FABRIC_CA_HOME 환경변수 값을 사용한다.
  • 아니라면, CA_CFG_PATH 환경변수 값을 사용한다.
  • 아니라면, 현재 작업 디렉토리를 사용한다.
    서버 섹션의 남은 부분에서는 FABRIC_CA_HOME환경변수 값을 $HOME/fabric-ca/server로 설정해 사용한다.

서버 초기화하기

다음과 같이 Fabric CA 서버를 초기화할 수 있다 : 

fabric-ca-server init -b admin:adminpw

-b(bootstrap identity) 옵션은 LDAP가 비활성화되어 있을 때 초기화를 위해 필요하다. 최소한 하나의 부트스트랩 ID가 서버를 시작하기 위해 필요하다. 이 ID는 서버 관리자가 된다.

서버 구성 파일은 인증서 서명 요청(Certificate Signing Request; CSR) 섹션을 포함하고 있다. 아래는 샘플 CSR이다.

cn: fabric-ca-server
names:
   - C: US
     ST: "North Carolina"
     L:
     O: Hyperledger
     OU: Fabric
hosts:
  - host1.example.com
  - localhost
ca:
   expiry: 131400h
   pathlength: 1

위의 모든 필드는 fabric-ca-server init 커맨드로 생성된 X.509 서명 키 및 인증서와 연관되어 있다. 이는 서버 구성 파일인 ca.certfile과 ca.keyfile에 대응된다. 필드들에 대한 설명은 다음과 같다 :

  • cn은 Common Name이다.
  • O는 조직명(organization name)이다.
  • OU는 조직 유닛(organizational unit)이다.
  • L은 위치(location) 또는 도시이다.
  • ST는 주(state)이다.
  • C는 국가(country)이다.

만약 CSR에 대한 사용자 정의가 필요하다면, 구성 파일을 사용자 정의하고, ca.certfile 및 ca.keyfile 구성 요소로 지정된 파일들을 삭제하고, fabric-ca-server init -b admin:adminpw 커맨드를 다시 실행해야 한다.

fabric-ca-server init 커맨드는 -u <parent-fabric-ca-server-URL> 옵션이 지정되지 않으면 자체 서명된 CA 인증서를 생성한다. 만약 -u가 지정되면, 서버의 CA 인증서는 부모 CA 서버에 의해 서명된다. 부모 서버에 인증하려면 URL은 반드시 <scheme>://<enrollmentID>:<secret>@<host>:<port> 형식이어야 한다. 여기서 <enrollmentID>와 <secret>은 값이 true로 지정된 hf.IntermediateCA속성에 지정된 신원과 같아야 한다.

또한 fabric-ca-server init 커맨드는 서버의 home 디렉토리에 fabric-ca-server-config.yaml 이라는 디폴트 파일을 만든다.

CA 서버가 사용자가 제공한 CA 서명 인증서 및 키 파일을 사용하게 하려면, ca.certfile와 ca.keyfile에서 참조하는 위치에 각각 파일을 저장해야 한다. 두 파일 모두 PEM으로 인코딩 되어야 하며 암호화되어서는 안된다. 더 자세하게는, CA 인증서 파일 내용은 -----BEGIN CERTIFICATE-----로 시작해야 하고, 키 파일 내용은 -----BEGIN PRIVATE KEY-----로 시작해야 한다. -----BEGIN ENCRYPTED PRIVATE KEY-----로 시작되어서는 안 된다.


알고리즘과 키 사이즈

CSR은 Elliptic Curve (ECDSA) 방식을 지원하는 키와 X.509 인증서를 생성하도록 사용자 정의 될 수 있다. 아래 설정은 prime256v1 커브와 ecdsa-with-SHA256알고리즘을 따르는 Elliptic Curve Digital Signature Algorithm (ECDSA)을 구현한 예이다 :

key:
   algo: ecdsa
   size: 256

알고리즘과 키 사이즈 선택은 보안상의 필요에 따른다.
ECDSA는 아래와 같은 키 사이즈 옵션을 제공한다:

ECDSA key size option


서버 시작하기

서버는 아래와 같이 실행한다 :

fabric-ca-server start -b <admin>:<adminpw>

서버가 앞서 초기화되지 않았다면 처음 실행될 때 자동으로 초기화된다. 초기화 과정 동안, 서버는 ca-cert.pem 과 ca-key.pem 파일, 구성 파일이 존재하지 않는 경우 위 파일들을 생성한다. 서버 초기화 섹션을 참고하라.

Fabric CA 서버가 LDAP으로 생성된 경우를 제외하고, 다른 신원들을 서버에 기재(register)하고 등록(enroll)하기 위해서 서버는 최소한 하나의 미리 기재된(pre-registered) 부트스트랩 신원으로 구성되어야 한다. -b 옵션이 부트스트랩 신원의 이름과 비밀번호를 지정한다.

Fabric CA 서버가 http가 아닌 https에서 수신하려고 하려면 tls.enabled를 true로 설정한다.


보안 경고 :

Fabric CA 서버는 항상 TLS를 활성화 한 채 시작되어야 한다 (tls.enabled를 true로 설정). 이렇게 하지 않으면 서버는 네트워크 트래픽에 접근하려는 공격자에게 취약한 채로 남게 된다.


같은 secret(또는 password)가 등록에 사용될 수 있는 횟수를 제한하기 위해, 구성 파일의 registry.maxenrollments 를 적당한 값으로 설정해야 한다. 만약 이 값을 1로 설정하면 Fabric CA 서버는 특정 등록 ID에 대해 비밀번호가 한 번만 사용될 수 있도록 허용한다. 이 값이 -1인 경우, 서버는 암호가 등록을 위해 재사용 될 수 있는 횟수를 제한하지 않는다. 값이 0인 경우, 서버는 모든 신원의 등록을 비활성화하고 신원 기재도 허용되지 않는다.

이제 서버는 포트 7054에서 수신 대기해야 한다.
클러스터나 LDAP를 사용하는 경우 남은 부분을 스킵하고 Fabric CA 클라이언트 세션으로 넘어갈 수 있다.


데이터베이스 구성하기

이 섹션은 서버가 PostgreSQL이나 MySQL DB와 연결되도록 서버를 구성하는 방법을 설명한다. 디폴트 데이터베이스는 SQLite이고 디폴트 데이터베이스 파일은 서버의 홈 디렉토리 안에 있는 fabric-ca-server.db이다.

Fabric CA는 클러스터 셋업에 다음과 같은 DB 버전을 지원한다 :

  • PostgreSQL : 9.5.5 이상
  • MySQL: 5.7 이상

PostgreSQL

아래 샘플은 PostgreSQL 데이터베이스를 연결하기 위해 서버 구성 파일에 추가될 수 있다.
변수 값을 적절히 설정했는지 확인해야 한다. 데이터베이스명에 허용되는 문자에는 제한이 있다. 아래 Postgres 문서를 참고해라 :
https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS

db:
  type: postgres
  datasource: host=localhost port=5432 user=Username password=Password dbname=fabric_ca sslmode=verify-full

sslmode 설정은 SSL인증 타입을 구성한다. 유효한 값은 다음과 같다 :

모드설명
disableNo SSL
requirealways SSL (검증 건너뛰기)
verify-caalways SSL (서버가 제시한 인증서가 신뢰할 만한 CA에서 서명되었는지 검증)
verify-fullverify-ca와 동일 + 서버 호스트이름이 인증서에 있는 이름과 일치하는지 검증

만약 TLS를 사용한다면 서버 구성 파일의 db.tls 섹션이 지정되어야 한다. SSL 클라이언트 인증이 PostgreSQL 서버에서 활성화되면, 클라이언트 인증서와 키 파일은 db.tls.client섹션에 지정되어야 한다. 다음은 db.tls섹션의 예시이다 : 

db:
  ...
  tls:
      enabled: true
      certfiles:
        - db-server-cert.pem
      client:
            certfile: db-client-cert.pem
            keyfile: db-client-key.pem
  • certfiles : PEM으로 인코딩된 신뢰할만한 루트 인증서 파일
  • certfile , keyfile : PEM으로 인코딩된 인증서와 키 파일들. Fabric CA 서버가 PostgreSQL 서버와 안전하게 커뮤니케이션 하기 위해 사용된다.

PostgreSQL SSL 구성


PostgreSQL server SSL 구성에 대한 기본적인 소개
1. postgresql.conf에서 SSL의 주석을 제거하고 "on"으로 설정한다(SSL=on).
2. PostgreSQL data directory에 인증서와 키 파일을 둔다.

자가 서명된 인증서 생성은 https://www.postgresql.org/docs/9.5/static/ssl-tcp.html 를 보자.

참고: 자가 서명된 인증서는 테스트 목적으로 사용되며, 프로덕션 환경에서는 사용해서는 안된다.


PostgreSQL Server - 클라이언트 인증서 요구

  1. 신뢰하는 인증기관의 인증서를 PostgreSQL data directory의 root.crt 파일에 둔다.

  2. postgresql.conf에서 "ssl_ca_file"가 클라이언트의 루트 인증서(CA cert)를 가리키도록 설정한다.

  3. pg_hba.conf의 관련 hostssl 행에서 clientcert 파라미터를 1로 설정한다.

    PostgreSQL 서버 SSL 구성에 대한 더 많은 정보는 다음 PostgreSQL 문서를 참조하자: https://www.postgresql.org/docs/9.4/static/libpq-ssl.html


MySQL

다음 샘플은 MySQL database 연결을 위해 Fabric CA server 구성 파일에 추가될 수 있다. 값을 적절히 커스터마이징했는지 주의해야 한다. 데이터베이스 이름으로 허용되는 문자에 제한이 있다. 다음 MySQL 문서를 더 많은 정보를 위해 참조하자: https://dev.mysql.com/doc/refman/5.7/en/identifiers.html

MySQL 5.7.X에서는, 서버가 '0000-00-00'를 유효한 date로 허가하는지에 특정 모드가 영향을 미친다. MySQL 서버가 사용하는 모드를 완화해야 할 필요가 있을 수 있다. 서버가 0 date 값을 허용할 수 있어야 하기 때문이다.

my.cnf에서 구성 옵션 sql_mode 를 찾고 만약 NO_ZERO_DATE가 존재한다면 삭제해라. 이후 MySQL 서버를 재시작해야 한다.

사용가능한 다양한 모드들에 대한 설명은 아래 MySQL 문서를 참조하고, 사용 중인 특정 MySQL 버전에 대한 적절한 설정을 선택하자: https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html

db:
  type: mysql
  datasource: root:rootpw@tcp(localhost:3306)/fabric_ca?parseTime=true&tls=custom

MySQL 서버에 TLS를 사용해 접속할 경우 위 PostgreSQL 섹션에서 설명한 db.tls.client 섹션이 필요하다.


MySQL SSL 구성

MySQL 서버 SSL 구성에 대한 기본 소개

  1. 서버를위한 my.cnf 파일을 열거나 생성한다. mysqld 섹션 아래 줄들을 추가하거나 주석 처리를 없앤다. 이는 서버의 키와 인증서, 그리고 root CA 인증서를 가리켜야 한다.

    서버 및 클라이언트 사이드 인증서 생성에 대한 소개: http://dev.mysql.com/doc/refman/5.7/en/creating-ssl-files-using-openssl.html

    mysqld ssl-ca=ca-cert.pem ssl-cert=server-cert.pem ssl-key=server-key.pem

    SSL이 활성화되었는지ㄹ를 확인하기 위해 아래 쿼리를 실행할 수 있다.

    mysql> SHOW GLOBAL VARIABLES LIKE ‘have_%ssl’;

    다음을 볼 수 있다:

    Variable_nameValue
    have_opensslYES
    have_sslYES

  2. 서버사이드 SSL 구성이 완료된 후, 다음 단계는 SSL을 통해 MySQL 서버에 접근가능한 권한을 가진 유저를 만드는 것이다. 이를 위해 MySQL 서버에 로그인하고 다음을 타이핑한다:

    mysql> GRANT ALL PRIVILEGES ON . TO ‘ssluser’@’%’ IDENTIFIED BY ‘password’ REQUIRE SSL; mysql> FLUSH PRIVILEGES;

    유저가 서버에 액세스할 특정 IP주서를 지정하려면 '%'를 특정 IP 주소로 변경한다.

MySQL Server - 클라이언트 인증서 요구
안전한 연결을 위한 옵션은 서버사이드에서 사용된 것과 유사하다.

  • ssl-ca는 인증 기관 인증서를 식별한다. 이 옵션은, 만약 사용된다면, 반드시 서버에 의해 사용되는 것과 동일한 인증서를 지정해야 한다.
  • ssl-cert는 MySQL 서버의 인증서를 식별한다.
  • ssl-key는 MySQL 서버의 개인키를 식별한다.

특별한 암호화 요구가 없고 REQUIRE SSL 옵션을 포함한 GRANT statement를 사용해 생성된 계정으로 커넥트하고 싶다고 가정해 보자. 추천되는 안전한 연결 옵션(secure-connection options) 설정은 MySQL 서버를 최소한 –ssl-cert 및 –ssl-key 옵션과 함께 시작하는 것이다. 그리고 서버 구성 파일에서 db.tls.certfiles 속성을 설정하고, fabric CA 서버를 시작한다.

클라이언트 인증서 또한 지정하도록 요구하려면, REQUIRE X509 옵션을 사용해 계정을 생성한다. 그리고 클라이언트 또한 반드시 적절한 클라이언트 키와 인증서 파일을 지정해야 한다. 그렇지 않으면 MySQL 서버가 연결을 거부할 것이다. 클라이언트 키와 인증서 파일을 Fabric CA 서버를 위해 지정하기 위해서는 db.tls.client.certfile 및 db.tls.client.keyfile 구성 속성을 설정해야 한다.


LDAP 구성하기

Fabric CA 서버는 LDAP 서버를 읽어오도록 구성할 수 있다.

구체적으로, LDAP 서버와 연결된 Fabric CA 서버는 다음을 할 수 있다:

  • 등록 이전에 신원을 인증한다
  • 권한 부여에 사용된 신원의 속성값을 재인한다.

Fabric CA 서버 구성 파일의 LDAP 섹션을 서버가 LDAP 서버에 연결하도록 구성하기 위해 수정한다.

ldap:
   # Enables or disables the LDAP client (default: false)
   enabled: false
   # The URL of the LDAP server
   url: <scheme>://<adminDN>:<adminPassword>@<host>:<port>/<base>
   userfilter: <filter>
   attribute:
      # 'names' is an array of strings that identify the specific attributes
      # which are requested from the LDAP server.
      names: <LDAPAttrs>
      # The 'converters' section is used to convert LDAP attribute values
      # to fabric CA attribute values.
      #
      # 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 expression
      # evaluates to true).
      #    converters:
      #       - name: hf.Revoker
      #         value: attr("uid") =~ "revoker*"
      #
      # As another example, assume a user has an LDAP attribute named
      # 'member' which has multiple values of "dn1", "dn2", and "dn3".
      # Further assume the following configuration.
      #    converters:
      #       - name: myAttr
      #         value: map(attr("member"),"groups")
      #    maps:
      #       groups:
      #          - name: dn1
      #            value: client
      #          - name: dn2
      #            value: peer
      # The value of the user's 'myAttr' attribute is then computed to be
      # "client,peer,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 "client" and "dn2" with "peer".
      converters:
        - name: <fcaAttrName>
          value: <fcaExpr>
      maps:
        <mapName>:
            - name: <from>
              value: <to>
  • scheme은 ldap 또는 ldaps 이다.
  • adminDN 은 관리자의 고유 이름(distinquished name)이다.
  • pass 는 관리자 비밀번호이다.
  • host 는 LDAP 서버의 호스트네임 또는 IP 주소이다.
  • port 는 포트 넘버로, 선택사항이다. 기본값은 ldap 는 389, ldaps 는 636이다.
  • base 는 검색에 사용하기 위한 LDAP 트리의 루트로, 선택사항이다.
  • filter 는 로그인 유저 이름을 고유 이름으로 변환하기 위해 검색할 때 사용하는 필터이다. 예를 들어, (uid=%s) 값은 로그인 유저 이름이 값인 uid 속성값을 가지고 LDAP 엔트리를 검색한다. 유사하게, (email=%s)는 이메일 주소로 로그인할 때 사용된다.
  • LDAPAttrs 은 사용자를 대신하여 LDAP 서버에서 요청할 LDAP 속성 이름 배열이다.
  • attribute.converters 섹션은 LDAP 속성을 fabric CA 속성으로 변환하기 위해 사용된다. fcaAttrName은 fabric CA 속성 이름이고, fcaExpr 는 평가된 값이 fabric CA 속성에 할당된 표현식이다. 예를 들어, <LDAPAttrs>이 “uid”이고 <fcaAttrName>이 ‘hf.Revoker’이며 <fcaExpr>는 ‘attr(“uid”) =~ “revoker*”’라고 가정해 보자. 이는 "uid"로 명명된 속성이 유저를 대신해 LDAP로부터 요청되었음을 뜻한다. 이제 유저는 유저의 ‘uid’ LDAP속성이 ‘revoker’로 시작될 경우 ‘hf.Revoker’ 속성에 ‘true’ 값을 부여한다. 그렇지 않으면, ‘hf.Revoker’ 속성에 'false' 값을 부여한다.

클러스터 설정하기

Fabric CA 서버들의 클러스터에 로드밸런싱 하기 위해 IP 스프레이어를 사용할 수도 있을 것이다. 이 섹션은 Fabric CA 서버 클러스터로 라우트하기 위해 Haproxy를 설정하는 방법에 대한 예시를 제공한다. 호스트 이름과 포트가 Fabric CA 서버 설정으로 리다이렉트하도록 변경되었는지 확인하자.

haproxy.conf: 

global
      maxconn 4096
      daemon

defaults
      mode http
      maxconn 2000
      timeout connect 5000
      timeout client 50000
      timeout server 50000

listen http-in
      bind *:7054
      balance roundrobin
      server server1 hostname1:port
      server server2 hostname2:port
      server server3 hostname3:port

참고: TLS를 사용할 경우 mode tcp를 사용해야 한다.


여러 CA 설정하기

fabric-ca server는 기본적으로 단일 디폴트 CA로 구성되어 있다. 하지만 추가 CA를 cafiles 이나 cacount 구성 옵션을 이용해 추가할 수 있다. 각 추가 CA는 자신만의 홈 디렉토리를 가진다.

cacount:

cacount 는 X개의 기본 추가 CA를 시작하는 빠른 방법을 제공한다. 홈 디렉토리는 서버 디렉토리의 상대 경로가 된다. 이 옵션을 사용하면 디렉토리 구조는 다음과 같이 된다:

--<Server Home>
  |--ca
    |--ca1
    |--ca2

각 추가 CA는 자신의 홈 디렉토리에 생성된 기본 구성 파일을 가진다. 구성 파일 내에는 고유한 CA 이름이 포함된다.

예를 들어 아래 커맨드는 두 기본 CA 인스턴스를 시작한다:

fabric-ca-server start -b admin:adminpw --cacount 2

cafiles:

cafiles 구성 옵션을 사용하면 절대 경로는 지원되지 않는다. CA 홈 디렉토리는 서버 디렉토리의 상대 경로가 된다.

이 옵션을 사용하기 위해서는 시작될 각 CA의 구성 파일이 이미 생성되고 구성되어 있어야 한다. 각 구성 파일은 반드시 고유의 CA이름과 Common Name (CN)를 가져야 한다. 그렇지 않으면 이름이 반드시 유니크해야 하므로 서버 시작에 실패한다. 이 CA 구성 파일은 기본 CA 구성을 오버라이딩하며 이 구성 파일에서 빠진 옵션은 기본 CA 구성 값으로 대체된다.

우선 순위는 다음과 같다:
1. CA 구성 파일
2. 기본 CA CLI 플래그
3. 기본 CA 환경 변수
4. 기본 CA 구성 파일

구성 파일은 최소한 다음을 포함해야 한다:

ca:
# Name of this CA
name: <CANAME>

csr:
  cn: <COMMONNAME>

디렉토리 구조를 다음과 같이 설정할 수 있다:

--<Server Home>
  |--ca
    |--ca1
      |-- fabric-ca-config.yaml
    |--ca2
      |-- fabric-ca-config.yaml

예를 들어 다음 커맨드는 커스터마이징된 두 CA 인스턴스를 시작한다:

fabric-ca-server start -b admin:adminpw --cafiles ca/ca1/fabric-ca-config.yaml
--cafiles ca/ca2/fabric-ca-config.yaml

중간 CA 등록하기

중간 CA 서명 인증서 생성을 위해 중간 CA는 fabric-ca-client가 CA에 등록하는 방법으로 부모 CA에 등록해야 한다. 이것은 부모 CA의 URL과 등록 ID 및 비밀번호를 지정하기 위해 -u 옵션을 사용한다. 등록 ID에 해당하는 신원은 반드시 hf.IntermediateCA 속성을 가지고 true값을 가져야 한다. 발행된 인증서의 CN (or Common Name)은 등록 ID로 설정되어야 한다. 중간 CA가 명시적으로 CN 값을 지정할 경우 오류가 발생한다.

fabric-ca-server start -b admin:adminpw -u http://<enrollmentID>:<secret>@<parentserver>:<parentport>

다른 중간 CA 플래그는 패브릭 CA 서버의 구성 파일 포맷 섹션을 참고하자.


서버 업그레이드하기

Fabric CA client가 업그레이드되기 전에 Fabric CA server가 업그레이드 되어야 한다. 업그레이드 이전에 현재 데이터베이스를 백업하는 것을 권장한다:

  • sqlite3을 사용할 경우 현재 데이터베이스 파일을 백업한다. 기본값으로 fabric-ca-server.db라고 이름지어진 파일이다.

  • 다른 데이터베이스 타입은 적절한 백업/복제 메커니즘을 사용한다.

Fabric CA server 단일 인스턴스를 업데이트하기 위해서는 다음 단계를 사용한다:

  1. fabric-ca-server 프로세스를 중지한다.
  2. 현재 데이터베이스를 백업했는지 확인한다.
  3. 이전 fabric-ca-server 바이너리를 업그레이드 된 버전으로 대체한다.
  4. fabric-ca-server 프로세스를 런칭한다.
  5. fabric-ca-server 프로세스가 사용 가능한지 아래 커맨드에서 <host>를 서버가 시작될 호스트 이름으로 바꾸어서 검증한다:
fabric-ca-client getcainfo -u http://<host>:7054

클러스터 업그레이드:

MySQL 또는 Postgres 데이터베이스를 사용하는 fabric-ca-server 인스턴스 클러스터를 업그레이드 하기 위해 다음 절차를 수행한다. host1 및 host2에 있는 두 fabric-ca-server 클러스터 멤버를 haproxy로 로드밸런싱한다고 가정한다. 둘 모두 7054 포트를 수신대기한다. 이 절차 후에 업그레이드된 클러스터 멤버들을 host3, host4에 각각 로드밸런싱한다. 둘 모두 7054 포트를 수신대기한다.

haproxy stats를 사용해 변화를 모니터링하기 위해 statistics collection을 활성화한다. 아래 라인을 haproxy 구성 파일의 global 섹션에 추가한다:

stats socket /var/run/haproxy.sock mode 666 level operator
stats timeout 2m

변화를 반영하기 위해 haproxy를 재시작한다:

# haproxy -f <configfile> -st $(pgrep haproxy)

haproxy “show stat” 커맨드에서 요약 정보를 보여주기 위해 아래 펑션으로 반환되는 풍부한 양의 CSV 데이터를 파싱한다:

haProxyShowStats() {
   echo "show stat" | nc -U /var/run/haproxy.sock |sed '1s/^# *//'|
      awk -F',' -v fmt="%4s %12s %10s %6s %6s %4s %4s\n" '
         { if (NR==1) for (i=1;i<=NF;i++) f[tolower($i)]=i }
         { printf fmt, $f["sid"],$f["pxname"],$f["svname"],$f["status"],
                       $f["weight"],$f["act"],$f["bck"] }'
}
  1. 처음에 haproxy 구성 파일은 다음과 비슷하다:
server server1 host1:7054 check
server server2 host2:7054 check

구성 파일을 다음과 같이 바꾼다:

server server1 host1:7054 check backup
server server2 host2:7054 check backup
server server3 host3:7054 check
server server4 host4:7054 check
  1. haproxy 다음과 같이 새 구성으로 재시작한다:
haproxy -f <configfile> -st $(pgrep haproxy)

haProxyShowStats는 두 활성화된 옛 버전 백업 서버와 두 (아직 시작 전인) 업그레이드 된 서버를 가진 변경된 구성을 보여준다:

sid   pxname      svname  status  weig  act  bck
  1   fabric-cas  server3   DOWN     1    1    0
  2   fabric-cas  server4   DOWN     1    1    0
  3   fabric-cas  server1     UP     1    0    1
  4   fabric-cas  server2     UP     1    0    1
  1. fabric-ca-server의 업그레이드 된 바이너리를 host3과 host4에 설치한다. 이 새로 업그레이드 된 서버는 host1과 host2에 있는 이전 서버와 동일한 데이터베이스를 사용하도록 구성해야 한다. 업그레이드 된 서버를 시작하기 전에, 데이터베이스는 자동으로 마이그레이션 된다. haproxy는 업그레이드 된 서버로 모든 새 트래픽을 전달한다. 백업 서버로 구성되지 않았기 때문이다. fabric-ca-client getcainfo 커맨드를 사용해서 진행 전에 클러스터가 여전히 올바르게 기능하고 있는지 검증한다. 또한 haProxyShowStats는 모든 서버가 활성 상태임을 다음과 같이 보여주어야 한다: 
sid   pxname      svname  status  weig  act  bck
  1   fabric-cas  server3    UP     1    1    0
  2   fabric-cas  server4    UP     1    1    0
  3   fabric-cas  server1    UP     1    0    1
  4   fabric-cas  server2    UP     1    0    1
  1. 오래된 서버들을 중지시킨다. 진행 전에 fabric-ca-client getcainfo로 새 클러스터가 여전히 올바르게 동작하는지 검증한다. 그리고 오래된 서버 백업 구성을 haproxy 구성 파일로부터 제거한다. 이제 다음과 같이 보이게 된다:
server server3 host3:7054 check
server server4 host4:7054 check
  1. haproxy 를 다음과 같이 새 설정으로 재시작한다:
haproxy -f <configfile> -st $(pgrep haproxy)

haProxyShowStats는 이제 새 버전으로 업그레이드 된 두 활성화된 서버를 가진 수정된 구성을 반영한다:

sid   pxname      svname  status  weig  act  bck
  1   fabric-cas  server3   UP       1    1    0
  2   fabric-cas  server4   UP       1    1    0

운영 서비스


CA Server는 RESTful "운영(operations)" API를 제공하는 HTTP 서버를 호스트한다. 이 API들은 네트워크 관리자나 유저가 아닌 운영자에 의해 사용되도록 의도되엇다.

API는 다음 케이퍼빌리티들을 노출한다:

  • 운영 매트릭(operational metrics)의 Prometheus target (구성될 경우)

운영 서비스 구성

운영 서비스 구성에는 두 가지 필수적인 부분이 있다:

수신을 위한 address 와 port 이다. TLS 인증서와 키는 인증과 암호화에 사용된다. 이 인증서들은 분리되고 특정한 목적을 위해 사용되는 CA들에 의해 생성되어야 한다. 모든 채널의 모든 조직의 인증서를 생성하는 CA를 사용하지 마라.

CA 서버는 서버의 구성 파일의 operations 섹션에서 구성될 수 있다:

operations:
  # host and port for the operations server
  listenAddress: 127.0.0.1:9443

  # TLS configuration for the operations endpoint
  tls:
    # TLS enabled
    enabled: true

    # path to PEM encoded server certificate for the operations server
    cert:
      file: tls/server.crt

    # path to PEM encoded server key for the operations server
    key:
      file: tls/server.key

    # require client certificate authentication to access all resources
    clientAuthRequired: false

    # paths to PEM encoded ca certificates to trust for client authentication
    clientRootCAs:
      files: []

listenAddress 키는 operation server를 리스닝하는 호스트와 포트를 정의한다. 서버가 모든 주소를 리스닝해야 한다면 호스트 부분이 생략될 수 있다.

tls 섹션은 운영 서비스에서 TLS가 활성화되는지 여부, 서비스의 인증서와 개인키 위치, 클라이언트 인증에 신뢰받는 인증 기관 루트 인증서의 위치를 가리킨다. clientAuthRequired가 true일 경우 클라이언트는 권한 인증을 위한 인증서를 제공해야 한다.


운영 보안

운영 서비스는 운영에 초점을 맞추고 있으며 패브릭 네트워크와 의도적으로 관련되어 있지 않으므로 접근 제어에 MSP를 사용하지 않는다. 대신에 운영 서비스는 클라이언트 인증서 인증을 사용한 상호 TLS에 전적으로 의존하고 있다.

프로덕션 환경에서 clientAuthRequired를 true로 설정해 상호 TLS를 활성화하는 것이 추천된다. 이 구성에서 클라이언트는 인증을 위한 유효한 인증서를 필수로 제공해야 한다. 클라이언트가 인증서를 공급하지 않거나 클라이언트의 인증서를 서비스가 검증하지 못할 경우 리퀘스트는 거부된다. clientAuthRequired가 false로 지정될 경우 클라이언트는 인증서를 제공할 필요가 없다. 하지만 서비스는 인증서를 검증할 수 없으므로 리퀘스트가 거부된다.

TLS가 비활성화되면 검증은 우회되고 어떤 클라이언트이든 운영 엔드포인트에 커넥트해 API를 사용할 수 있다.

메트릭

Fabric CA는 시스템 동작에 대한 인사이트를 제공한다. 운영자와 관리자는 이 정보를 사용해 시스템이 시간에 따라 어떻게 작동하는지 잘 이해할 수 있다.

메트릭 구성

Fabric CA는 메트릭을 노출하는 두 가지 방법을 제공한다: 프로메테우스에 기반한 풀 모델(pull model)과 StatsD에 기반한 푸시 모델(push model)이다.

프로메테우스(Prometheus)

일반적인 프로메테우스 배포는 계측 대상에 의해 노출된 HTTP 엔드포인트에 요청함으로써 메트릭을 스크랩한다. 프로메테우스가 메트릭 요청을 담당하므로 풀 모델로 간주된다.

구성되면 Fabric CA Server는 운영 서비스에 /metrics 리소스를 제공한다. 프로메테우스 활성화를 위해서는 서버의 구성 파일에 provider 값을 prometheus로 설정한다.

metrics:
  provider: prometheus

StatsD

StatsD는 단순 통계 집계 데몬(simple statistics aggregation daemon)이다. 메트릭은 수집되고 집계되는 statsd 데몬으로 전송되고, 시각화 및 알림을 위해 백엔트로 푸시된다. 이 모델은 메트릭 데이터를 StatsD로 보내는계측 프로세스를 필요로 한다. 따라서 이것은 푸시 시스템으로 간주된다.

CA Server는 서버 구성 파일의 metrics 섹션 metrics provider를 statsd로 설정하여 메트릭을 StatsD로 보내도록 구성할 수 있다. statsd 하위 섹션은 StatsD 데몬의 주소, 사용하는 네트워크 타입(tcp 또는 udp), 그리고 얼마나 자주 메트릭을 전송하는지를 구성해야 한다. 선택적 prefix는 메트릭 소스를 구분할 수 있도록 지정할 수 있다. 예를 들어 서로 다른 서버로부터 오는 구분되는 메트릭을 구분할 수 있다. 이것은 모든 생성되는 메트릭 앞에 추가된다. 

metrics:
  provider: statsd
  statsd:
    network: udp
    address: 127.0.0.1:8125
    writeInterval: 10s
    prefix: server-0

생성되는 다른 메트릭을 보려면 메트릭 레퍼런스를 확인하자.

Fabric CA 클라이언트

이 섹션은 fabric-ca-client 커맨드 사용법을 설명한다.

패브릭 CA 클라이언트 home 디렉토리는 아래와 같이 정해진다 :

  • -home 커맨드 라인 옵션이 설정되면, 그 값을 사용한다.
  • 설정되지 않았다면, FABRIC_CA_CLIENT_HOME 환경변수 값을 사용한다.
  • 설정되지 않았다면, FABRIC_CA_HOME 환경변수 값을 사용한다.
  • 설정되지 않았다면, CA_CFG_PATH 환경변수 값을 사용한다.
  • 설정되지 않았다면, $HOME/.fabric-ca-client 를 사용한다.

아래 설명은 클라이언트 홈 디렉토리에 클라이언트 구성 파일이 있다고 전제한다.


부트스트랩 신원(identity) 등록하기

먼저, 필요하다면 클라이언트 구성 파일을 CSR(Certificate Signing Request; 인증서 서명 요청) 섹션을 사용자정의설정으로 변경해야 한다. csr.cn 필드를 반드시 부트스트랩 신원 ID로 설정해야 한다. 디폴트 CSR 값은 다음과 같다 : 

csr:
  cn: <<enrollment ID>>
  key:
    algo: ecdsa
    size: 256
  names:
    - C: US
      ST: North Carolina
      L:
      O: Hyperledger Fabric
      OU: Fabric CA
  hosts:
   - <<hostname of the fabric-ca-client>>
  ca:
    pathlen:
    pathlenzero:
    expiry:

이 필드에 대한 설명은 서버 초기화하기 토픽의 CSR필드를 참고해라.

그리고 신원을 등록하기 위해 fabric-ca-client enroll 커맨드를 실행해라. 예를 들어, 아래 커맨드는 7054 포트에서 로컬로 실행되는 패브릭 CA 서버를 호출함으로써 ID가 admin이고 비밀번호가 adminpw인 신원을 등록한다. 

export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client enroll -u http://admin:adminpw@localhost:7054

enroll 커맨드는 enrollment certificate(ECert)를 저장한다. 이것은 패브릭 CA 클라이언트의 msp 디렉토리의 하위 디렉토리에 상응하는 개인키와 CA 인증서 체인 PEM 파일로 저장된다. PEM 파일이 저장된 위치를 가리키는 메시지를 확인할 수 있다.


새 신원 기재하기

기재 요청(register request)를 수행하는 신원은 이미 등록되어 있으면서 새로 기재되는 신원 타입을 기재할 수 있는 권한도 가지고 있어야 한다.

구체적으로, 기재가 진행되는 동안 패브릭 CA 서버에 의해 세가지 인증 확인이 만들어진다:

  1. registrar(invoker; 기재를 수행하는 신원)은 쉼표로 구분된 값 목록이 있는 hf.Registrar.Roles 속성을 가져야 한다. 이 값들 중 하나는 새로 기재 중인 신원의 타입과 동일해야 한다. 예를 들어, registrar가 가진 hf.Registrar.Roles 속성이 peer라는 값을 가진다면, 이 registrar는 peer 타입의 신원을 기재할 수 있지만 client, admin, 또는 orderer 는 기재할 수 없다.

  2. 레지스트라의 소속은 레지스트되는 아이덴티티의 소속과 같거나, 레지스트되는 아이덴티티의 소속의 접두사여야 한다. 예를 들어, a.b라는 소속을 가진 레지스트라는 a.b.c 소속을 가진 아이덴티티를 기재할 수 있지만, a.c 소속을 가진 아이덴티티를 기재하지는 못한다. root 소속이 아이덴티티에 필요한 경우, 소속 요청은 .이어야 하며 레지스트라도 root 소속을 가지고 있어야 한다. 기재 요청에 소속이 지정되지 않을 경우, 레지스트라의 소속이 기재되는 아이덴티티에 부여된다.

  3. 레지스트라는 아래 조건이 모두 만족된다면 속성을 가진 아이덴티티를 기재할 수 있다.

    • 레지스트라가 해당 속성을 소유하고 있고 hf.Registrar.Attributes 속성 값의 한 부분일 때, 접두사 hf.가 있는 패브릭 CA 예약 속성을 기재할 수 있다. 그 속성이 list라면 기재되는 속성의 값은 레지스트라가 가진 값과 같거나 그 하위 집합이어야 한다. 속성이 boolean이라면 레지스트라의 해당 속성 값이 true일 때만 속성을 기재할 수 있다.

    • 사용자 정의 속성(i.e. 이름이 hf.로 시작되지 않는 속성)기재는 레지스트라가 해당 속성이나 패턴을 hf.Registar.Attributes 속성 값으로 가져야 가능하다. 지원되는 패턴은 *로 끝나는 string 뿐이다. 예를 들어, a.b.*는 a.b.로 시작되는 모든 속성 이름과 매칭되는 패턴이다. 또, 레지스트라가 hf.Registrar.Attributes=orgAdmin을 가졌다면 레지스트라가 신원에 더하거나 제거할 수 있는 속성은 orgAdmin 뿐이다.

    • 요청된 속성 이름이 hf.Registrar.Attributes라면, 이 속성에 대해 요청된 값이 레지스트라의 hf.Registrar.Attributes 속성 값과 같거나 그 하위집합인지 확인하기 위해 추가 검사가 이루어진다. 결과가 true이기 위해서는 각 요청된 값이 레지스트라의 hf.Registrar.Attributes 속성 값과 매치되어야 한다. 예를 들어, 레지스트라의 값이 'a.b.*, x.y.z' 이고 요청된 값이 'a.b.c, x.y.z'일 경우, ‘a.b.c’가 ‘a.b.*’ 와 매칭되고 ‘x.y.z’가 ‘x.y.z’와 매칭되므로 유효하다.

예제:

유효한 시나리오들:

  1. 레지스트라가 hf.Registrar.Attributes = a.b.*, x.y.z 속성을 가지고 기재하려는 속성이 a.b.c인 경우, a.b.c가 a.b.*와 매치되어서 유효하다.

  2. 레지스트라가 hf.Registrar.Attributes = a.b.*, x.y.z 를 가지고 기재하려는 속성이 x.y.z인 경우, x.y.z가 x.y.z와 매치되어서 유효하다.

  3. 레지스트라가 hf.Registrar.Attributes = a.b.*, x.y.z 를 가지고 기재하려는 속성이 a.b.c, x.y.z인 경우, a.b.c가 a.b.*와 매치되고 x.y.z가 x.y.z와 매치되어서 유효하다.

  4. 레지스트라가 hf.Registrar.Roles = peer,client,admin,orderer 속성을 가지고 요청된 속성 값이 peer, peer,client,admin,orderer, 또는 client,admin인 경우, 요청된 값이 레지스트라의 값과 같거나 하위집합이기 때문에 유효하다.

유효하지 않은 시나리오:

  1. 레지스트라가 hf.Registrar.Attributes = a.b.*, x.y.z 속성을 가지고 기재하려는 속성이 hf.Registar.Attributes = a.b.c, x.y.*인 경우, x.y.*는 레지스트라가 가진 패턴이 아니기 때문에 유효하지 않다. x.y.*는 x.y.z의 상위집합이다.

  2. 레지스트라가 hf.Registrar.Attributes = a.b.*, x.y.z 속성을 가지고 기재하려는 속성이 hf.Registar.Attributes = a.b.c, x.y.z, attr1일 경우, 레지스트라의 hf.Registrar.Attributes가 attr1를 포함하고 있지 않기 때문에 유효하지 않다.

  3. 레지스트라가 hf.Registrar.Attributes = a.b.*, x.y.z 속성을 가지고 기재하려는 속성이 hf.Registar.Attributes = a.b.인 경우, a.b는 a.b.*에 포함되지 않으므로 유효하지 않다.

  4. 레지스트라가 hf.Registrar.Attributes = a.b.*, x.y.z 속성을 가지고 기재하려는 속성이 hf.Registar.Attributes = x.y인 경우, 유효하지 않다.

  5. 레지스트라가 hf.Registrar.Roles = peer 속성을 가지고, 요청된 속성값은 peer,client인 경우, 레지스트라는 client role을 가지고 있지 않으므로 유효하지 않다.

  6. 레지스트라가 hf.Revoker = false 속성을 가지고, 요청된 속성값은 true인 경우, hf.Revoker이 boolean이면서 레지스트라 값은 true가 아니므로 유효하지 않다.

아래 표는 아이덴티티에 기재 가능한 속성 목록이다. 속성의 이름은 대소문자를 구별한다.

이름타입설명
hf.Registrar.RolesList레지스트라가 관리할 수 있는 역할 목록
hf.Registrar.DelegateRolesList레지스트라가 기재되는 아이덴티티(registree)의 hf.Registrar.Roles 속성으로 줄 수 있는 역할 목록
hf.Registrar.AttributesList레지스트라가 기재할 수 있는 속성 목록
hf.GenCRLBooleantrue라면 아이덴티티가 CRL을 생성할 수 있다.
hf.RevokerBooleantrue라면 아이덴티티가 아이덴티티와 인증서를 취소할 수 있다.
hf.AffiliationMgrBooleantrue라면 아이덴티티가 소속을 관리할 수 있다.
hf.IntermediateCABooleantrue라면 아이덴티티가 중간 CA로 등록할 수 있다.

주의 : 아이덴티티를 기재할 때, 속성 이름과 값 배열을 지정한다. 이 배열이 같은 이름을 가진 여러 배열 element를 지정하면, 마지막 element만 현재 사용된다. 다른 말로, 다중 값을 가진 속성(multi-valued attributes)은 지원되지 않는다.

아래 커맨드는 admin 아이덴티티의 인증서를 사용해 등록 ID admin2와 소속 org1.department1, hf.Revoker 속성에 true값, 그리고 admin속성에 true 값을 가진 새 아이덴티티를 기재한다. :ecert 접미사는 기본적으로 admin 속성과 그 값이 아이덴티티의 등록 인증서에 삽입되어 액세스 컨트롤 결정을 내릴 때 사용될 수 있음을 의미한다.

export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client register --id.name admin2 --id.affiliation org1.department1 --id.attrs 'hf.Revoker=true,admin=true:ecert'

password, 또는 enrollment secret이 인쇄된다. 이 비밀번호는 아이덴티티를 등록하기 위해 요구된다. 이것은 관리자가 아이덴티티를 기재하고, enrollment ID과 secret을 다른 사람에게 주어서 아이덴티티를 등록할 수 있도록 허가한다.

다중 속성은 –id.attrs 플래그의 부분으로 지정된다. 플래그의 각 속성은 반점으로 나누어진다. 반점을 포함한 속성 값을 지정하기 위해서는 속성이 큰따옴표로 캡슐화되어야 한다. 아래 예시를 보자.

fabric-ca-client register -d --id.name admin2 --id.affiliation org1.department1 --id.attrs '"hf.Registrar.Roles=peer,client",hf.Revoker=true'

또는

fabric-ca-client register -d --id.name admin2 --id.affiliation org1.department1 --id.attrs '"hf.Registrar.Roles=peer,client"' --id.attrs hf.Revoker=true

register 커맨드에서 사용되는 필드들의 디폴트 값을 클라이언트의 구성 파일을 편집함으로써 지정할 수 있다. 예를 들어, 아래 필드를 포함한 구성 파일을 상상해 보자 : 

id:
  name:
  type: client
  affiliation: org1.department1
  maxenrollments: -1
  attributes:
    - name: hf.Revoker
      value: true
    - name: anotherAttrName
      value: anotherAttrValue

아래 커맨드는 커맨드 라인 값을 받아 admin3라는 enrollment ID를 가진 새 아이덴티티를 기재한다. 하지만 나머지 값은 구성 파일에서 가져와 아이덴티티 타입 : client, 소속: org1.department1, 두 속성: hf.Revoker와 anotherAttrName을 가진다. 

export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client register --id.name admin3

여러 속성을 가진 아이덴티티를 기재하기 위해서는 모든 속성 이름과 값을 구성 파일에서 지정해주어야 한다.

maxenrollments를 0으로 설정하거나 구성에서 제외한 채 내버려두면 아이덴티티가 CA의 최대 등록 값을 사용하도록 등록된다. 기재되는 아이덴티티의 최대 등록 값은 CA의 최대 등록 값을 초과할 수 없다. 예를 들어, CA의 최대 등록 값이 5라면 새 아이덴티티는 5와 같거나 작아야 한다. -1(무제한 등록)로 지정할 수도 없다.

다음으로, 다음 섹션에서 피어를 등록하기 위해 사용될 피어 아이덴티티를 기재해 보자. 아래 커맨드는 peer1 아이덴티티를 기재한다. 아래 비밀번호를 그대로 사용하지 말고 다른 비밀번호를 지정해야 한다. 

export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client register --id.name peer1 --id.type peer --id.affiliation org1.department1 --id.secret peer1pw

소속은 서버 구성 파일에서 지정되는 non-leaf affiliations를 제외하면 대소문자를 구별한다. (non-leaf affiliations는 모두 소문자로 저장된다). 예를 들어, 서버 구성 파일의 소속 섹션이 다음과 같다면 : 

affiliations:
  BU1:
    Department1:
      - Team1
  BU2:
    - Department2
    - Department3

BU1, Department1, BU2는 소문자로 저장된다. 패브릭 CA가 구성을 읽기 위해 Viper를 사용하기 때문이다. Viper는 map key를 대소문자 구분 없이 취급하고, 소문자 값을 반환한다. Team1 소속의 아이덴티티를 등록하기 위해, bu1.department1.Team1가 –id.affiliation 플러그에 아래와 같이 지정되어야 한다 : 

export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client register --id.name client1 --id.type client --id.affiliation bu1.department1.Team1

피어 신원 등록하기

이제 피어 아이덴티티가 성공적으로 기재되었다. 이 피어를 주어진 enrollment ID와 secret(i.e. 앞 섹션의 password)으로 등록해야 한다. -M 옵션을 사용해 하이퍼레저 패브릭 MSP(Membership Service Provider; 멤버쉽 서비스 공급자) 디렉토리 구조를 채우는 방법을 보여줄 것이다. 이 점만 제외하면 이것은 부트스트랩 아이덴티티를 등록하는 것과 유사하다.

아래 커맨드는 peer1을 등록한다. -M 옵션의 값을 실제 피어의 MSP 디렉토리(피어의 core.yaml 파일에 mspConfigPath로 설정됨)로 반드시 바꿔야 한다. 

export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/peer1
fabric-ca-client enroll -u http://peer1:peer1pw@localhost:7054 -M $FABRIC_CA_CLIENT_HOME/msp

MSP 디렉토리 경로가 오더러의 orderer.yaml 파일에 지정된 LocalMSPDir인 점을 제외하면 오더러 등록 방법도 같다.

fabric-ca-server에 의해 발행된 모든 등록 인증서는 아래와 같은 조직 유닛(OUs)를 가진다 :

  1. OU 계층의 root는 아이덴티티 타입과 같다.
  2. 아이덴티티 소속의 각 컴포넌트에 대해 OU가 추가된다.

예를 들어, 아이덴티티 타입이 peer이고 소속이 department1.team1라면 아이덴티티의 OU 계층(leaf부터 root로)은 OU=team1, OU=department1, OU=peer이다.


Identity Mixer 자격 증명 얻기

Identity Mixer (Idemix)는 개인정보 보호 인증 및 인증된 속성 전송을 위한 암호화 프로토콜 수트이다. Idemix를 사용하면 클라이언트가 발행기관(CA) 없이 검증자(verifiers)를 이용해 인증할 수 있고, verifier가 요구하는 속성만을 선택적으로 드러낼 수 있다. 이러한 기능들은 트랜잭션 간 연결 없이 가능하다.

패브릭 CA 서버는 X509 인증서 외에도 Idemix 인증서를 발행할 수 있다. /api/v1/idemix/credential API 엔드포인트로 요청(request)를 전송해 Idemix 인증서를 요청할 수 있다. 다른 패브릭 CA 서버 API 엔드포인트에 대한 정보를 얻으려면, swagger-fabric-ca.json을 참고해라.

Idemix 인증서 발급은 두 단계를 거친다. 처음으로, 임시값(nonce)와 CA의 Idemix 공개키를 얻기 위해 /api/v1/idemix/credential API 엔드포인트로 body가 비어있는 리퀘스트를 보낸다. 두번째로, nonce와 Idemix 공개키를 사용해 인증서 리퀘스트를 만들고, 인증서 리퀘스트를 바디에 포함한 다른 리퀘스트를 /api/v1/idemix/credential API 엔드포인트로 보낸다. 이것은 Idemix 인증서,
인증서 폐지 정보(CRI; Credential Revocation Information), 그리고 속성 이름과 값을 얻기 위해서이다. 현재, 세가지 속성이 지원된다 :

  • OU - 아이덴티티의 조직 유닛. 이 속성의 값은 아이덴티티의 소속으로 설정된다. 예를 들어, 아이덴티티의 소속이 dept1.unit1라면 OU 속성은 dept1.unit1으로 설정된다.

  • IsAdmin - 아이덴티티가 관리자인지 아닌지를 나타낸다. 이 속성 값은 isAdmin registration 속성 값으로 설정된다.

  • EnrollmentID - 아이덴티티의 enrollment ID

    Idemix 자격 증명을 얻기 위한 프로세스의 참조 구현은 https://github.com/hyperledger/fabric-ca/blob/master/lib/client.go 의 handleIdemixEnroll 함수를 참고할 수 있다.

    /api/v1/idemix/credential API 엔드포인트는 기본 및 토큰 인증 헤더를 모두 사용한다. 기본 인증 헤더는 유저의 registration ID와 비밀번호를 포함해야 한다. 아이덴티티가 이미 X509 등록 인증서를 가지고 있다면 토큰 인증 헤더를 만드는 데 사용할 수 있다.

    Hyperledger Fabric은 클라이언트가 X509와 Idemix 자격 증명을 사용해 트랜젝션에 서명할 수 있도록 지원한다. 하지만 피어와 오더러 아이덴티티를 위해서는 X509 인증서만 지원한다. 앞서와 같이, 애플리케이션은 Fabric SDK를 사용해 Fabric CA server에 리퀘스트를 보낼 수 있다. SDK는 인증 헤더 생성, 리퀘스트 페이로드 생성, 응답 처리와 관련된 복잡성을 숨긴다.


Idemix CRI(Certificate Revocation Information; 인증서 폐지 정보) 얻기


Idemix CRI (Credential Revocation Information; 인증서 폐지 정보)는 X509 CRL (Certificate Revocation List; 인증서 폐지 목록)과 목적 면에서 유사하고, 그 목적인 먼저 발행된 것을 폐지하는 것이다. 하지만, 여기에는 몇 가지 차이점이 있다.

X509에서 발행인은 엔드 유저의 인증서를 폐지하고, 그 ID가 CRL에 포함된다. 검증자는 유저의 인증서가 CRL에 있는지를 확인하고, 만약 그렇다면 인증 실패를 반환한다. 엔드 유저는 이 폐지 프로세스에 포함되지 않고, 검증자로부터 권한 에러를 받는다.

Idemix에서는 유저가 (프로세스에) 포함된다. 발행자는 엔드 유저의 인증서를 X509와 유사하게 폐지하고, 이 폐지의 증거는 CRI에 기록된다. CRI는 엔드 유저(일명 '증명인')에게 주어진다. 그러고 엔드 유저는 CRI에 따라 그들의 인증서가 폐지되지 않았음에 대한 증명을 생성한다. 엔드 유저는 이 증명을 CRI에 따라 증명을 검증하는 검증자에게 준다. 검증 성공을 위해서는 엔드 유저에 의해 사용된 CRI의 버전("epoch"로 알려진)과 검증자에 의해 사용되는 버전이 반드시 같아야 한다. 최신 CRI는 /api/v1/idemix/cri API 엔드포인트로 리퀘스트를 보내 요청할 수 있다.

CRI 버전은 fabric-ca-server가 등록(enroll) 리퀘스트를 받고, revocation handle pool에 revocation handle이 남아 있지 않은 경우 증가한다. 이 경우, 해당 fabric-ca-server는 반드시 CRI의 epoch를 증가시키는 revocation handle의 새 pool을 생성해야 한다. revocation handle pool의 핸들 수는 idemix.rhpoolsize 서버 구성 프로퍼티를 통해 설정가능하다.


신원 재등록하기

당신의 등록 인증서가 곧 만료되거나 손상되었다고 가정해 보자. 당신은 등록 인증서 갱신을 위해 다음과 같이 reenroll 커맨드를 발급할 수 있다.

export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/peer1
fabric-ca-client reenroll

인증서 또는 신원 취소시키기

신원이나 인증서는 폐기될 수 있다. 신원 폐기는 해당 신원이 소유한 모든 인증서를 폐지하고, 해당 신원이 새 인증서를 얻는 것 또한 막는다. 인증서 폐기는 단일 인증서를 유효하지 않게 만든다.

인증서 또는 신원을 폐기하기 위해서는, 호출 신원이 반드시 hf.Revoker와 hf.Registrar.Roles 속성을 가지고 있어야 한다. 신원 폐기는 폐기하는 신원의 조직이 해당 조직의 접두사거나 또는 동일한 조직인 인증서 또는 신원만을 폐기할 수 있다.
뿐만 아니라, 폐기자는 오직 폐기자의 hf.Registrar.Roles 속성에 나열된 타입의 신원만 폐기할 수 있다.

예를 들어, orgs.org1 조직과 ‘hf.Registrar.Roles=peer,client’ 속성을 가진 폐기자는 orgs.org 또는 orgs.org1.department1조직에 속한 peer 및 client 타입 신원을 폐기할 수 있다. 하지만 orgs.org2에 속해 있거나 다른 타입인 신원은 폐기할 수 없다.

아래 커맨드는 신원을 비활성화시키고 신원과 관련된 모든 인증서를 폐기한다. 이 신원으로 Fabric CA server에 전달되는 모든 미래 리퀘스트는 거부될 것이다.

fabric-ca-client revoke -e <enrollment_id> -r <reason>

아래는 -r 플래그에서 지정될 수 있는 지원되는 이유 목록이다:

  • unspecified
  • keycompromise
  • cacompromise
  • affiliationchange
  • superseded
  • cessationofoperation
  • certificatehold
  • removefromcrl
  • privilegewithdrawn
  • aacompromise

예를 들어, 조직(affiliation) 트리의 루트와 연관된 부트스트랩 관리자는 아래와 같이 peer1의 신원을 폐기할 수 있다:

export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/admin
fabric-ca-client revoke -e peer1

한 신원에 속한 등록 인증서는 그 AKI(Authority Key Identifier; 권한 키 식별자)와 시리얼 넘버를 다음과 같이 지정해 폐기할 수 있다:

fabric-ca-client revoke -a xxx -s yyy -r <reason>

예를 들어, openssl커맨드를 사용해 인증서의 AKI와 시리얼 넘버를 얻고, 그것들을 revoke 커맨드를 사용해 아래와 같이 인증서 폐지에 사용할 수 있다:

serial=$(openssl x509 -in userecert.pem -serial -noout | cut -d "=" -f 2)
aki=$(openssl x509 -in userecert.pem -text | awk '/keyid/ {gsub(/ *keyid:|:/,"",$1);print tolower($0)}')
fabric-ca-client revoke -s $serial -a $aki -r affiliationchange

–gencrl 플래그는 모든 폐지된 인증서를 담고 있는 CRL 생성에 사용할 수 있다. 예를 들어 아래 커맨드는 peer1을 폐지하고, CRL을 생성하고, <msp folder>/crls/crl.pem 파일에 그것을 저장할 것이다.

fabric-ca-client revoke -e peer1 --gencrl

CRL은 또한 gencrl 커맨드를 사용해 생성가능하다. 커맨드에 대해서는 CRL 생성하기 섹션을 통해 자세히 알아보자.


CRL(인증서 폐지 목록) 생성하기

Fabric CA server에서 인증서가 폐지된 후, 하이퍼레저 패브릭의 적절한 MSP도 반드시 업데이트되어야 한다. 이것은 피어의 local MSPs와 적절한 채널 구성 블록의 MSPs를 포함한다. PEM encoded CRL 파일은 반드시 MSP의 crls 폴더에 위치해야 한다. fabric-ca-client gencrl 커맨드는 CRL 생성에 사용될 수 있다. hf.GenCRL 속성을 가진 신원은 특정 기간 동안 폐기된 모든 신원들의 시리얼 넘버를 포함한 CRL을 생성할 수 있다. 생성된 CRL은 <msp folder>/crls/crl.pem 파일에 저장된다.

다음 커맨드는 모든 폐기된 인증서들 (만료되었거나 만료되지 않은)을 포함한 CRL을 생성하고, ~/msp/crls/crl.pem 파일에 CRL을 저장한다. 

export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl -M ~/msp

다음 커맨드는 2017-09-13T16:39:57-08:00 이후(–revokedafter 플래그로 지정된), 2017-09-21T16:39:57-08:00 이전(–revokedbefore 플래그로 지정된)에 폐기된 모든 인증서들을 포함하는 CRL을 만들고 ~/msp/crls/crl.pem 파일에 CRL을 저장한다. 

export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl --caname "" --revokedafter 2017-09-13T16:39:57-08:00 --revokedbefore 2017-09-21T16:39:57-08:00 -M ~/msp

–caname 플래그는 리퀘스트가 전송되어야 하는 CA 이름을 지정한다. 예를 들어, gencrl 리퀘스트는 default CA로 전달된다.

–revokedafter와 –revokedbefore 플래그는 기간을 상하한을 결정한다. 생성된 CRL은 이 시간에 폐기된 인증서들을 포함한다. 이 값은 반드시 RFC3339 포맷으로 지정된 UTC timestamps 값이어야 한다. –revokedafter 타임스탬프는 –revokedbefore 타임스탬프보다 클 수 없다.

기본값으로, CRL의 다음 업데이트 일자는 다음 날로 정해진다. crl.expiry CA 구성 프로퍼티를 값 지정에 사용할 수 있다.

gencrl 커맨드 또한 –expireafter 및 –expirebefore 플래그를 받아들인다. 이는 이 플래그들로 지정된 기간동안 만료된 폐기된 인증서 CRL을 생성하는데에 사용될 수 있다. 예를 들어, 아래 커맨드는 2017-09-13T16:39:57-08:00 이후, 2017-09-21T16:39:57-08:00 이전에 폐기되었고, 2017-09-13T16:39:57-08:00 이후, 2018-09-13T16:39:57-08:00이전에 만료되는 인증서들을 포함한다.

export FABRIC_CA_CLIENT_HOME=~/clientconfig
fabric-ca-client gencrl --caname "" --expireafter 2017-09-13T16:39:57-08:00 --expirebefore 2018-09-13T16:39:57-08:00  --revokedafter 2017-09-13T16:39:57-08:00 --revokedbefore 2017-09-21T16:39:57-08:00 -M ~/msp

TLS 활성화

이 섹션은 Fabric CA client를 위한 TLS 구성법을 더 자세하게 설명한다.

아래 섹션은 fabric-ca-client-config.yaml 에서 구성된다.

tls:
  # Enable TLS (default: false)
  enabled: true
  certfiles:
    - root.pem
  client:
    certfile: tls_client-cert.pem
    keyfile: tls_client-key.pem

certfiles 옵션은 클라이언트에 의해 신뢰되는 루트 인증서를 설정한다. 이것은 일반적으로 ca-cert.pem 파일의 서버 홈 디렉토리에 있는 루트 패브릭 CA 서버의 인증서이다.

client 옵션은 상호 TLS가 서버에서 구성될때만 필요하다.


속성 기반 접근 제어

액세스 제어 결정은 신원의 속성을 기반으로 하는 체인코드(및 하이퍼레저 패브릭 런타임)으로 내릴 수 있다. 이를 속성 기반 액세스 제어 또는 짧게 ABAC라고 한다.

이를 가능하게 하기 위해, 신원의 등록 인증서(ECert)에는 하나 이상의 속성 이름과 값이 포함될 수 있다. 그런 다음 체인코드가 액세스 제어 결정을 내리기 위해 속성의 값을 추출한다.

예를 들어, 당신이 어플리케이션 app1 을 개발하고 있고, 특정 체인코드 작업에 app1 관리자만이 액세스 할 수 있기를 원한다고 가정해 보자. 체인코드는 호출자의 인증서(채널이 신뢰하는 CA에 의해 발행된)가 app1Admin 속성에 true 값을 가졌는지 검증할 수 있다. 물론 속성의 이름은 무엇이든 될 수 있고, 값이 반드시 불리언일 필요도 없다.

그러면 어떻게 속성이 있는 등록 인증서를 얻을 수 있을까? 두 가지 방법이 있다:

  1. 신원을 기재할 때, 해당 신원을 위한 등록 인증서가 반드시 기본적으로 어떤 속성을 가지도록 지정할 수 있다. 이 행위는 등록 시 오버라이딩될 수 있다. 하지만 이것은 기본 행위 지정에 유용하고, 기재가 어플리케이션 바깥에서 일어난다고 가정하면, 어플리케이션 변화를 요구하지 않는다.

    다음은 두 속성(app1Admin, email)을 가진 user1 을 기재하는 방법이다. ”:ecert” 접미사는 appAdmin 속성이 user1의 인증서에 기본으로 삽입되도록 한다. 이것은 사용자가 등록 시 속성을 명시적으로 요청되지 않은 경우에 사용된다. email 속성은 기본으로 인증서에 삽입되지 않는다.

    fabric-ca-client register --id.name user1 --id.secret user1pw --id.type client --id.affiliation org1 --id.attrs 'app1Admin=true:ecert,email=user1@gmail.com'

  2. 신원을 등록할 때, 명시적으로 하나 이상의 속성을 인증서에 추가할 수 있다. 각 속성을 요청하기 위해서는, 속성이 선택적인지 아닌지를 지정해야 한다. 이것이 선택적으로(optionally) 요청되지 않고 신원이 해당 속성을 갖고 있지 않다면 오류가 일어날 것이다.

아래는 user1이 app1Admin 속성 없이 email 속성을 가지고 등록되는 방법을 보여준다. 그리고 phone 속성을 선택적으로 가진다(유저가 phone 속성을 가지고 잇을 경우).

fabric-ca-client enroll -u http://user1:user1pw@localhost:7054 --enrollment.attrs "email,phone:opt"

아래 표는 모든 신원에 자동적으로 기재되는 세 속성들을 보여준다.

속성명속성값
hf.EnrollmentID신원의 등록ID(enrollment ID)
hf.Type신원 타입
hf.Affiliation신원 조직

인증서에 디폴트로 위 속성을 추가하기 위해서는, 반드시 명시적으로 ”:ecert” 지정과 함께 해당 속성을 기재해야 한다. 예를 들어, 예를 들어 다음은 등록 시 특정 속성이 요청되지 않은 경우 'hf.Affiliation' 속성이 등록 인증서에 추가되도록 신원'user1'을 기재한다.

조직 값(org1)이 –id.affiliation과 –id.attrs 플래그에서 반드시 같아야 함에 주의하자.

fabric-ca-client register --id.name user1 --id.secret user1pw --id.type client --id.affiliation org1 --id.attrs 'hf.Affiliation=org1:ecert'

속성 기반 액세스 제어를 위한 체인코드 라이브러리 API에 대한 정보는 https://github.com/hyperledger/fabric/blob/release-1.4/core/chaincode/lib/cid/README.md 를 보자.


동적 서버 구성 업데이트

이 섹션은 fabric-ca-server의 구성 일부를 서버 재시작 없이 동적으로 업데이트하기 위해 fabric-ca-client를 사용하는 방법을 설명한다.

이 섹션의 모든 커맨드를 사용하려면 먼저 fabric-ca-client enroll 커맨드를 실행해 등록되어야 한다.


동적으로 신원 업데이트하기

이 섹션은 신원을 동적으로 업데이트하기 위해 fabric-ca-client를 사용하는 방법을 설명한다.

클라이언트 신원이 아래를 모두 만족하지 못하면 허가 실패가 일어난다:

  • 클라이언트 신원은 반드시 콤마로 구분된 값 목록을 가진 "hf.Registrar.Roles" 속성을 가져야 하고, 그 값 중 하나가 업데이트 될 신원의 타입과 같아야 한다. 예를 들어, 클라이언트 신원이 “hf.Registrar.Roles” 속성을 가지고, 속성값이 “client”라면 이 클라이언트는 클라이언트를 업데이트할 수 있지만 피어는 업데이트할 수 없다.

  • 클라이언트의 신원의 조직은 반드시 업데이트하려는 신원의 조직과 같거나, 또는 그 조직의 접두사여야 한다. 예를 들어, “a.b” 조직 클라이언트는 “a.b.c” 조직 신원을 업데이트할 수 있다. 하지만 “a.c” 조직 신원은 업데이트할 수 없다. 만약 루트 조직이 요구된다면, 업데이트 요청은 반드시 조직 값을 ”.”로 지정해야 하고, 클라이언트는 반드시 루트 조직에 속해야 한다.

    아래는 신원을 추가, 수정, 제거하는 방법이다.


신원 정보 획득

호출자는 위 섹션에서 강조된 인증 요구 사항을 충족하는 한 fabric-ca 서버에서 신원에 대한 정보를 검색할 수 있다. 아래 명령어는 신원 획득 방법을 보여준다.

fabric-ca-client identity list

신원 추가

아래는 user1을 위한 새 신원을 추가한다. 새 신원 추가는 ‘fabric-ca-client register’ 명령어를 통한 아이덴티티 기재(registering)와 동일한 행동을 수행한다. 새 신원 추가를 위한 가능한 방법 두 가지가 있다. 첫 번째 방법은 JSON string으로 신원을 묘사할 때 -json 플래그를 쓰는 것이다.

fabric-ca-client identity add user1 --json '{"secret": "user1pw", "type": "client", "affiliation": "org1", "max_enrollments": 1, "attrs": [{"name": "hf.Revoker", "value": "true"}]}'

아래는 루트 조직으로 유저를 추가한다. 조직(affiliation)명이 "."인 것이 루트 조직이라는 뜻이다.

fabric-ca-client identity add user1 --json '{"secret": "user1pw", "type": "client", "affiliation": ".", "max_enrollments": 1, "attrs": [{"name": "hf.Revoker", "value": "true"}]}'

두 번째 방법은 다이렉트 플래그들을 사용한는 것이다. user1을 추가하기 위한 아래 방법을 살펴보자.

fabric-ca-client identity add user1 --secret user1pw --type client --affiliation . --maxenrollments 1 --attrs hf.Revoker=true

아래 테이블은 신원의 모든 필드들과 그것들이 필수인지 옵션인지, 그리고 기본 값이 무엇인지 나열한다.

FieldsRequiredDefault Value
IDYes
SecretNo
AffiliationNoCaller’s Affiliation
TypeNoclient
MaxenrollmentsNo0
AttributesNo

신원 수정

기존 신원을 수정하는 두 가지 방법이 있다. 첫 번째 방법은 JSON String으로 신원을 수정하기 위해 -json 플래그를 사용하는 것이다. 단일 요청으로 여러 수정이 가능하다. 수정되지 않은 신원 구성요소들은 기존 값으로 남는다.

주의: maxenrollments 값 "-2"는 CA의 최대 등록 설정이 사용되도록 지정한다.

아래 명령어는 -json 플래그를 사용해 신원의 여러 요소를 수정한다.

fabric-ca-client identity modify user1 --json '{"secret": "newPassword", "affiliation": ".", "attrs": [{"name": "hf.Regisrar.Roles", "value": "peer,client"},{"name": "hf.Revoker", "value": "true"}]}'

아래 명령어들은 다이렉트 플래그를 사용해 신원을 수정한다. 다음은 'user1'의 비밀번호를 'newsecret'으로 수정한다.

fabric-ca-client identity modify user1 --secret newsecret

다음은 user1의 조직을 org2로 수정한다.

fabric-ca-client identity modify user1 --affiliation org2

다음은 user1의 신원 타입을 peer1로 업데이트한다. 

fabric-ca-client identity modify user1 --type peer

다음은 user1의 maxenrollments를 5로 변경한다.

fabric-ca-client identity modify user1 --maxenrollments 5

maxenrollments 값을 -2로 지정함으로써, 아래는 user1이 최대 CA 등록 설정을 사용하게 한다.

fabric-ca-client identity modify user1 --maxenrollments -2

다음은 user1의 속성 hf.Revoker를 제공한다.

fabric-ca-client identity modify user1 --attrs hf.Revoker=

다음은 단일 fabric-ca-client identity modify 명령어에서 여러 옵션이 사용될 수 있음을 보여준다. 이 경우 비밀번호와 타입이 모두 변경된다.

fabric-ca-client identity modify user1 --secret newpass --type peer

신원 삭제

다음은 user1 신원을 삭제하고 해당 신원이 가진 모든 인증서를 폐기한다.

fabric-ca-client identity remove user1

참고: 신원 삭제는 기본적으로 fabric-ca-server에서 비활성화 되어 있다. fabric-ca-server를 –cfg.identities.allowremove 옵션으로 시작하면 활성화된다.


동적으로 소속(affiliation) 업데이트하기

이 섹션은 fabric-ca-client를 사용해 동적으로 소속을 업데이트하는 방법을 서술한다. 아래는 소속 추가, 수정, 삭제, 나열하는 방법을 보여준다.


소속 추가

클라이언트 신원이 아래 조건을 만족하지 못하면 권한 부여 실패(An authorization failure)가 일어난다:

  • 클라이언트 신원은 반드시 hf.AffiliationMgr 속성값을 true로 가지고 있어야 한다.
  • 클라이언트 신원의 소속은 반드시 업데이트되는 소속보다 계층적으로 위에 있어야 한다. 예를 들어, 클라이언트의 소속이 "a.b"일 경우 해당 클라이언트는 "a.b.c"를 추가할 수 있지만 "a"나 "a.b"를 추가할 수는 없다.

아래는 org1.dept1라는 새 조직을 추가한다.

fabric-ca-client affiliation add org1.dept1

소속 수정

클라이언트 신원이 아래 조건을 만족하지 못하면 권한 부여 실패(An authorization failure)가 일어난다:

  • 클라이언트 신원은 반드시 hf.AffiliationMgr 속성값을 true로 가지고 있어야 한다.
  • 클라이언트 신원의 소속은 반드시 업데이트되는 소속보다 계층적으로 상위에 위치해야 한다. 예를 들어, 클라이언트의 소속이 "a.b"일 경우 해당 클라이언트는 "a.b.c"를 수정할 수 있지만 "a"나 "a.b"를 수정할 수는 없다.
  • 만약 '-force' 옵션이 true이고 반드시 수정되어야 하는 신원이 있을 경우, 클라이언트 신원은 반드시 해당 신원을 수정할 권한을 가지고 있어야 한다.

아래는 org2 소속의 이름을 org3으로 바꾼다. 이것은 또한 하위 소속들의 이름을 바꾼다(e.g. ‘org2.department1’는 ‘org3.department1’로 바뀐다).

fabric-ca-client affiliation modify org2 --name org3

만약 소속 변경으로 영향받는 신원이 있다면, '–force' 옵션 없이는 오류가 발생한다. –force 옵션 사용은 영향받는 신원의 소속을 새 소속 이름으로 업데이트한다.

fabric-ca-client affiliation modify org1 --name org2 --force

소속 삭제

클라이언트 신원이 아래 조건을 만족하지 못하면 권한 부여 실패(An authorization failure)가 일어난다:

  • 클라이언트 신원은 반드시 hf.AffiliationMgr 속성값을 true로 가지고 있어야 한다.
  • 클라이언트 신원의 소속은 반드시 업데이트되는 소속보다 계층적으로 상위에 위치해야 한다. 예를 들어, 클라이언트의 소속이 "a.b"일 경우 해당 클라이언트는 "a.b.c"를 삭제할 수 있지만 "a"나 "a.b"를 삭제할 수는 없다.
  • 만약 '-force' 옵션이 true이고 반드시 영향받는 신원이 있을 경우, 클라이언트 신원은 반드시 해당 신원을 수정할 권한을 가지고 있어야 한다.

아래는 org2와 하위 소속들을 제거한다. 예를 들어 org2.dept1가 있다면 그 역시 제거된다.

fabric-ca-client affiliation remove org2

소속 삭제로 영향을 받는 신원이 있다면, –force 옵션이 사용되지 않을 경우 오류가 발생한다. –force 옵션은 해당 소속에 속한 모든 신원과, 신원의 모든 인증서들을 삭제한다.

주의: 소속 삭제는 기본적으로 fabric-ca-server에서 비활성화되어있다. 하지만 –cfg.affiliations.allowremove 옵션을 사용해 서버를 시작하면 활성화된다.


소속 정보 나열

클라이언트 신원이 아래 조건을 만족하지 못하면 권한 부여 실패(An authorization failure)가 일어난다:

  • 클라이언트 신원은 반드시 hf.AffiliationMgr 속성값을 true로 가지고 있어야 한다.
  • 클라이언트 신원의 소속은 반드시 동일하거나 계층적으로 상위에 위치해야 한다. 예를 들어, 클라이언트의 소속이 "a.b"일 경우 해당 클라이언트는 "a.b.c"나 "a.b"의 소속 정보를 가져올 수 있지만 "a"나 "a.c"의 정보를 가져올 수는 없다.

아래는 특정 소속의 정보를 가져오는 방법을 보여준다.

fabric-ca-client affiliation list --affiliation org2.dept1

호출자는 아래 명령어를 입력함으로써 열람 권한이 있는 모든 소속의 정보를 불러올 수 있다.

fabric-ca-client affiliation list

인증서 관리

이 섹션은 인증서 관리를 위해 fabric-ca-client를 사용하는 방법을 설명한다.


인증서 정보 나열

호출자를 통해 아래 인증서들을 볼 수 있다:

  • 호출자에 속하는 인증서
  • 호출자가 hf.Registrar.Roles 속성을 가지고 있거나 hf.Revoker 속성값을 true로 가지고 있을 경우, 호출자의 소속에 속한 모든 신원의 인증서를 볼 수 있다. 예를 들어 클라이언트의 소속이 'a.b'일 경우, 해당 클라이언트는 'a.b'와 'a.b.c'에 속한 신원들의 인증서를 가져올 수 있을 것이나 'a'나 'a.c'에 속한 신원들의 인증서는 가져올 수 없다.

하나 이상의 신원에 대한 인증서를 요구하는 list 명령어를 실행할 경우, 호출자와 소속이 같거나 계층적으로 하위에 위치하는 신원의 인증서들만이 나열된다.

나열되는 인증서들은 ID, AKI, serial number, expiration time, revocation time, notrevoked, 그리고 notexpired 플래그로 필터링될 수 있다.

  • id: 해당 등록 ID에 대한 인증서를 나열한다.
  • serial: 해당 시리얼 넘버를 가진 인증서가 나열된다.
  • aki: 해당 AKI를 가진 인증서가 나열된다.
  • expiration: 만료일이 해당 만료 시간 사이에 위치한 인증서가 나열된다.
  • revocation: 해당 폐지 시간 사이에 폐지된 인증서들이 나열된다.
  • notrevoked: 폐지되지 않은 인증서들이 나열된다.
  • notexpired: 만료되지 않은 인증서들이 나열된다.

결과에 만료된 인증서와 폐지된 인증서가 포함되지 않도록 notexpired 플래그와 notrevoked 플래그를 사용할 수 있다. 예를 들어 만료되었지만 폐지되지 않은 인증서를 보고 싶을 경우 expiration 플래그와 notrevoked플래그를 사용해 얻을 수 있다. 이 케이스에 대한 예시는 아래에 준비되어 있다.

시간은 반드시 RFC3339에 기초해 지정되어야 한다. 예를 들어 2018일 3월 1일 오후 1시와 2018일 6월 15일 오전 2시 사이에 만료된 인증서를 나열하기 위해서는, 입력 시간 문자열은 반드시
2018-03-01T13:00:00z와 2018-06-15T02:00:00z처럼 되어야 한다. 시간이 고려되지 않고 일자만이 중요한 경우 시간 부분을 적지 않고 두어서 문자열이 2018-03-01와 2018-06-15가 되도록 하면 된다.

now 문자열은 현재 시간을 나타내고, 빈 문자열은 모든 시간(any time)을 나타낸다. 예를 들어 now::는 지금부터 미래의 모든 지점을 표시한다. 그리고 ::now는 과거의 모든 시간부터 지금까지를 나타낸다.

아래 명령어는 여러 필터를 사용해 인증서를 나열하는 방법을 보여준다.

모든 인증서 나열하기:

fabric-ca-client certificate list

id로 모든 인증서 나열하기:

fabric-ca-client certificate list --id admin

serial 과 aki로 인증서 나열하기:

fabric-ca-client certificate list --serial 1234 --aki 1234

serial 과 aki, id로 인증서 나열하기:

fabric-ca-client certificate list --id admin --serial 1234 --aki 1234

폐기되지도 만료되지도 않은 인증서 나열하기:

fabric-ca-client certificate list --id admin --notrevoked --notexpired

아이디의 폐기되지 않은 모든 인증서 나열하기:

fabric-ca-client certificate list --id admin --notrevoked

아이디의 만료되지 않은 인증서 나열하기:

–notexpired 플래그는 –expiration now::와 동일하다. 이것은 미래에 인증서가 만료될 것임을 뜻한다.

fabric-ca-client certificate list --id admin --notexpired

아이디의 특정 시간에 폐기된 인증서 나열하기:

fabric-ca-client certificate list --id admin --revocation 2018-01-01T01:30:00z::2018-01-30T05:00:00z

특정한 시간에 폐기되었지만 만료되지 않은 특정 아이디의 인증서 나열하기:

fabric-ca-client certificate list --id admin --revocation 2018-01-01::2018-01-30 --notexpired

기간을 사용해 특정 아이디의 모든 폐기된 인증서 나열하기:

fabric-ca-client certificate list --id admin --revocation -30d::-15d

특정 시간 전에 폐기된 모든 인증서 나열하기:

fabric-ca-client certificate list --revocation ::2018-01-30

특정 시간 후에 폐기된 모든 인증서 나열하기:

fabric-ca-client certificate list --revocation 2018-01-30::

특정 시간 이후 현재 이전에 폐기된 모든 인증서 나열하기:

fabric-ca-client certificate list --id admin --revocation 2018-01-30::now

아이디의 특정 시간 사이에 만료되었지만 폐기되지 않은 인증서 나열하기:

fabric-ca-client certificate list --id admin --expiration 2018-01-01::2018-01-30 --notrevoked

아이디의 특정 시간동안 만료된 인증서 나열하기:

fabric-ca-client certificate list --expiration -30d::-15d

아이디의 특정 시간 이전에 만료된 인증서 나열하기:

fabric-ca-client certificate list --expiration ::2058-01-30

아이디의 특정 시간 이후에 만료된 인증서 나열하기:

fabric-ca-client certificate list --expiration 2018-01-30::

아이디의 특정 시간 이후 현재 이전에 만료된 인증서 나열하기

fabric-ca-client certificate list --expiration 2018-01-30::now

이후 10일간 만료되는 인증서 나열하기

fabric-ca-client certificate list --id admin --expiration ::+10d --notrevoked

list certificate 명령어는 파일 시스템에 인증서를 저장할때도 사용될 수 있다. 이것은 관리자 폴더를 MSP에 전파하는 편리한 방법이다. -store 플래그로 인증서를 저장할 위치를 가리킨다.

MSP에 신원의 인증서를 저장하여 신원이 관리자가 되도록 구성한다.

export FABRIC_CA_CLIENT_HOME=/tmp/clientHome
fabric-ca-client certificate list --id admin --store msp/admincerts

특정 CA 인스턴스에 접근

서버가 여러 CA 인스턴스를 구동하고 있을 경우, 리퀘스트는 특정 CA를 향할 수 있다. 기본적으로 클라이언트 리퀘스트에서 CA 이름이 지정되지 않으면 fabric-ca-server의 기본 CA로 요청이 향한다. 아래와 같이 caname 필터를 사용해 클라이언트 커맨드에서 CA 이름을 지정할 수 있다:

fabric-ca-client enroll -u http://admin:adminpw@localhost:7054 --caname <caname>

HSM 구성


기본값으로 Fabric CA 서버와 클라이언트는 PEM-encoded file에 개인키들을 저장한다. 하지만 개인키를 PKCS11 APIs를 통해 HSM(Hardware Security Module)에 저장하도록 구성할 수 있다. 이는 서버나 클라이언트의 구성 파일의 BCCSP (BlockChain Crypto Service Provider) 섹션에서 구성가능하다. 현재 패브릭은 HSM과의 통신에 PKCS11 standard만을 지원한다.


예시


아래 예시는 Fabric CA server나 client를 SoftHSM(https://github.com/opendnssec/SoftHSMv2 를 보자)이라고 불리는 PKCS11의 소프트웨어 버전을 사용하기 위해 구성하는 방법을 보여준다.

SoftHSM 설치 후 SOFTHSM2_CONF 환경변수가 SoftHSM2 구성파일이 저장된 위치를 가리키는지 확인한다. 구성 파일은 아래와 같이 보인다.

directories.tokendir = /tmp/
objectstore.backend = file
log.level = INFO

testdata 디렉토리에서 SoftHSM2.conf라는 이름의 구성파일 예시를 찾을 수 있다.

토큰을 만들어서 ForFabric로 라벨링하고 pin을 98765432로 설정한다(SoftHSM 문서를 참조하자).

BCCSP 구성을 위해 구성 파일과 환경변수를 모두 사용할 수 있다. Fabric CA 서버 구성 파일의 bccsp 섹션을 아래와 같이 지정할 수 있다. default 필드의 값이 PKCS11라는 것에 주의한다.

#############################################################################
# BCCSP (BlockChain Crypto Service Provider) section is used to select which
# crypto library implementation to use
#############################################################################
bccsp:
  default: PKCS11
  pkcs11:
    Library: /usr/local/Cellar/softhsm/2.1.0/lib/softhsm/libsofthsm2.so
    Pin: 98765432
    Label: ForFabric
    hash: SHA2
    security: 256
    filekeystore:
      # The directory used for the software file-based keystore
      keystore: msp/keystore

그리고 아래와 같이 환경변수로 관련된 필드를 오버라이딩할 수 있다.

FABRIC_CA_SERVER_BCCSP_DEFAULT=PKCS11
FABRIC_CA_SERVER_BCCSP_PKCS11_LIBRARY=/usr/local/Cellar/softhsm/2.1.0/lib/softhsm/libsofthsm2.so
FABRIC_CA_SERVER_BCCSP_PKCS11_PIN=98765432
FABRIC_CA_SERVER_BCCSP_PKCS11_LABEL=ForFabric

사전 빌드된 Hyperledger Fabric Docker 이미지는 PKCS11 사용이 활성화되어 있지 않다. 도커를 사용해 fabric ca를 배포할 경우 직접 이미지를 빌드하고 아래 명령어를 사용해 PKCS11를 활성화해야 한다:

make docker GO_TAGS=pkcs11

PKCS11 라이브러리가 컨테이너 안에 설치되거나 마운트되어 CA가 접근가능한지 확인해야 한다. 도커 컴포즈를 사용해 fabricCA를 배포하는 경우, SoftHSM 라이브러리와 구성 파일을 컨테이너에 마운트할 수 있도록 volumes를 사용해 Compose 파일을 업데이트할 수 있다. 예를 들어 아래 환경변수 및 volumes 변수를 Docker Compose file에 추가할 수 있다:

environment:
   - SOFTHSM2_CONF=/etc/hyperledger/fabric/config.file
volumes:
   - /home/softhsm/config.file:/etc/hyperledger/fabric/config.file
   - /usr/local/Cellar/softhsm/2.1.0/lib/softhsm/libsofthsm2.so:/etc/hyperledger/fabric/libsofthsm2.so

파일 포맷


Fabric CA 서버의 구성 파일 포맷


기본 구성 파일이 서버의 홈 디렉토리에 만들어진다 (더 많은 정보는 Fabric CA Server 섹션을 참고하자). 다음 링크는 샘플 서버 구성 파일을 보여준다.


Fabric CA 클라이언트의 구성 파일 포맷


기본 구성 파일이 클라이언트의 홈 디렉토리에 만들어진다 (더 많은 정보는 Fabric CA Client 섹션을 참고하자). 다음 링크는 샘플 클라이언트 구성 파일을 보여준다.


문제 해결


1.. fabric-ca-client 또는 fabric-ca-server 실행 시도 시 OSX에서 Killed: 9 에러를 볼 경우, 해당 문제에 대해 논의하는 긴 스레드가 https://github.com/golang/go/issues/19734 에 있다. 이 이슈를 다루기 위한 간단한 답변은 아래 커맨드를 실행하는 것이다:

# sudo ln -s /usr/bin/true /usr/local/bin/dsymutil

2.. 아래 이벤트가 일어날경우 [ERROR] No certificates found for provided serial and aki 에러가 발생한다:

a. fabric-ca-client enroll 명령어를 입력해서 등록 인증서(ECert)를 생성한다.

b. fabric-ca-server의 데이터베이스가 지워지고 재생성된다. 그에 따라 a. 에서 생성한 ECert를 잃게 된다. fabric-ca-server를 호스팅하는 도커 컨테이너를 멈추고 재시작하지만 fabric-ca-server가 기본 sqlite 데이터베이스를 사용하고 데이터베이스 파일이 볼륨에 저장되어 있지 않아 지속성이 없을 경우 이런 상황이 일어날 수 있다.

c. fabric-ca-client register 명령어나 a.에서 생성한 ECert를 사용하는 다른 명령어를 입력한다. 이 경우 데이터베이스가 ECert를 더 이상 가지고 있지 않기 때문에 [ERROR] No certificates found for provided serial and aki가 발생한다.

이 문제를 해결하기 위해서는 a.단계를 반복해 다시 등록해야한다. 이는 새 ECert를 생성해 현재 데이터베이스에 저장할 것이다.


3.. Fabric CA Server 클러스터로 공유된 sqlite3 데이터베이스를 사용하는 여러 병렬 리퀘스트를 보내는 경우, 서버는 때때로 ‘database locked’ 에러를 발생시킨다. 이는 대개 데이터베이스 트랜잭션이 데이터베이스 락(다른 클러스터 멤버에 의해 유지된)에서 벗어나기를 기다리는 동안 타임아웃이 발생했기 때문이다. 이는 sqlite가 임베디드 데이터베이스이기 때문에 유효하지 않은 구성이다. 즉, Fabric CA 서버 클러스터는 반드시 공유된 파일 시스템을 통해 동일한 파일을 공유해야 하는데 이는 클러스터 토폴로지와 모순되는 SPoF(single point of failure; 단일 실패 지점)을 발생시킨다. 가장 좋은 방법은 클러스터 토폴로지에서 Postgres나 MySQL 데이터베이스를 사용하는 것이다.


4.. Fabric CA 서버로부터 발행된 등록 인증서를 사용할 때 피어 또는 오더러가 Failed to deserialize creator identity, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority 와 유사한 오류를 반환했다고 가정해 보자. 이는 Fabric CA Server가 인증서를 발행하기 위해 사용한 서명 CA 인증서가 권한 확인을 위해 사용되는 MSP의 cacerts 또는 intermediatecerts 폴더의 인증서와 일치하지 않는다는 뜻이다.

권한 확인을 위해 사용되는 MSP는 에러를 발생시켰을 때 실행한 기능이 무엇인지에 달려 있다. 예를 들어 체인코드를 피어에 설치하고자 했다면 피어 파일 시스템에 있는 로컬 MSP가 사용된다; 반면 특정 채널에서의 체인코드 인스턴스화 같은 채널 특정적 기능을 수행했다면, 채널의 제네시스 블록 또는 가장 최근 구성 파일의 MSP가 사용된다.

이것이 문제인지 확인하려면 등록 인증서의 AKI(Authority Key Identifier; 권한 키 식별자)를 적절한 MSP의 cacerts 또는 intermediatecerts 폴더에 있는 인증서(들)의 SKI(Subject Key Identifier; 대상 키 식별자)와 비교한다. penssl x509 -in <PEM-file> -noout -text | grep -A1 “Authority Key Identifier” 명령어는 AKI를 보여준다. penssl x509 -in <PEM-file> -noout -text | grep -A1 “Subject Key Identifier” 명령어는 SKI를 보여준다. 둘이 동일하지 않을 경우 그것이 에러의 원인이라고 볼 수 있다.

이는 아래를 포함한 여러 이유 때문에 일어날 수 있다:

a. 키 자료를 생성하기 위해 cryptogen 을 사용했지만 cryptogen 으로 생성된 인증서와 서명키를 사용해 fabric-ca-server를 시작하지 않았다. 이 문제를 해결하기 위해서는(FABRIC_CA_SERVER_HOME은 fabric-ca-server의 홈 디렉토리로 설정되어 있다고 가정한다.):

  1. fabric-ca-server를 중지시킨다.

  2. crypto-config/peerOrganizations/<orgName>/ca/*pem을 $FABRIC_CA_SERVER_HOME/ca-cert.pem으로 복사한다.

  3. crypto-config/peerOrganizations/<orgName>/ca/*_sk 를 $FABRIC_CA_SERVER_HOME/msp/keystore/으로 복사한다.

  4. fabric-ca-server를 시작한다.

  5. 앞서 생성된 등록 인증서를 제거하고 다시 등록해 새 인증서를 얻는다.

    b. 제네시스 블록이 생성된 후에 Fabric CA 서버에 의해 사용된 서명 키와 인증서를 제거하고 재생성한다. 이는 패브릭 CA 서버가 도커 컨테이너에서 구동되고, 컨테이너가 재시작되었고, 홈 디렉토리가 볼륨 마운트 되어 있지 않을 경우 일어날 수 있다. 이 경우 fabric CA 서버는 새 CA 서명 키와 인증서를 만든다.

    원 CA 서명 키를 복구할 수 없다고 가정하면, 이 시나리오에서 복구하기 위한 유일한 방법은 적절한 MSP의 cacerts 또는 intermediatecerts의 인증서를 새 CA 인증서로 업데이트하는 것이다.

profile
HH
다음 포스트

Fabric CA Operations Guide

0개의 댓글