<div id="readability-page-1" class="page"><div><p>Hyperledger Fabric을 구성하는 Orderer와 Peer는 <code>msp</code>와 <code>tls</code> 키를 갖고 있다. 이 키들은 <code>cryptogen</code>을 이용하여 키를 생성하거나, Fabric CA 서버에 <code>enroll</code> 하여 얻을 수 있다. <code>cryptogen</code> 을 이용하여 생성하면, 인증서 만료 값이 매우 길기 때문에(10년인가 15년인가로 알고 있다) 걱정할 필요가 없지만, Fabric CA의 경우 <code>fabric-ca-server-config.yaml</code> 파일을 수정하지 않는한 기본 1년으로 설정되어 있다. 그렇기 때문에 네트워크가 중단되는 사태를 맞지 않으려면, 1년마다 반드시 갱신을 해주어야 한다.</p>
<p>참고로, <code>msp</code>는 만료가 되어도 네트워크가 정상 작동한다. 하지만 <code>msp</code>가 만료된 Orderer 또는 Peer 프로세스를 중단시키면, 다시 실행시킬 수 없다. 즉, <code>msp</code> 가 만료되어도 최소한의 데이터 백업 등을 위해 네트워크에서 바로 퇴출시키지 않고 유예시켜주는 것이다. 반면에 <code>tls</code>는 만료되는 순간 즉각 퇴출된다. <code>tls</code>는 말 그대로 TLS 통신을 위한 것이기 때문에, 인증서가 만료되면 애초에 Orderer와 Peer들 사이에 통신이 불가능해진다.</p>
<p>Hyperledger Fabric의 키를 갱신하는 과정은 다음과 같다.</p>
<ol>
<li>Fabric CA 서버로부터 새로운 키들을 다운받는다.</li>
<li>Orderer 키를 갱신한다. 반드시 1개씩 순차적으로 진행해야 한다.</li>
<li>Peer 키를 갱신한다. 한번에 해도 관계없다.</li>
</ol>
<p>위의 과정은 내가 StackOverflow에 올린 <a href="https://stackoverflow.com/questions/67072278/tls-certificate-renewal-deadlock-among-raft-orderers-after-expiry">질문글</a>에 <a href="https://stackoverflow.com/users/8211613/yacovm">yacovm</a>님이 달아주신 댓글을 통해 알게 되었다.</p>
<p>참고로 아래의 모든 과정은 Fabric CA 1.4.4 버전, Hyperledger Fabric 2.2 버전에서 진행했다.</p>
<h2 id="새로운-키-준비">새로운 키 준비</h2>
<p>당연하지만, 우선 새로운 키가 필요하다. 키를 새로 발급 받는 방법은 처음에 Fabric CA로부터 <code>msp</code>와 <code>tls</code> 를 받을 때 했던 방법 그대로 수행하면 된다. <code>reenroll</code> 을 굳이 안 써도 되고, 그냥 마치 처음 하는 것처럼 <code>enroll</code>을 통해 받으면 된다. <code>register</code>는 (당연한 말이지만) 할 필요 없다. 처음에 등록한 노드 ID, 비밀번호를 이용하여 <code>enroll</code> 만 다시 받으면 된다. 새로운 키를 받았다면, 어디 한 구석에 잘 저장해두자.</p>
<h2 id="orderer-키-갱신">Orderer 키 갱신</h2>
<p>Orderer의 키를 갱신하는 건 복잡하고, 사실 이게 핵심이다. 단순히 Orderer의 키를 바꿔칠 뿐 아니라, Channel의 Configuration 값을 수정해야하기 때문이다.</p>
<p>Hyperledger Fabric의 Channel 블록에는 해당 Channel에 참여하는 Orderer들의 노드 ID, <code>tls/signcerts</code> 값을 저장하고 있다. <code>tls/signcerts</code> 값은 우리가 갱신해야 하는 값에 해당하기 때문에, Channel Config Update 절차를 통해, 해당 값을 갱신해주어야 한다.</p>
<p>Channel Config Update 절차는 <a href="https://hyperledger-fabric.readthedocs.io/en/release-2.2/config_update.html#editing-a-config">공식 문서</a>에 잘 정리가 되어 있다. 해당 내용을 요약하면 대충 다음과 같다.</p>
<ol>
<li>채널에 참가하고 있는 Peer를 통해, Channel Config를 가져온다.</li>
<li>Channel Config 를 json 형태로 변경하여, 내용을 수정한다.</li>
<li>기존 Channel Config 와 변경된 내용을 비교하여 변경점을 찾는다.</li>
<li>이 변경점에 대한 Channel Update envelope을 생성한다.</li>
<li>Channel Update envelope 을 <code>peer channel update</code> 명령어를 통해 Orderer에게 전송한다.</li>
</ol>
<p>2~4번 과정은 <code>configtxlator</code> 를 통해 <code>proto-buf</code> 형태의 Channel Config 파일을 json으로 변경하고, 이걸 다시 <code>proto-buf</code> 파일로 인코딩하는 과정들의 반복으로 구성되어 있다. 또한 <a href="https://stedolan.github.io/jq/"><code>jq</code></a>가 있으면 꽤 편하니, 미리 준비하도록 하자.</p>
<p>공식 문서를 참고하여 진행하다보면, 이제 json 파일을 수정해야 하는 단계에 올 것이다. 공식 문서의 "Step 2: Modify the config" 단계에 왔다면, 이제 내용을 수정해야 하는데 주의해야 할 점이 있다.</p>
<p>우선 수정해야 할 내용은 <code>channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters</code>에 있다. 여기 보면 Orderer 들이 배열로 정의되어 있는데,<code>client_tls_cert</code>와 <code>server_tls_cert</code> 값을 수정하면 된다. 참고로, <code>channel_group.groups.Orderer.values.ConsensusType.value</code> 위치의 <code>BatchSize</code>, <code>BatchTimeout</code> 등도 변경 가능한 값들이니 알아두도록 하자.</p>
<p><code>client_tls_cert</code>와 <code>server_tls_cert</code> 값은 <code>tls/signcerts</code> 폴더의 인증서 값을 넣으면 되는데, <code>client_tls_cert</code>와 <code>server_tls_cert</code> 모두 같은 값을 넣으면 된다. 다만, 해당 인증서를 base64로 인코딩해야 하는데, 방법은 다음과 같다.</p>
<pre><code>base64 tls/signcerts/cert.pem <span>|</span> <span>sed</span> <span>':a;N;<span>$!</span>ba;s/<span>\n</span>//g'</span></code></pre>
<p>이를 통해 얻은 값을 <code>client_tls_cert</code>와 <code>server_tls_cert</code>에 붙여넣고, 저장한 후 나머지 과정을 진행하면 된다. 위의 base64 내용은 yacovm 님이 안내해주신 <a href="https://github.com/SmartBFT-Go/fabric-samples/blob/release-1.4-BFT/first-network/scripts/bftutil.sh">GitHub 저장소</a>에서 알 수 있었다.</p>
<p><code>peer channel update</code> 를 통해 Channel Config 가 잘 업데이트 되면, 이제 키 값을 갱신한 Orderer에 새로운 <code>msp</code>, <code>tls</code> 값을 준다. 보통은 그냥 해당 폴더를 교체하고, Orderer 프로세스(보통 도커 컨테이너)를 재시작해주면 된다.</p>
<h2 id="orderer-키-갱신-시-주의할-점">Orderer 키 갱신 시 주의할 점</h2>
<p>RAFT 에서는 적어도 3개의 Orderer를 쓰는데, 이를 한번에 업데이트 하면 절대 안된다. 그렇게 되면, 모두가 서로를 알아보지 못하는 데드록에 빠질 수 있다. 그래서 1개의 Orderer에 대해 위의 과정을 모두 완료한 후, 다음 Orderer에 대해 Channel Config fetch부터 전부 다시 진행해주어야 한다. 그렇게 순차적으로 진행해야 Orderer들이 서로를 인식할 수 있게 된다. 그렇기 때문에 RAFT 에서는 위의 과정을 적어도 3번 반복해야 한다.</p>
<h2 id="peer-키-갱신">Peer 키 갱신</h2>
<p>Peer 키 갱신은 상대적으로 쉽다. 그저 <code>msp</code>와 <code>tls</code> 폴더를 새로운 키로 교체한 후 프로세스 또는 도커 컨테이너를 재시작해주면 된다.</p>
<h2 id="키가-이미-만료된-경우">키가 이미 만료된 경우</h2>
<p>이게 사실 문제다. 나 같은 경우, 처음으로 인증서 만료에 직면했던 Fabric 체인은 이미 키가 만료된 상태였다. 갑자기 Fabric 네트워크가 동작을 안해서 가보니 이미 인증서가 만료되어 버린 것... 이때는 완전 맨붕에 빠져서 결국 새 네트워크를 띄우고 모든 블록체인 내용을 옮긴 후 기존 것을 버렸었다. 내용은 살렸지만, 그간 내역이 모두 날라가서 어찌보면 블록체인의 의미를 상실한 것이 되어버렸다. 그래서 같은 경우를 겪지 않기 위해, <a href="https://stackoverflow.com/questions/67072278/tls-certificate-renewal-deadlock-among-raft-orderers-after-expiry">StackOverflow</a> 와 Hyperledger Chat 커뮤니티를 통해 조사한 결과 위의 절차를 알게 되었던 것이다.</p>
<p>위의 모든 과정에서 "키가 이미 만료된 경우"는 Orderer에 대해 다음 몇가지 설정을 추가해서 Orderer를 재시작해주어야 한다.</p>
<ul>
<li><code>General.Cluster.TLSHandshakeTimeShift</code> 설정</li>
<li><code>General.Authentication.NoExpirationChecks</code> 설정</li>
</ul>
<p>그리고 Peer 가 Orderer에게 Channel Update 트랜잭션을 보낼 때 <code>--tlsHandshakeTimeShift</code> 옵션을 함께 설정해주어야 한다.</p>
<p><code>TLSHandshakeTimeShift</code>의 경우, 해당 시간만큼 <code>tls</code> 인증서의 만료 기간을 연장하는 것을 말한다. 그래서 가령 만료된지 2일이 지났다면, <code>TLSHandshakeTimeShift</code> 값은 적어도 <code>48h</code> 이상이 되어야 한다.</p>
<p><code>NoExpirationChecks</code>의 경우, Orderer가 <code>msp</code>에 대해 만료 체크를 하지 않는 것을 말한다 (<a href="https://hyperledger-fabric.readthedocs.io/en/latest/raft_configuration.html#certificate-expiration-related-authentication">공식문서</a>).</p>
<p>이 경우에 대한 논의는 Hyperledger의 공식 JIRA의 <a href="https://jira.hyperledger.org/browse/FAB-18384">이슈</a>에 자세히 나와있으니 참고하자.</p></div></div>

