CA Deployment steps

HH·2022년 1월 9일

목록 보기

6/7

CA 배포 단계

바이너리 다운로드

Fabric CA 서버와 클라이언트 바이너리는 github에서 다운로드할 수 있다. Assets로 스크롤을 내려서 머신 타입에 맞는 최신 바이너리를 선택하자. .zip 파일은 CA 서버 및 클라이언트 바이너리를 모두 포함한다. 이 바이너리들을 사용해 CA를 배포하고 구동하는 것을 마스터한다면 쿠버네티스 또는 도커 배포와 같은 fabric CA 이미지를 대신 사용하고 싶을 수 있다. 하지만 지금 이 토픽의 목적은 바이너리를 적절히 사용하는 방법을 가르치는 것이다.

서버 바이너리 파일

이 토픽에서는 세 가지 다른 종류의 CA를 배포하기 위해 바이너리를 사용할 것이다. 각각 TLS CA, 조직 CA, 그리고 선택적으로 중간 CA이다. TLS CA는 조직의 모든 노드들 간 통신을 안전하게 하는 인증서르 발행한다. 조직 CA는 신원 인증서를 발행한다. 중간 CA를 추가하기로 결정했다면, 조직 CA가 루트 CA 또는 중간 CA의 부모 CA가 된다. 아직 읽지 않았다면 CA 계획하기 토픽을 읽어서 각 CA의 목적과 그들의 차이점을 이해해야 한다. 여기서는 TLS CA, 중간 CA, 그리고 조직 CA를 서로 다른 폴더에서 구동한다. CA 서버 바이너리를 각 폴더에 복사할 것이다.

클라이언트 바이너리 파일

마찬가지로 Fabric CA client binary를 고유한 디렉토리에 복사할 것이다. CA 클라이언트를 고유한 폴더에 놓는 것은 인증서 관리를 돕는다. 특히 여러 CA들과 상호작용 해야 할 때 그렇다. CA 서버에 대해 CA 클라이언트 명령어를 입력할 때 특정 CA 서버 URL을 리퀘스트에서 수정함으로써 해당 CA를 타게팅할 수 있다. 따라서, 오직 한 Fabric CA 클라이언트 바이너리가 필수적이다. 그리고 그것을 여러 CA와 상호작용하는데에 사용할 수 있다. Fabric CA 클라이언트 사용에 대해서는 아래에서 자세히 알아본다.

Fabric CA client

Fabric CA server 배포 전에 Fabric CA client의 역할을 이해해야 한다. fabric SDKs를 사용할 수도 있지만 노드 관리자 신원을 기재하고 등록하기 위해 fabric CA 클아이언트를 사용하는 것이 권장된다. 이 토픽에서 제공하는 지침은 단일 Fabric CA 클라이언트가 사옹된다고 가정한다. 신원, 또는 유저를 기재하는 것은 CA 데이터베이스 유저 레지스트리에 등록 ID와 비밀번호가 추가되는 프로세스다. LDAP server를 유저 레지스트리로 사용할 경우 기재 단계는 필요하지 않다. 신원이 이미 LDAP 데이터베이스에 존재하기 때문이다. 유저가 기재되고 나면 abric CA client를 신원을 등록하기 위해 사용할 수 있다. 등록은 신원이 조직의 일부로써 거래하기 위해 필요한 인증서를 생성하는 프로세스이다. 등록 리퀘스트를 제출했다면, 비밀키와 공개키가 먼저 fabric CA 클라이언트에 로컬로 저장된다. 그리고 공개키가 CA로 전송되고, 인코딩된 "서명 인증서"가 반환된다.

단일 CA 클라이언트를 여러 CA에 대한 기재 및 등록 리퀘스트 제출에 사용할 것이므로, 인증서 관리는 CA 클라이언트 사용 시 매우 중요하다. 가장 좋은 방법은 CA 클라이언트가 상호작용하는 각 CA 서버마다 하위 폴더를 만들어 생성된 인증서를 저장하는 것이다.

각 CA 서버에 커넥트하기 위한 하위 폴더를 만든다(/tls-ca, /org1-ca, /int-ca). 이 폴더는 Fabric CA client 아래, 또는 Fabric CA client가 접근할 수 있는 어떤 경로에든 만들 수 있다. 이 지침의 목적을 위해 이 폴더들은 fabric-ca-client 디렉토리 안에 만들어진다.

예시:

mkdir fabric-ca-client
cd fabric-ca-client
mkdir tls-ca org1-ca int-ca

팁: fabric CA 클라이언트 바이너리를 선호하는 어떤 폴더에서든 구동할 수 있지만, 지침을 따라오기 쉽게 하기 위해 이것이 fabric-ca-client 로 이름붙여진 디렉토리에서 참조할 것이다.

Fabric CA client binary를 fabric-ca-client 폴더 아래로 복사한다.
TLS 통신이 프로덕션 네트워크에서 활성화되었기 때문에, 조직을 위한 TLS CA가 조직의 모든 노드들의 통신 보안을 위한 인증서 생성을 맡는다. 따라서 Fabric CA client가 조직의 CA 서버와 거래할 때 마다 안전한 클라이언트-서버 통신을 위해 TLS CA "루트 인증서"가 필요하다. 예를 들어 Fabric CA 클라이언트가 CA 서버에 기재 또는 등록 요청을 보낼 경우, 클라이언트 리퀘스트는 SSL handshake를 수행하기 위한 루트 인증서를 포함한다. ca-cert.pem이라고 이름지어진 TLS CA의 루트인증서는 서버 config .yaml 파일에서 TLS가 활성화된 후 TLS CA에서 생성된다. CA 클라이언트의 TLS 통신을 활성화시키기 위하여 루트 인증서를 저장할 tls-root-cert 디렉토리가 필요하다. 이 토픽에서는 나중에 루트 인증서를 이 폴더로 복사할 것이다.

mkdir tls-root-cert

폴더 구조 결과는 다음과 유사하다:

fabric-ca-client
  ├── int-ca
  ├── org1-ca
  ├── tls-ca
  └── tls-root-cert

중요: Fabric CA client가 서로 다른 TLS 서버에 의해 보안되는 여러 조직의 CA들과 거래하는 경우, 각 조직의 TLS CA 루트 인증서를 보유하기 위한 tls-root-cert 폴더를 추가로 만들거나, 폴더 내부에서 인증서들을 구분할 수 있도록 이름붙인다. Fabric Ca 클라이언트가 동일한 조직의 CA 서버들과만 거래할 것이므로, 모두 동일한 TLS CA에 의해 보안이 이루어진다. 따라서 이 폴더에는 단일 루트 인증서만을 가질 것이다.

CLI커맨드 플래그나 환경변수를 사용해 인증서 및 Fabric CA 클라이언트 바이너리 위치를 지정할 수 있다:

FABRIC_CA_CLIENT_HOME : Fabric CA 클라이언트 바이너리 위치에 대한 정규화된 경로를 지정한다.
FABRIC_CA_CLIENT_TLS_CERTFILES : TLS CA 루트 인증서의 위치와 이름을 지정한다. 만약 환경변수 FABRIC_CA_CLIENT_TLS_CERTFILES가 절대경로가 아니라면 FABRIC_CA_CLIENT_HOME로 지정된 CA 클라이언트의 홈 디렉토리에 대한 상대경로로 파싱된다. 이 지침 전체에 걸쳐, TLS CA 루트 인증서 위치를 지정하는 대신 --tls.certfiles 플래그를 커맨드에서 사용할 것이다.
FABRIC_CA_CLIENT_MSPDIR : 인증서가 위치한 폴더의 이름을 지정하기 위해 환경변수를 사용할 수 있지만, 클라이언트가 여러 CA들과 통신하기 때문에, 더 나은 선택지는 명시적으로 --mspdir 플래그를 register 및 enroll 커맨드로 보내 위치를 지정하는 것이다. 커맨드에서 지정되지 않을 경우, 위치는 기본적으로 $FABRIC_CA_CLIENT_HOME/msp가 되고, 이는 패브릭 CA 클라이언트가 조직의 여러 CA 서버와 거래할 경우 문제가 된다.

