Hyperledger Fabric: Как можно ожидать, что пользователь будет иметь сертификаты других организаций при попытке вызвать цепной код?

Question

Когда пользователь вызывает цепной код, ему необходимо передать равноправные адреса, по которым цепной код будет оцениваться для подтверждения. Если TLS включен, то пользователю также необходимо иметь сертификаты CA для пиров, указанных выше. Например, скажем, есть три организации A, B, C. Политика одобрения требует одобрения от каждой из этих организаций. Пользователь в организации А хочет вызвать цепной код. Им нужно будет выполнить вызов одноранговой цепочки , передавая адреса одноранговых узлов так, чтобы был включен одноранговый узел из каждой организации. Все в порядке. Но если TLS включен, то ожидается, что пользователь также будет включать в себя сертификат CA TLS каждой организации (используя опцию --tlsRootCertFiles), в противном случае вызов не будет выполнен. Насколько это разумно? И как пользователь может получить сертификат TLS CA других организаций? На практике, как это будет приобретено?

Answer 1

Как это разумно?

Чтобы пояснить причину, по которой был задан этот вопрос, при вызове peer chaincode invoke необходимо передать CORE_PEER_ADDRESS, в противном случае возникает ошибка:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x110fddc]

goroutine 1 [running]:
github.com/hyperledger/fabric/peer/common.NewPeerClientForAddress(0x7ffd955fe783, 0x9, 0x7ffd955fe7a0, 0x10, 0x8fb52c, 0x9e8745, 0x14848a7)
    /opt/gopath/src/github.com/hyperledger/fabric/peer/common/peerclient.go:44 +0x8c

мы думали, что peer chaincode invoke просто отправляет запрос на узел, указанный в CORE_PEER_ADDRESS, и фактический акт вызова цепного кода на узлах, указанный в --peerAddresses, выполняется узлом в CORE_PEER_ADDRESS. Если бы это было так, то клиент, выполняющий peer chaincode invoke, не должен был бы нести сертификаты CA TLS одноранговых узлов, указанных в --peerAddresses. Однако это не так . Клиент, выполняющий peer chaincode invoke, вызывает цепной код на --peerAddresses. Если TLS включен на одноранговых узлах (CORE_PEER_TLS_ENABLED=true при запуске однорангового узла), тогда клиент будет требовать сертификаты CA TLS одноранговых узлов в --peerAddresses для успешной проверки подлинности TLS.

И как можно ожидать, что пользователь получит сертификат TLS CA других организаций? На практике, как это будет приобретено?

Одним из способов получения сертификатов TLS CA = сертификатов органов, которые выдавали другим организациям свои сертификаты TLS, является использование интерфейса командной строки Discover следующим образом:

/etc/hyperledger/bin/discover --peerTLSCA my-ca-chain.pem  --userKey msp/keystore/user-myorg.key  --userCert msp/signcerts/user-myorg.pem  --MSP myorgMSP  --tlsCert user-myorg-tls-client.pem  --tlsKey user-myorg-tls-client.key config --server peer1-myorg:7051 --channel mychannel > discover.json

Сертификаты в discover.json кодируются в base64. Таким образом, они должны быть декодированы в base64, и если есть промежуточные сертификаты, они должны быть перед корневыми сертификатами в файле цепочки.

* +1032 * Пример: * 1 033 *

cat discover.json | jq .msps.cvsMSP.tls_root_certs[0] | sed "s/\"//g" | base64 --decode > rca-cvs.pem
cat discover.json | jq .msps.cvsMSP.tls_intermediate_certs[0] | sed "s/\"//g" | base64 --decode > ica-cvs.pem
cat ica-cvs.pem rca-cvs.pem > cvs-ca-chain.pem

CLI Discover является частью двоичных файлов, которые загружаются при запуске Fabric install script .

Answer 2

это ничем не отличается от выдачи сертификатов для веб-службы: либо вы доверяете стороннему поставщику для обмена сертификатом, либо обмениваетесь напрямую с контрагентом.

Fabric - это разрешенная цепочка блоков, а - это определенный уровень доверия для начала.В противном случае вы никогда не узнаете, с кем вы совершаете сделку, например, в биткойнах ethereum, где рассматривается другой вариант использования.