byron1st.log

안휘

Hyperledger Fabric을 구성하는 Orderer와 Peer는 msp와 tls 키를 갖고 있다. 이 키들은 cryptogen을 이용하여 키를 생성하거나, Fabric CA 서버에 enroll 하여 얻을 수 있다. cryptogen 을 이용하여 생성하면, 인증서 만료 값이 매우 길기 때문에(10년인가 15년인가로 알고 있다) 걱정할 필요가 없지만, Fabric CA의 경우 fabric-ca-server-config.yaml 파일을 수정하지 않는한 기본 1년으로 설정되어 있다. 그렇기 때문에 네트워크가 중단되는 사태를 맞지 않으려면, 1년마다 반드시 갱신을 해주어야 한다.
참고로, msp는 만료가 되어도 네트워크가 정상 작동한다. 하지만 msp가 만료된 Orderer 또는 Peer 프로세스를 중단시키면, 다시 실행시킬 수 없다. 즉, msp 가 만료되어도 최소한의 데이터 백업 등을 위해 네트워크에서 바로 퇴출시키지 않고 유예시켜주는 것이다. 반면에 tls는 만료되는 순간 즉각 퇴출된다. tls는 말 그대로 TLS 통신을 위한 것이기 때문에, 인증서가 만료되면 애초에 Orderer와 Peer들 사이에 통신이 불가능해진다.
Hyperledger Fabric의 키를 갱신하는 과정은 다음과 같다.
Fabric CA 서버로부터 새로운 키들을 다운받는다.
Orderer 키를 갱신한다. 반드시 1개씩 순차적으로 진행해야 한다.
Peer 키를 갱신한다. 한번에 해도 관계없다.
위의 과정은 내가 StackOverflow에 올린 질문글에 yacovm님이 달아주신 댓글을 통해 알게 되었다.
참고로 아래의 모든 과정은 Fabric CA 1.4.4 버전, Hyperledger Fabric 2.2 버전에서 진행했다.
새로운 키 준비
당연하지만, 우선 새로운 키가 필요하다. 키를 새로 발급 받는 방법은 처음에 Fabric CA로부터 msp와 tls 를 받을 때 했던 방법 그대로 수행하면 된다. reenroll 을 굳이 안 써도 되고, 그냥 마치 처음 하는 것처럼 enroll을 통해 받으면 된다. register는 (당연한 말이지만) 할 필요 없다. 처음에 등록한 노드 ID, 비밀번호를 이용하여 enroll 만 다시 받으면 된다. 새로운 키를 받았다면, 어디 한 구석에 잘 저장해두자.
Orderer 키 갱신
Orderer의 키를 갱신하는 건 복잡하고, 사실 이게 핵심이다. 단순히 Orderer의 키를 바꿔칠 뿐 아니라, Channel의 Configuration 값을 수정해야하기 때문이다.
Hyperledger Fabric의 Channel 블록에는 해당 Channel에 참여하는 Orderer들의 노드 ID, tls/signcerts 값을 저장하고 있다. tls/signcerts 값은 우리가 갱신해야 하는 값에 해당하기 때문에, Channel Config Update 절차를 통해, 해당 값을 갱신해주어야 한다.
Channel Config Update 절차는 공식 문서에 잘 정리가 되어 있다. 해당 내용을 요약하면 대충 다음과 같다.
채널에 참가하고 있는 Peer를 통해, Channel Config를 가져온다.
Channel Config 를 json 형태로 변경하여, 내용을 수정한다.
기존 Channel Config 와 변경된 내용을 비교하여 변경점을 찾는다.
이 변경점에 대한 Channel Update envelope을 생성한다.
Channel Update envelope 을 peer channel update 명령어를 통해 Orderer에게 전송한다.
2~4번 과정은 configtxlator 를 통해 proto-buf 형태의 Channel Config 파일을 json으로 변경하고, 이걸 다시 proto-buf 파일로 인코딩하는 과정들의 반복으로 구성되어 있다. 또한 jq가 있으면 꽤 편하니, 미리 준비하도록 하자.
공식 문서를 참고하여 진행하다보면, 이제 json 파일을 수정해야 하는 단계에 올 것이다. 공식 문서의 "Step 2: Modify the config" 단계에 왔다면, 이제 내용을 수정해야 하는데 주의해야 할 점이 있다.
우선 수정해야 할 내용은 channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters에 있다. 여기 보면 Orderer 들이 배열로 정의되어 있는데,client_tls_cert와 server_tls_cert 값을 수정하면 된다. 참고로, channel_group.groups.Orderer.values.ConsensusType.value 위치의 BatchSize, BatchTimeout 등도 변경 가능한 값들이니 알아두도록 하자.
client_tls_cert와 server_tls_cert 값은 tls/signcerts 폴더의 인증서 값을 넣으면 되는데, client_tls_cert와 server_tls_cert 모두 같은 값을 넣으면 된다. 다만, 해당 인증서를 base64로 인코딩해야 하는데, 방법은 다음과 같다.
base64 tls/signcerts/cert.pem | sed ':a;N;$!ba;s/\n//g'
이를 통해 얻은 값을 client_tls_cert와 server_tls_cert에 붙여넣고, 저장한 후 나머지 과정을 진행하면 된다. 위의 base64 내용은 yacovm 님이 안내해주신 GitHub 저장소에서 알 수 있었다.
peer channel update 를 통해 Channel Config 가 잘 업데이트 되면, 이제 키 값을 갱신한 Orderer에 새로운 msp, tls 값을 준다. 보통은 그냥 해당 폴더를 교체하고, Orderer 프로세스(보통 도커 컨테이너)를 재시작해주면 된다.
Orderer 키 갱신 시 주의할 점
RAFT 에서는 적어도 3개의 Orderer를 쓰는데, 이를 한번에 업데이트 하면 절대 안된다. 그렇게 되면, 모두가 서로를 알아보지 못하는 데드록에 빠질 수 있다. 그래서 1개의 Orderer에 대해 위의 과정을 모두 완료한 후, 다음 Orderer에 대해 Channel Config fetch부터 전부 다시 진행해주어야 한다. 그렇게 순차적으로 진행해야 Orderer들이 서로를 인식할 수 있게 된다. 그렇기 때문에 RAFT 에서는 위의 과정을 적어도 3번 반복해야 한다.
Peer 키 갱신
Peer 키 갱신은 상대적으로 쉽다. 그저 msp와 tls 폴더를 새로운 키로 교체한 후 프로세스 또는 도커 컨테이너를 재시작해주면 된다.
키가 이미 만료된 경우
이게 사실 문제다. 나 같은 경우, 처음으로 인증서 만료에 직면했던 Fabric 체인은 이미 키가 만료된 상태였다. 갑자기 Fabric 네트워크가 동작을 안해서 가보니 이미 인증서가 만료되어 버린 것... 이때는 완전 맨붕에 빠져서 결국 새 네트워크를 띄우고 모든 블록체인 내용을 옮긴 후 기존 것을 버렸었다. 내용은 살렸지만, 그간 내역이 모두 날라가서 어찌보면 블록체인의 의미를 상실한 것이 되어버렸다. 그래서 같은 경우를 겪지 않기 위해, StackOverflow 와 Hyperledger Chat 커뮤니티를 통해 조사한 결과 위의 절차를 알게 되었던 것이다.
위의 모든 과정에서 "키가 이미 만료된 경우"는 Orderer에 대해 다음 몇가지 설정을 추가해서 Orderer를 재시작해주어야 한다.
General.Cluster.TLSHandshakeTimeShift 설정
General.Authentication.NoExpirationChecks 설정
그리고 Peer 가 Orderer에게 Channel Update 트랜잭션을 보낼 때 --tlsHandshakeTimeShift 옵션을 함께 설정해주어야 한다.
TLSHandshakeTimeShift의 경우, 해당 시간만큼 tls 인증서의 만료 기간을 연장하는 것을 말한다. 그래서 가령 만료된지 2일이 지났다면, TLSHandshakeTimeShift 값은 적어도 48h 이상이 되어야 한다.
NoExpirationChecks의 경우, Orderer가 msp에 대해 만료 체크를 하지 않는 것을 말한다 (공식문서).
이 경우에 대한 논의는 Hyperledger의 공식 JIRA의 이슈에 자세히 나와있으니 참고하자.

Hyperledger Fabric 인증서 갱신하기

댓글