중요: 처음 enroll 커맨드를 CA 클라이언트에서 사용할 때 fabric-ca-client-config.yaml이 $FABRIC_CA_CLIENT_HOME 디렉토리에 이미 존재하고 있지 않을 경우 해당 파일이 생성된다. 이 파일의 값을 커스터마이징할 때 그것들은 자동으로 CA 클라이언트에 의해 사용되고 이후 실행할 enroll 커맨드에 지정할 필요가 없다.

여러 CA 서버와 통신하기 위해 단일 Fabric CA 클라이언트를 사용하는 것은 필수적인 패턴이 아니다. 다른 대안은 각 CA 서버마다 클라이언트를 가지는 것이다. 이 경우 서버에 대한 Fabric CA 클라이언트 커넥션 설정은 최초 enroll 명령어가 CA 서버 관리자를 생성하기 위해 입력될 때 fabric-ca-client-config.yaml 파일에 생성되고 저장된다.

CLI에서 트랜잭션 제출

CA 서버와 CA 클라이언트 바이너리 파일에 두 CLI 커맨드 세트가 포함되어 있다.

Fabric CA 서버를 배포하고 업데이트 하기 위해서는 Fabric CA server CLI commands를 사용한다.
서버가 설정된 후 신원 기재,등록,폐지 등과 같은 요청을 보내기 위해서는 Fabric CA client CLI commands 를 사용한다.

이 토픽 전반에 걸쳐 이 커맨드들을 사용할 것이다.

어떤 순서로 CA들을 배포해야 하는가?

TLS CA와 조직 CA를 모두 포함한 dual-headed CA 를 배포하지 않는다고 가정하면, 다음 순서를 따라야 한다.

TLS CA 배포

TLS 통신이 프로덕션 네트워크에 필요하기 때문에 TLS는 반드시 각 CA, 피어, 오더링 노드에서 활성화되어야 한다. CA 운영 가이드의 예시 구성이 모든 조직에 대해 단일 TLS CA를 공유하는 반면, 프로덕션을 위한 추천 구성은 각 조직마다 TLS CA를 배포하는 것이다. TLS CA가 네트워크의 모든 노드들 간 통신을 안전하게 하는 TLS 인증서를 발행한다. 따라서 처음에 TLS CA를 배포해 노드 간에 발생하는 TLS handshake를 위한 TLS 인증서를 생성하도록 해야 한다.
조직 CA 배포

이것은 조직의 신원 등록 CA이고 이 조직에서 신원을 기재하고 등록해 네트워크에 참여할 수 있게 한다.
중간 CA 배포(선택적)

네트워크에 중간 CA를 배포하도록 마음먹었다면 중간 CA의 부모 서버(관련된 루트 CA)가 반드시 먼저 배포되어야 한다.

TLS CA 배포

TLS CA, 조직 CA, 중간 CA 중 무엇을 설정하느냐에 상관 없이 아래 단계는 전반적으로 동일하다. 차이점은 CA 서버 configuration.yaml 파일을 수정할 때 생긴다. 아래 단계는 프로세스를 전반적으로 살펴보기 위한 것이다:

1단계: CA 서버 초기화
2단계: CA 서버 구성 수정
3단계: CA 서버 인증서 삭제
4단계: CA 서버 시작
5단계: TLS CA로 부트스트랩 유저 등록

노드를 배포할 때 TLS 구성에 대한 세 가지 옵션이 있다:

TLS 없음. 프로덕션 네트워크에 추천되지 않는다.
서버 사이드 TLS
상호 TLS

이 프로세스는 프로덕션 네트워크에 추천되는 erver-side TLS가 활성화된 CA를 구성할 것이다. 상호 TLS는 기본적으로 비활성화된다. 만약 상호 TLS를 필요로 한다면, TLS 구성 설정을 참조해라.

시작하기 전에

Fabric CA 서버 바이너리 fabric-ca-server를 이미 다운로드하고 머신의 빈 디렉토리에 복사해 놓았어야 한다. 이 지침의 목적을 위해 바이너리를 fabric-ca-server-tls에 둔다.

mkdir fabric-ca-server-tls

바이너리를 폴더로 복사한다.

TLS CA 서버 초기화

CA 서버를 배포하기 위한 첫 단계는 그것을 "초기화" 하는 것이다. 관리자 유저 아이디와 패스워드를 지정해 아래 ca 서버 cli 커맨드를 구동시킨다.

./fabric-ca-server init -b <ADMIN_USER>:<ADMIN_PWD>

예:

cd fabric-ca-server-tls
./fabric-ca-server init -b tls-admin:tls-adminpw

-b(bootstrap identity) 플래그는 관리자 이름과 패스워드를 CA 서버에 부트스트랩해서 CA 관리자 유저를 성공적으로 "기재"한다. 그러므로 명시적인 Fabric CA 클라이언트 register 명령어가 부트스트랩된 유저에는 필요하지 않다. 모든 CA 유저는 CA로 기재된 다음 등록되어야 한다. -b 플래그를 사용해 암묵적으로 기재된 CA 관리 신원만이 예외이다. 기재 프로세스는 유저를 CA 데이터베이스에 삽입한다. -b 옵션은 LDAP가 구성될 경우 불필요하다.

주의: 이 예시는 오직 설명 목적이다. 명백하게, 프로덕션 환경에서는 절대 tls-admin과 tls-adminpw를 부트스트랩 유저 이름과 비밀버호로 사용하면 안 된다. 지정한 관리자 id 와 비밀번호를 기록해놓았는지 확인하자. 그것들은 CA에 대해 기재 및 등록 커맨드를 실행할 때 필요하다.

CA 서버 `init` 명령어가 무슨 일을 하는가?

init 커맨드는 실제로 서버를 시작하지는 않지만 서버에 존재하고 있지 않을 경우 필요한 메타데이터를 생성한다:

기본 CA 홈 디렉토리(이 지침에서 FABRIC_CA_HOME로 참조된다)를 fabric-ca-server init가 구동된 위치로 지정한다.
FABRIC_CA_HOME 디렉토리에 서버 구성 템플릿으로 사용되는 기본 구성 파일 fabric-ca-server-config.yaml을 생성한다. 이 파일을 지침 전체에 걸쳐 configuration .yaml 파일이라고 부른다.
CA HOME 디렉토리에 해당 파일이 존재하지 않을 경우 TLS CA 루트 서명 인증서 파일 ca-cert.pem를 생성한다. 이것은 자기 서명 루트 인증서로, TLS CA 자기 자신에 의해 생성되었고 서명되었으며 다른 소스에서 오지 않았음을 뜻한다. 이 인증서는 조직의 모든 노드들과 거래하고 싶어하는 모든 클라이어들에게 공유되어야 하는 공개키이다. 어떤 클라이언트 또는 노드가 다른 노드에게 트랜잭션을 보낼 때 반드시 이 인증서를 트랜잭션의 일부로 보내야 한다.
CA 서버 개인 키를 생성하고 FABRIC_CA_HOME 디렉토리의 /msp/keystore 아래 저장한다.
서버를 위한 기본 SQLite 데이터베이스를 초기화한다. 선택한 데이터베이스를 사용하기 위해 configuration .yaml file에서 데이터베이스 설정을 수정할 수 있다. 서버는 시작될 때 마다 이 데이터베이스로부터 데이터를 불러온다. 나중에 PostgreSQL 나 MySQL과 같은 다른 데이터베이스로 변경할 경우, 그리고 configuration .yaml 파일의 registry.identites 섹션에서 정의된 신원이 그 데이터베이스에 없을 경우, 해당 신원이 기재된다.
CA 서버 관리자를 부트스트랩한다. CA 서버가 이후 시작되면, 관리자 유저는 구성 파일의 registry 섹션에 준비된 관리자 속성을 가지고 기재된다. CA가 이 중 어느 속성으로 다른 유저를 기재할 때 사용될 경우, CA 관리자 유저가 해당 속성들을 가지고 있어야 한다. 다른 말로, 기재자는 반드시 다른 신원을 특정 속성으로 기재할 때 해당하는 hf.Registrar.Roles 속성을 가져야 한다. 즉 CA 관리자가 중간 CA의 관리자 신원 기재를 위해 사용될 경우, CA 관리자는 해당 CA가 중간 CA 서버가 아닐지라도 반드시 hf.IntermediateCA 에 true값을 가져야 한다. 기본 설정은 이미 이 속성을 포함하고 있다.

중요: 구성 파일의 설정을 수정하고 서버를 재시작할 때 앞서 발행된 인증서가 대체되지 않는다. 서버가 시작될 때 인증서를 재생성하고 싶을 경우 인증서를 제거하고 fabric-ca-server start 커맨드를 구동해야 한다. 예를 들어 서버를 시작한 후 csr 값을 수정했다면 앞서 발행된 인증서를 제거하고 fabric-ca-server start 커맨드를 입력해야 한다. 새 서명 인증서와 개인키를 사용해 CA 서버를 재시작할 때 모든 이전에 발행된 인증서는 더이상 CA에서 인증될 수 없음을 주의해야 한다.

TLS CA 서버 구성 수정

이제 CA 서버를 초기화했고, 구성 파일을 수정해 기본 구성 설정을 유즈케이스에 맞춰 수정할 수 있다.

최소한 다음은 진행해야 한다:

port : 이 서버에 사용하고 싶은 포트를 입력한다. 이 지침은 7054를 사용하지만 포트를 선택할 수 있다.
tls.enabled : 기본 구성 파일에서 TLS는 비활성화되어 있다. 이것은 프로덕션 서버이므로 해당 값을 true로 수정해야 한다. 이것은 TLS 서명 인증서 tls-cert.pem 파일이 서버가 다음 단계에서 시작될 때 생성되도록 한다. 이 인증서는 TLS handshake동안 서버가 클라이언트한테 제시해서 클라이언트가 TLS CA의 ca-cert.pem을 사용해 검증하는데에 사용된다.
ca.name : 이 파라미터를 수정해 ca에 이름을 부여한다.
csr.hosts : 파일에 제시된 것과 ( 호스트명과 ip 주소가) 다를 경우, 서버가 구동될 때 이 호스트명과 ip 주소를 포함하도록 해당 파라미터를 수정한다.
signing.profiles.ca : 이것은 CA 인증서를 발행하지 않는 TLS CA 서버이므로 ca 프로파일 섹션은 제거될 수 있다. signing.profiles 블록은 오직 tls 프로파일만 가지고 있어야 한다.
operations.listenAddress : 이 호스트와 포트에 다른 노드가 있는 드문 경우, 이 파라미터를 다른 포트로 변경해야 한다.

TLS CA 서버 인증서 삭제

서버를 시작하기 전에, 구성 파일의 csr 블록의 어떤 값을 변경했다면 fabric-ca-server-tls/ca-cert.pem 파일과 전체 fabric-ca-server-tls/msp 폴더를 삭제해야 한다. 이 인증서들은 CA 서버를 시작할 때 재생성될 것이다.

TLS CA 서버 시작

CA 서버를 시작하기 위해 다음 명령어를 구동한다.

./fabric-ca-server start

서버가 성공적으로 시작되면 아래와 유사한 것을 볼 수 있다:

[INFO] Listening on https://0.0.0.0:7054

TLS 통신을 활성화했으므로 TLS 서명 인증서 tls-cert.pem 파일이 FABRIC_CA_HOME 위치 아래에 생성된다.

팁: CA init 커맨드에 설정된 ADMIN_USER와 ADMIN_PWD는 start 커맨드의 -b플래그로 오버라이딩할 수 없다. CA 관리자 비밀번호를 변경할필요가 있다면 Fabric CA 클라이언트 identity 커맨드를 사용해야 한다.

옵션 플래그:

-b : 문제 진단을 위한 DEBUG 모드로 서버를 구동하고 싶을 경우 start 명령어에 -d 플래그를 사용한다. 하지만 일반적으로 서버를 디버그 모드를 활성화하여 시작하는 것은 추천되지 않는다. 퍼포먼스를 느리게 하기 때문이다.
-p : 서버를 구성파일에서 지정한것과 다른 포트에서 구동하고 싶을 경우 기존 포트를 오버라이딩 할 수 있다.

TLS CA로 부트스트래핑 유저 등록하기

이제 TLS CA가 구성되었고, 조직의 다른 노드들을 배포하기 전에 TLS CA의 부트스트래핑 (관리자) 유저ㅏ를 등록해야 한다. CA 서버가 설정되고 구동되었기 때문에, Fabric CA server CLI commands 대신 Fabric CA client CLI commands를 사용해 서버에 등록 리퀘스트를 보낼 것이다.

Fabric CA 클라이언트를 사용해 수행되는 등록 프로세스는 노드 신원을 형성하는 인증서와 개인키 페어를 생성하는 과정이다. 이미 Fabric CA client 섹션에서 필요한 폴더를 준비해놓았어야 한다.

클라이언트 커맨드를 위해 사용할 폴더 구조는 다음과 같다:

fabric-ca-client
  └── tls-ca
  └── tls-root-cert

이 폴더는 Fabric CA 클라이언트가 다음을 하기 위해 사용된다:

Fabric CA client enroll 커맨드가 TLS CA 서버에 대해 실행되어 TLS CA 부트스트랩 신원을 등록할 때 인증서를 저장한다(tls-ca폴더).
Fabric CA client가 TLS CA server와 통신하기 위한 TLS CA root 인증서가 위치한 장소를 안다(tls-root-cert폴더).

TLS CA 루트 인증서 fabric-ca-server-tls/ca-cert.pem를 fabric-ca-client/tls-root-cert/tls-ca-cert.pem 폴더로 복사한다. 이 인증서는 TLS CA가 시작될 때 생성된 것이다. 파일 이름을 tls-ca-cert.pem로 변경한 것은 이 인증서가 TLS CA로부터 온 루트 인증서임을 알아보기 쉽게 하기 위한 것이다.

중요: 이 TLS CA root 인증서는 TLS CA에 대해 커맨드를 실행하는 각 클라이언트 시스템들이 사용가능해야한다.
The Fabric CA Client는 Fabric CA client binary의 위치를 알 필요가 있다. FABRIC_CA_CLIENT_HOME 환경 변수가 위치 설정에 사용된다:

export FABRIC_CA_CLIENT_HOME=<FULLY-QUALIFIED-PATH-TO-FABRIC-CA-BINARY>

예를 들어 fabric-ca-client 폴더에 있다면 다음을 사용할 수 있다:

export FABRIC_CA_CLIENT_HOME=$PWD

the Fabric CA client CLI를 TLS CA admin user 등록을 위해 사용할 준비가 되었다. 아래 명령어를 실행한다:

./fabric-ca-client enroll -d -u https://<ADMIN>:<ADMIN-PWD>@<CA-URL>:<PORT> --tls.certfiles <RELATIVE-PATH-TO-TLS-CERT> --enrollment.profile tls --csr.hosts '<CA_HOSTNAME>' --mspdir tls-ca/tlsadmin/msp

다음과 같이 대체한다:

<ADMIN> : init 커맨드에서 지정한 TLS CA 관리자
<ADMIN-PWD> : init 커맨드에서 지정한 TLS CA 관리자 비밀번호
<CA-URL> : TLS CA 구성파일의 csr 섹션에서 지정한 호스트 이름
<PORT> : TLS CA가 수신대기중인 포트
<RELATIVE-PATH-TO-TLS-CERT> : TLS CA에서 복사해 온 루트 TLS 인증서 파일의 경로와 이름. 이 패스는 FABRIC_CA_CLIENT_HOME의 상대경로이다. 튜토리얼의 폴더 구조를 따를 경우 tls-root-cert/tls-ca-cert.pem가 되어야 한다.
<CA_HOSTNAME> : 콤마로 구분된 인증서가 유효해야 하는 호스트 이름 목록. 지정되지 않으면 구성 파일의 기본값이 사용된다. 도메인에 대한 와일드카드를 사용할 수 있다. 예를 들어 --csr.hosts 'host1,*.example.com' 플래그를 사용한다면 호스트 이름 host1과 도메인 example.com의 모든 호스트가 인식된다. 이 값은 생성된 인증서 대상 대체 이름(certificate Subject Alternative Name; SAN) 속성에 삽입된다. 여기에 지정된 값은 CA서버에 지정한 csr.hosts에 해당된다.

예:

./fabric-ca-client enroll -d -u https://tls-admin:tls-adminpw@my-machine.example.com:7054 --tls.certfiles tls-root-cert/tls-ca-cert.pem --enrollment.profile tls --csr.hosts 'host1,*.example.com' --mspdir tls-ca/tlsadmin/msp

이 경우 -d 파라미터는 클라이언트를 DEBUG 모드에서 동작시켜 등록 실패를 디버깅하기 좋게 한다.

--mspdir 플래그가 enroll 커맨드로 생성된 TLS CA 관리자 인증서가 저장된 위치를 가리키는데에 사용된다.

--enrollment.profile tls 플래그는 TLS CA에 대해 등록을 실행하고 있기 때문에 지정되었다. 이 플래그를 사용한다는 것은 등록이 구성 파일의 signing 섹션에서 정의된 TLS 프로파일의 usage와 expiry에 따라 수행됨을 뜻한다.

참고: TLS CA의 구성파일에서 signing.profiles.ca 블록을 삭제한 경우 --enrollment.profile tls 플래그를 생략할 수 있다.

명령어가 성공적으로 완료되면 fabric-ca-client/tls-ca/tlsadmin/msp 폴더가 생성되고 TLS CA 관리자 신원의 서명 인증서와 개인키가 그 안에 담기게 된다. 어떤 이유로든 enroll 커맨드가 실패할 경우 혼동을 막기 위해 명령어를 다시 실행하기 전에 fabric-ca-client/tls-ca/admin/msp/keystore 폴더의 개인 키를 삭제해야 한다. 이 암호화 자료는 TLS CA에 다른 신원을 기재하기 위해 필요하므로 나중에 참조하게 된다.

팁: 첫 enroll 커맨드를 Fabric CA client에서 사용한 이후, 클라이언트에 의해 사용되는 기본 설정에 친숙해지기 위해 fabric-ca-client/fabric-ca-client-config.yaml 파일을 살펴봐야 한다. 단일 Fabric CA 클라이언트를 여러 CA 서버와 상호작용하기 위해 사용하므로, -u 플래그를 client CLI commands에 사용해 올바른 CA 서버를 타게팅해야 한다. --mspdir 플래그는 register 커맨드에서 사용되는 암호화 자료의 위치와 enroll 명령어로 생성된 인증서가 저장될 위치를 가리킨다.

아래 다이어그램은 TLS CA 서버를 생성하고 Fabric CA 클라이언트를 사용해 부트스트랩 신원을 등록하기 위해 수행한 단계들을 개념적으로 요약한 것이다:

개념도

TLS CA로 조직 CA 부트스트랩 신원(identity) 기재(register) 및 등록(enroll)하기

TLS CA server가 서버에 대한 전체(full) 관리자 권한을 가진 부트스트랩 신원으로 시작되었다. 관리자의 핵심 기능 중 하나는 새 신원을 기재하는 것이다. 네트워크에서 거래를 하고자 하는 조직의 각 노드들은 TLS CA로 기재될 필요가 있다. 따라서 조직 CA를 설정하기 전에 TLS CA를 사용해 조직 CA 부트스트랩 신원이 TLS 인증서와 개인키를 갖도록 신원을 기재하고 등록할 필요가 있다. 아래 커맨드는 TLS CA로 조직 CA 부트스트랩 신원 rcaadmin을 기재한다(비밀번호: rcaadminpw).

./fabric-ca-client register -d --id.name rcaadmin --id.secret rcaadminpw -u https://my-machine.example.com:7054  --tls.certfiles tls-root-cert/tls-ca-cert.pem --mspdir tls-ca/tlsadmin/msp

커맨드의 --mspdir 플래그는 앞선 단계에서 생성한 TLS CA 관리자 MSP 인증서의 위치를 가리킨다. 이 암호화 자료는 TLS CA의 다른 유저들을 기재하기 위해 필요하다.

다음으로 rcaadmin 유저를 등록해 TLS 인증서를 생성해야 한다. 이 경우 enroll 명령어의 --mspdir 플래그는 rcaadmin 유저를 위해 생성된 조직 CA TLS 인증서가 저장되어야 하는 위치를 가리켜야 한다. 이 인증서가 다른 신원을 위한 것이므로 새로운 폴더를 만드는 것이 좋다. 따라서 기본 msp 폴더에 인증서를 생성하기보다는 rcaadmin라는 폴더를 tlsadmin 옆에 새로 만들어 그 안에 인증서를 집어넣는다.

./fabric-ca-client enroll -d -u https://rcaadmin:rcaadminpw@my-machine.example.com:7054 --tls.certfiles tls-root-cert/tls-ca-cert.pem --enrollment.profile tls --csr.hosts 'host1,*.example.com' --mspdir tls-ca/rcaadmin/msp

이 경우 --mspdir 플래그는 조금 다르게 동작한다. enroll 커맨드에서 --mspdir 플래그는 신원의 생성된 인증서가 저장되는 위치를 가리킨다.

중요: 조직 CA TLS 서명 인증서는 fabric-ca-client/tls-ca/rcaadmin/msp/signcert 아래 생성되고 개인키는 fabric-ca-client/tls-ca/rcaadmin/msp/keystore에서 접근가능하다. 조직 CA를 배포할 때 이 두 파일의 위치를 CA 구성 파일의 tls 섹션에서 가리켜야 한다. 참조를 쉽게 하기 위해 keystore 폴더에 있는 파일 이름을 key.pem으로 바꿀 수 있다.

(선택사항) TLS CA로 중간 CA 관리자 기재 및 등록하기

비슷하게, 조직 CA 대신에 인증서를 발급할 수 있는 중간 CA를 계획하고 있다면 중간 CA 관리자 유저 또한 기재하고 등록해야 한다. 다음 커맨드는 icaadmin와 icaadminpw로 TLS CA에서 중간 CA를 기재한다. 신원 이름과 비밀번호 값으로 무엇이든 지정할 수 있다.

./fabric-ca-client register -d --id.name icaadmin --id.secret icaadminpw -u https://my-machine.example.com:7054  --tls.certfiles tls-root-cert/tls-ca-cert.pem --mspdir tls-ca/tlsadmin/msp

다시, register 명령어의 --mspdir 플래그는 TLS CA 관리자 msp 인증서를 가리킨다. 이것은 TLS CA로 다른 유저들을 기재할 때 필요하다.

이제 유저를 등록해 icaadmin 유저의 중간 CA TLS 인증서를 생성한다. enroll 커맨드에서 --mspdir 플래그는 중간 CA TLS 인증서가 저장될 위치를 가리킨다. 이 경우 새 폴더 icaadmin/msp를 생성한다.

./fabric-ca-client enroll -d -u https://icaadmin:icaadminpw@my-machine.example.com:7054 --tls.certfiles tls-root-cert/tls-ca-cert.pem --enrollment.profile tls --csr.hosts 'host1,*.example.com' --mspdir tls-ca/icaadmin/msp

중요: 중간 CA TLS 서명 인증서는 fabric-ca-client/tls-ca/icaadmin/signcert에 저장가능하고 개인키는 fabric-ca-client/tls-ca/icaadmin/keystore에서 접근가능하다. 중간 CA를 배포할 때 이 두 파일들을 중간 CA 구성 파일 tls 섹션에서 참조해야 한다. 참조를 쉽게 하기 위해 keystore 폴더에 있는 파일 이름을 key.pem으로 바꿀 수 있다.

결과 폴더 구조는 다음과 비슷하다:

fabric-ca-client
  └── tls-ca
    └── tlsadmin
      └── msp
    └── rcaadmin
      └── msp
    └── icaadmin
      └── msp
    └── tls-root-cert
      └── tls-ca-cert.pem

팁: 모든 노드를 TLS CA로 기재한 후에는 안전하게 끌 수 있다.

조직 CA 배포

배포 프로세스 개요는 조직 CA와 TLS가 모든 조직에 필요함을 설명한다. TLS CA는 TLS 인증서를 발행해 조직간 통신 보안을 가능하게 한다. 조직 CA는 등록 CA나 ECert CA라고도 불리고 조직의 신원을 발행하기 위해 사용된다. 앞선 단계에서 TLS CA를 배포했으므로 조직 CA 배포 준비가 된 것이다. 나중에는 선택적으로 중간 CA를 생성할 수 있다. 따라서 이 CA는 신뢰 체인의 루트 CA가 된다.

이미 조직 CA 부트스트랩 신원 rcaadmin 를 앞선 단계에서 TLS CA로 기재하고 등록했으므로, 동일한 패턴인 단계를 밟아 CA를 배포할 수 있다.

시작하기 전에

Fabric CA server binary fabric-ca-server를 머신의 새 디렉토리에 복사한다. 이 지침의 목적에 따라 바이너리를 fabric-ca-server-org1라는 폴더에 넣는다.

mkdir fabric-ca-server-org1

이제 fabric-ca-server 바이너리를 폴더에 복사한다.

아래 커맨드를 사용해 앞서 생성한 조직 CA TLS 인증서와 키 페어를 CA서버에서 접근가능한 위치로 복사한다. 예: fabric-ca-server-org1/tls. enroll 커맨드로 생성된 fabric-ca-client/tls-ca/rcaadmin/msp/signcerts/cert.pem 파일과 fabric-ca-client/tls-ca/rcaadmin/msp/keystore/ 파일들이 있다.

참고: 아래 커맨드는 다음을 가정한다:

fabric-ca-client/tls-ca/rcaadmin/msp/keystore/ 아래에 생성된 개인키가 key.pem으로 이름이 바뀌었다.
fabric-ca-client와 fabric-ca-server-org1 폴더는 파일 구조에서 같은 레벨에 있다.

cd fabric-ca-server-org1
mkdir tls
cp ../fabric-ca-client/tls-ca/rcaadmin/msp/signcerts/cert.pem tls && cp ../fabric-ca-client/tls-ca/rcaadmin/msp/keystore/key.pem tls

결과 폴더 구조는 아래 다이어그램과 비슷하다(몇몇 폴더와 파일은 명료성을 위해 생략될 수 있다).

fabric-ca-client
  └── tls-ca
        ├── rcaadmin
          ├── msp
             ├── IssuerPublicKey
             ├── IssuerRevocationPublicKey
             ├── cacerts
             ├── keystore
                 └── key.pem
             ├── signcerts
                 └── cert.pem
fabric-ca-server-org1
  └── tls
    └── cert.pem
    └── key.pem

CA 서버 초기화

서버 초기화를 위해 아래 명령어를 입력한다. 새 관리자 유저 아이디와 패스워드를 지정한다. 여기서는 앞선 단계에서 조직 CA 부트스트랩 신원으로써 기재한 것과 동일한 rcaadmin 신원을 사용한다. 아래 커맨드를 fabric-ca-server-org1 폴더에서 실행한다.

./fabric-ca-server init -b <ADMIN_USER>:<ADMIN_PWD>

예:

./fabric-ca-server init -b rcaadmin:rcaadminpw

CA 서버 구성 수정

TLS CA로 한 것과 같이 생성된 조직 CA의 fabric-ca-server-config.yaml를 수정해 기본 구성 설정을 유스케이스에 맞춰 변경해야 한다.

최소한 아래 수정을 진행해야 한다:

port : 서버가 사용할 포트를 설정한다. 이 지침에선 7055를 사용하지만 다른 포트를 선택할 수 있다.
tls.enabled : true로 설정해 TLS를 활성화한다.
tls.certfile와 tls.keystore : 이 CA의 부트스트랩 관리자가 TLS CA로 등록되었을때 생성된 TLS CA 서명 인증서와 개인키의 상대 경로 및 파일 이름. 서명 인증서 cert.pem은 Fabric CA client로 생성되었고 fabric-ca-client/tls-ca/rcaadmin/msp/signcerts/cert.pem 폴더 아래서 찾을 수 있다. 개인 키는 fabric-ca-client/tls-ca/rcaadmin/msp/keystore에 위치해 있다. 지정된 패스는 FABRIC_CA_CLIENT_HOME의 상대경로이므로 이 지침에서 사용되는 폴더 구조를 따랐다면 tls.certfile에는 tls/cert.pem, tls.keystore는 tls/key.pem이 지정될 수 있다. 또는 적절한 경로를 지정할 수 있다.
ca.name : 이 파라미터에 값을 지정함으로써 조직 CA에 이름을 줄 수 있다(예: org1-ca).
csr.hosts : 파일에 존재하는 것과 다를 경우 이 서버가 구동될 호스트 이름과 ip 주소를 포함시키기 위해 이 파라미터를 업데이트한다.
operations.listenAddress : 호스트에 다른 CA가 구동중일 경우 이 파라미터를 업데이트해 다른 포트를 사용한다.
csr.ca.pathlength : 이 필드는 CA 인증서 계층을 제한하기 위해 사용된다. 루트 CA에서 이 값을 1로 지정하는 것은 루트 CA가 중간 CA 인증서를 발행할 수 있지만, 그 중간 CA들은 다른 CA 인증서를 발행할 수 없다는 뜻이다. 다른 말로 중간 CA가 다른 중간 CA를 등록할 수 없지만, 유저 등록 인증서는 발급할 수 있다. 기본값은 1이다.
signing.profiles.ca.caconstraint.maxpathlen : 이 필드는 인증서 체인에서 해당 인증서를 따르는 스스로 발급하지 않은 중간 인증서(non-self-issued intermediate certificates)의 최대 개수를 나타낸다. 이 서버가 중간 CA의 부모 CA가 되고 중간 CA가 다른 중간 CA의 부모 CA가 되기를 원하는 경우, 이 루트 CA는 0보다 큰 값을 구성 파일에서 가져야 한다. signing 섹션을 확인하자. 기본 값은 0이다.

CA 서버 인증서 삭제

서버를 시작하기 전, 만약 구성 파일의 csr 블록의 어떤 값이든 수정했다면 fabric-ca-server-org1/ca-cert.pem 파일과 전체 fabric-ca-server-org1/msp 폴더를 삭제해야 한다. 인증서는 구성 파일의 새 설정을 기반으로 다음 단계에서 서버를 시작할 때 재 생성될 것이다.

CA 서버 시작

아래 명령어를 실행한다:

./fabric-ca-server start

CA 관리자 등록

CA를 배포하는 마지막 단계는 CA 관리자 부트스트랩 신원을 등록하는 것이다. 이 신원은 노드 서명 인증서와 개인키를 생성한다. 이 키 페어는 관리자 신원이 다른 신원을 등록하기 위해 필요하다. 다시 Fabric CA client CLI 를 사용해 관리자를 등록한다. 이미 필요한 폴더를 클라이언트 섹션에서 준비해두었어야 한다.

폴더 구조는 다음과 같다:

fabric-ca-client
  └── org1-ca
  └── tls-root-cert

이 폴더는 클라이언트가 다음을 하는 데에 사용된다:

Fabric CA client enroll 명령어가 TLS CA server에 대해 실행되었을 때 발행되는 인증서를 저장한다(org1-ca folder).
Fabric CA client가 TLS CA server와 통신할 수 있도록 하는 TLS 인증서가 위치한 장소를 안다(tls-root-cert folder).

Fabric CA client를 TLS CA에 대해 인증서를 생성하기 위해 사용했을 때, FABRIC_CA_CLIENT_HOME 값을 지정했다. 이것이 여전히 지정되어 있어 다음 단계에서 사용할 수 있다고 가정한다. 아니라면 Fabric CA client binary가 있는 디렉토리에서 다음 커맨드를 실행한다:

export FABRIC_CA_CLIENT_HOME=$PWD

이제 Fabric CA client를 관리자 인증서와 개인키를 생성하기 위해 사용할 수 있다. 이 인증서와 개인 키는 이 CA를 사용해 신원을 발급할 때 필요하다. --mspdir 플래그를 등록 커맨드에 실행해 생성된 인증서가 저장될 위치를 지정한다. 다음 명령어를 실행한다:

./fabric-ca-client enroll -d -u https://<ADMIN>:<ADMIN-PWD>@<CA-URL>:<PORT> --tls.certfiles <RELATIVE-PATH-TO-TLS-CERT> --csr.hosts '<CA_HOSTNAME>' --mspdir org1-ca/rcaadmin/msp

다음과 같이 대체한다:

<ADMIN> : init 커맨드에서 지정된 조직 CA 관리자
<ADMIN-PWD> : init 커맨드에서 지정된 조직 CA 관리자 패스워드
<CA-URL> : 조직 CA 구성 파일 csr 섹션에서 지정된 호스트 이름
<PORT> : 조직 CA가 수신대기중인 포트
<RELATIVE-PATH-TO-TLS-CERT> : TLS CA로부터 복사해 온 tls-ca-cert.pem 파일 경로. FABRIC_CA_CLIENT_HOME의 상대경로이다.
<CA_HOSTNAME> : 인증서가 유효해야 하는 콤마로 구분된 호스트 이름 목록. 지정되지 않을 경우 fabric-ca-client-config.yaml의 기본 값이 사용된다. 호스트 이름이 동적이라면 도메인에 대한 와일드카드를 사용할 수 있다. 예를 들어 --csr.hosts 'host1,*.example.com' 플래그를 사용하면 호스트 이름 host1과 example.com의 모든 호스트를 의미한다.

이 경우 -d 파라미터는 커맨드 실패를 디버깅하는데 유용한 디버그 모드로 클라이언트를 구동시킨다.

예:

./fabric-ca-client enroll -d -u https://rcaadmin:rcaadminpw@my-machine.example.com:7055 --tls.certfiles tls-root-cert/tls-ca-cert.pem --csr.hosts 'host1,*.example.com' --mspdir org1-ca/rcaadmin/msp

이 명령어가 실행되면 fabric-ca-client/org1-ca/rcaadmin/msp 폴더를 만들고 조직 CA의 서명 인증서와 개인키를 아래와 같이 저장한다:

└── msp
    ├── cacerts
        └── my-machine-example-com-7055.pem
    ├── keystore
        └── 60b6a16b8b5ba3fc3113c522cce86a724d7eb92d6c3961cfd9afbd27bf11c37f_sk
    ├── signcerts
        └── cert.pem
    ├── user
    ├── IssuerPublicKey
    └── IssuerRevocationPublicKey

my-machine-example-com-7055.pem : 조직 CA 루트 인증서
60b6a16b8b5ba3fc3113c522cce86a724d7eb92d6c3961cfd9afbd27bf11c37f_sk : 조직 CA 관리자 신원의 개인 키. 이 키는 보호되어야 하고 공유되어서는 안된다. 이 CA로 신원을 기재하고 등록할 때 이 키가 필요하다. 참조를 위해 이름을 마음대로 바꾸어도 된다.
cert.pem : CA 관리자 신원의 서명 인증서

(선택사항) 조직 루트 CA로 중간 CA 부트스트랩 신원을 기재한다.

만약 중간 CA를 계획하고 있다면 반드시 중간 CA 부트스트랩 신원을 루트 CA로 기재해 신뢰 체인을 만들어야 한다. 이미 TLS CA로 icaadmin 신원을 만들었다. 같은 신원을 루트 조직 CA로 기재해야 한다. 그리고 이것이 중간 CA이기 때문에, 반드시 hf.IntermediateCA=true 속성을 가져야 한다. (이 명령어를 조직 CA 관리자를 앞서 등록한 것과 같은 터미널 창에서 실행한다)
```
./fabric-ca-client register -u https://my-machine.example.com:7055  --id.name icaadmin --id.secret icaadminpw --id.attrs '"hf.Registrar.Roles=user,admin","hf.Revoker=true","hf.IntermediateCA=true"' --tls.certfiles tls-root-cert/tls-ca-cert.pem --mspdir org1-ca/rcaadmin/msp
```
--mspdir 플래그는 조직 CA 관리자의 암호화 자료를 가리키고 새 유저를 기재하기 위해 검증된다. icaadmin 신원을 조직 CA로 등록하지 않는다. 이 신원은 나중에 중간 CA에서 등록될 것이다.

(선택사항) 중간 CA 배포

중간 CA들은 조직 루트 CA와 신뢰 체인을 만들고 특정 조직을 위해 직접 등록 요청을 단일 CA로 보낸다. 또한 루트 CA를 종료해 신뢰 루트를 보호한다. 즉 모든 등록 요청 과정에 중간 CA가 사용되면 루트 CA를 종료할 수 있다.

참고: 이 섹션은 이미 icaadmin 신원이 TLS CA와 부모 조직 CA로 기재되고 등록되었다고 가정한다.

시작하기 전에

Fabric CA server binary fabric-ca-server 를 머신의 새 디렉토리로 복사한다. 이 지침의 목적에 따라 새 폴더를 만든다.

mkdir fabric-ca-server-int-ca

fabric-ca-server를 폴더 안으로 복사한다.

다음 커맨드를 사용해 CA 관리자 TLS 인증서와 키 페어를 이 CA 서버가 접근가능한 위치로 복사한다. (예: fabric-ca-server-int-ca/tls) fabric-ca-client/tls-ca/icaadmin/msp/signcerts/cert.pem 와 fabric-ca-client/tls-ca/icaadmin/msp/keystore/ 파일들이 enroll 커맨드에 의해 생성되었을 것이다.

참고: 아래 커맨드는 다음을 가정한다:

fabric-ca-client/tls-ca/icaadmin/keystore/에 생성된 개인키는 key.pem로 이름이 변경되었다.
fabric-ca-client 와 fabric-ca-server-int-ca 폴더가 파일 구조에서 동일한 레벨에 있다.

cd fabric-ca-server-int-ca
mkdir tls
cp ../fabric-ca-client/tls-ca/icaadmin/msp/signcerts/cert.pem tls && cp ../fabric-ca-client/tls-ca/icaadmin/msp/keystore/key.pem tls

TLS 통신이 활성화되었으므로 부모 조직 CA와의 통신 보안을 위해 중간 CA는 TLS CA 루트 인증서를 필요로 한다. 즉, TLS CA 서버가 초기화되었을 때 생성된 fabric-ca-server-tls/ca-cert.pem 를 tls 폴더로 복사해야 한다. 이 파일 이름은 이 인증서가 TLS CA에서 왔음을 명확하게 보여주기 위해서 tls-ca-cert.pem로 변경되었다.

cp ../fabric-ca-server-tls/ca-cert.pem tls/tls-ca-cert.pem

결과 폴더 구조는 다음 구조와 비슷하다(몇몇 폴더와 파일들은 명료성을 위해 생략될 수 있다):

fabric-ca-client
  └── tls-ca
        ├── icaadmin
          ├── msp
             ├── cacerts
             ├── keystore
                 └── key.pem
             ├── signcerts
                 └── cert.pem
             ├── tlscacerts
             ├── user
             ├── IssuerPublicKey
             └── IssuerRevocationPublicKey
fabric-ca-server-int-ca
  └── tls
    └── tls-ca-cert.pem
    └── cert.pem
    └── key.pem

부모 조직 루트 CA를 이미 배포하였으므로 중간 CA를 생성하는 다음 단계를 사용할 수 있다.

중간 CA 홈 디렉토리에서 init 커맨드를 실행하고 이미 TLS CA와 부모 조직 CA에 기입한 icaadmin 아이디를 부트스트래핑함으로써 CA를 초기화한다.

./fabric-ca-server init -b icaadmin:icaadminpw

fabric-ca-server-config.yaml 파일을 수정한다.

port : 서버가 사용할 포트를 설정한다. 이 지침에선 7056를 사용하지만 다른 포트를 선택할 수 있다.
tls.enabled : true로 반드시 설정한다.
tls.certfile와 tls.keystore : 이 CA의 부트스트랩 관리자(icaadmin)가 TLS CA로 등록되었을때 생성된 TLS CA 서명 인증서와 개인키의 상대 경로 및 파일 이름. 서명 인증서 cert.pem은 Fabric CA client로 생성되었고 fabric-ca-client/tls-ca/icaadmin/msp/signcerts/cert.pem 폴더 아래서 찾을 수 있다. 개인 키는 fabric-ca-client/tls-ca/icaadmin/msp/keystore에 위치해 있다. 지정된 패스는 FABRIC_CA_CLIENT_HOME의 상대경로이므로 이 지침에서 사용되는 폴더 구조를 따랐다면 tls.certfile에는 tls/cert.pem, tls.keystore는 tls/key.pem이 지정될 수 있다. 또는 적절한 경로를 지정할 수 있다.
ca : CA에 이름을 줄 수 있다(예: ica).
signing.profiles.ca.caconstraint.maxpathlen : 이 값을 0으로 지정하는 것은 이 CA 아래에 더 많은 중간 CA가 오지 않는다는 것을 뜻한다. 기본 값은 0이다.
csr.cn : 중간 CA를 위한 common name이 반드시 비어있어야 한다.
csr.ca.pathlength : 0으로 설정한다.
intermediate.parentserver.url : 부모 서버 USL 값을 입력한다. 형식은 https://<ROOT-CA-ADMIN>:<ROOT-CA-ADMIN-PW>@<CA-URL>:<PORT>와 같다(예: https://rcaadmin:rcaadminpw@my-machine.example.com:7055).
intermediate.parentserver.caname : 부모 조직 CA 구성파일의 caname 값을 입력한다. 튜토리얼에서는 org1-ca이다.
intermediate.enrollment.hosts : 중간 CA 서버가 수신대기하는 호스트 이름
intermediate.enrollment.profile : 인증서 발급에 사용하기 위해 signing.profile 섹션에서 온 서명 프로파일 이름을 입력한다. 일반적으로 이 값은 ca이다.
intermediate.tls.certfiles : TLS CA root tls-ca-cert.pem 파일의 경로와 파일 이름을 입력한다. 이 지침에서 사용하는 폴더 구조를 따랐다면 tls/tls-ca-cert.pem 이다.
operations.listenAddress : 호스트에 다른 CA가 구동중일 경우 이 파라미터를 업데이트해 다른 포트를 사용한다.

중요: 반드시 중간 CA의 fabric-ca-server-int-ca/ca-cert.pem와 fabric-ca-server-int-ca/msp 파일들을 삭재해 중간 CA 설정과 함께 파일들이 재생성되도록 해야 한다.
중간 CA 서버를 시작한다. CA가 시작되었을 때 중간 CA 부트스트랩 신원이 부모 조직 루트 CA로 등록되므로 중간 CA를 시작하기 전에 부모 조직 CA가 구동 중인지 확인한다.

./fabric-ca-server start

중간 CA 서버이므로 ca-chain.pem 파일이 생성된다. 이 파일은 인증서 체인을 담고 있고 중간 CA ca-cert.pem과 루트 CA ca-cert.pem을 포함하고 있다.

중간 CA 관리자

중간 CA 배포의 마지막 단계는 노드 서명 인증서와 개인 키를 생성하기 위해 중간 CA 관리자를 등록하는 것이다. 이것은 다른 신원을 등록하기 위해 필요하다. 클라이언트 섹션에서 필요한 폴더를 준비해 놓았어야 한다.

이 커맨드에서 사용하는 폴더 스트럭처는 다음과 같다:

fabric-ca-client
  └── int-ca
  └── tls-root-cert

이 폴더들은 패브릭 CA 클라이언트가 다음을 수행하는데에 사용된다:

Fabric CA client enroll 명령어가 TLS CA server에 대해 실행되었을 때 발행되는 인증서를 저장한다(int-ca folder).
Fabric CA client가 TLS CA server와 통신할 수 있도록 하는 TLS 인증서가 위치한 장소를 안다(tls-root-cert folder).

TLS CA와 중간 CA에 인증서를 생성하기 위해 Fabric CA client를 사용했을 때, FABRIC_CA_CLIENT_HOME 값을 지정했다. 이것이 여전히 지정되어 있어 다음 단계에서 사용할 수 있다고 가정한다. 아니라면 Fabric CA client binary가 있는 디렉토리에서 다음 커맨드를 실행한다:

export FABRIC_CA_CLIENT_HOME=$PWD

이제 Fabric CA client를 CA 관리자 인증서와 개인키를 생성하기 위해 사용할 수 있다. 이 인증서와 개인 키는 이 CA를 사용해 신원을 발급할 때 필요하다. --mspdir 플래그를 enroll 커맨드에 실행해 생성된 인증서가 저장될 위치를 지정한다. 다음 명령어를 실행한다:

./fabric-ca-client enroll -d -u https://<ADMIN>:<ADMIN-PWD>@<CA-URL>:<PORT> --tls.certfiles <RELATIVE-PATH-TO-TLS-CERT> --csr.hosts '<CA_HOSTNAME>' --mspdir int-ca/icaadmin/msp

다음과 같이 대체한다:

<ADMIN> : init 커맨드에서 지정된 조직 CA 관리자
<ADMIN-PWD> : init 커맨드에서 지정된 조직 CA 관리자 패스워드
<CA-URL> : CA 구성 파일 csr 섹션에서 지정된 호스트 이름
<PORT> : CA가 수신대기중인 포트
<RELATIVE-PATH-TO-TLS-CERT> : TLS CA로부터 복사해 온 tls-ca-cert.pem 파일 경로. FABRIC_CA_CLIENT_HOME의 상대경로이다.
<CA_HOSTNAME> : 인증서가 유효해야 하는 콤마로 구분된 호스트 이름 목록. 지정되지 않을 경우 fabric-ca-client-config.yaml의 기본 값이 사용된다. 호스트 이름이 동적이라면 도메인에 대한 와일드카드를 사용할 수 있다. 예를 들어 --csr.hosts 'host1,*.example.com' 플래그를 사용하면 호스트 이름 host1과 example.com의 모든 호스트를 의미한다.

예:

./fabric-ca-client enroll -d -u https://icaadmin:icaadminpw@my-machine.example.com:7056 --tls.certfiles tls-root-cert/tls-ca-cert.pem --csr.hosts 'host1,*.example.com' --mspdir int-ca/icaadmin/msp

이 커맨드를 실행하면 fabric-ca-client/int-ca/icaadmin/msp 폴더가 만들어지고 중간 CA의 인증서와 개인키가 담긴다. /intermediatecerts 폴더가 함께 만들어지고 이 중간 CA를 루트 CA로 연결시키는 중간 CA 인증서로 채워진다.

팁: 중간 CA가 성공적으로 배포된 다음 신원을 기재하고 등록할 수 있다. 안전하게 부모 조직 루트 CA를 종료시킬 수 있다.

다음 단계

최소한 TLS CA와 중간 CA가 조직을 위해 구성되었을 것이다. 이제 CA 클라이언트를 이용해 노드 관리자 신원, 노드 신원, 조직 신원을 TLS CA로 기재하고 등록해 서버 사이드 TLS 통신에 필요한 TLS 인증서들을 만들 수 있다. 마찬가지로 같은 노드 관리자와 유저들을 조직 CA로 기재하고 등록해 등록 인증서와 MSP들을 생성할 수 있다. 더 많은 정보는 신원과 MSP 생성을 위해 CA 사용하기를 참고하자. 만약 중간 CA를 구성했다면 중간 CA를 사용해 조직의 신원들을 기재하고 등록할 수 있다.

팁: 이후 중간 CA를 이용해 신원을 기재할 경우 기재 커맨드에 --mspdir int-ca/icaadmin/msp가 지정되었는지 확인해야 한다.

CA 배포 문제 해결

Fabric CA client enroll 커맨드 실패

문제: Fabric CA client CLI로 enroll 커맨드를 실행했을 때 다음과 같이 실패한다:

Error: Failed to read config file at '/Users/mwp/.fabric-ca-client/fabric-ca-client-config.yaml': While parsing config: yaml: line 42: mapping values are not allowed in this context

해결책:

이 에러는 FABRIC_CA_CLIENT_HOME이 지정되지 않을 때 일어난다. FABRIC_CA_CLIENT_HOME환경변수를 Fabric CA client binary를 가리키도록 설정했는지 확인한다. fabric-ca-client.exe 바이너리 파일이 있는 폴더로 이동해 아래 커맨드를 실행한다:

export FABRIC_CA_CLIENT_HOME=$PWD

FABRIC_CA_CLIENT_HOME이 설정되고 등록 커맨드가 실패했을 경우 생성된 FABRIC_CA_CLIENT_HOME/msp 폴더와 fabric-ca-client.yaml 파일을 삭제해 등록 커맨드를 다시 실행할 때 혼동이 없도록 한다.

Intermediate CA server 시작 실패

문제: 중간 CA가 다음 에러와 함께 시작 실패

Error: Response from server: Error Code: 0 - Certificate signing failure: {"code":5300,"message":"Policy violation request"}

다음 에러를 루트 CA에서 함께 볼 수 있을 것이다:

[ERROR] local signer certificate disallows CA MaxPathLen extending
[INFO] 9.27.117.220:49864 POST /enroll 500 0 "Certificate signing failure: {"code":5300,"message":"Policy violation request"}"

해결책: 중간 CA 구성 파일의signing.profiles.ca.caconstraint.maxpathlen와 csr.ca.pathlength 값을 0으로 설정해야 한다.

중간 CA 시작 실패

문제: 중간 CA를 시작하려고 하면 다음 에러와 함께 실패한다

Post https://host1.com:7060/enroll: x509: certificate signed by unknown authority

루트 조직 CA에서는 다음 에러가 나타난다:

TLS handshake error from 192.168.1.134:63094: remote error: tls: bad certificate

해결책: 이 문제는 중간 CA가 시작되고 중간 CA 관리자 유저를 루트 CA로 등록하는 도중에 나타난다. 이 문제를 해결하기 위해서는 중간 CA 구성 파일의 intermediate.tls.certfiles 섹션에 지정된 TLS 인증서가 TLS CA 루트 인증서를 가리키고 있는지 확인한다. 이 지침을 따랐을 경우 위치는 tls/tls-ca-cert.pem가 된다.

중간 CA 관리자 유저 등록 실패

문제: 중간 CA를 시작하고 다음 에러와 함께 프로세스가 실패한다:

Error: Response from server: Error Code: 0 - Chain file does not exist at /fabric-ca-server-int-ca/ca-chain.pem

해결책: 중간 CA 구성 파일의 csr 블록을 수정하였으므로 중간 CA ca-cert.pem 파일과 msp 폴더를 중간 CA 서버를 시작하기 전에 삭제해야 한다.

CA Deployment steps

Hyperledger Fabric CA

CA 배포 단계

바이너리 다운로드

서버 바이너리 파일

클라이언트 바이너리 파일

Fabric CA client

CLI에서 트랜잭션 제출

어떤 순서로 CA들을 배포해야 하는가?

TLS CA 배포

시작하기 전에

TLS CA 서버 초기화

CA 서버 `init` 명령어가 무슨 일을 하는가?

TLS CA 서버 구성 수정

TLS CA 서버 인증서 삭제

TLS CA 서버 시작

TLS CA로 부트스트래핑 유저 등록하기

TLS CA로 조직 CA 부트스트랩 신원(identity) 기재(register) 및 등록(enroll)하기

(선택사항) TLS CA로 중간 CA 관리자 기재 및 등록하기

조직 CA 배포

시작하기 전에

CA 서버 초기화

CA 서버 구성 수정

CA 서버 인증서 삭제

CA 서버 시작

CA 관리자 등록

(선택사항) 중간 CA 배포

시작하기 전에

중간 CA 관리자

다음 단계

CA 배포 문제 해결

Fabric CA client enroll 커맨드 실패

Intermediate CA server 시작 실패

중간 CA 시작 실패

중간 CA 관리자 유저 등록 실패

프로덕션 CA 서버를 위한 체크리스트

Registering and enrolling identities with a CA

0개의 댓글

CA Deployment steps

Hyperledger Fabric CA

CA 배포 단계

바이너리 다운로드

서버 바이너리 파일

클라이언트 바이너리 파일

Fabric CA client

CLI에서 트랜잭션 제출

어떤 순서로 CA들을 배포해야 하는가?

TLS CA 배포

시작하기 전에

TLS CA 서버 초기화

CA 서버 init 명령어가 무슨 일을 하는가?

TLS CA 서버 구성 수정

TLS CA 서버 인증서 삭제

TLS CA 서버 시작

TLS CA로 부트스트래핑 유저 등록하기

TLS CA로 조직 CA 부트스트랩 신원(identity) 기재(register) 및 등록(enroll)하기

(선택사항) TLS CA로 중간 CA 관리자 기재 및 등록하기

조직 CA 배포

시작하기 전에

CA 서버 초기화

CA 서버 구성 수정

CA 서버 인증서 삭제

CA 서버 시작

CA 관리자 등록

(선택사항) 중간 CA 배포

시작하기 전에

중간 CA 관리자

다음 단계

CA 배포 문제 해결

Fabric CA client enroll 커맨드 실패

Intermediate CA server 시작 실패

중간 CA 시작 실패

중간 CA 관리자 유저 등록 실패

프로덕션 CA 서버를 위한 체크리스트

Registering and enrolling identities with a CA

0개의 댓글

CA 서버 `init` 명령어가 무슨 일을 하는가?