Вопросы Теги

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

Исключение нулевого указателя генерируется, когда приложение пытается использовать null в случае, когда требуется объект. К ним относятся:

  1. Вызов метода экземпляра объекта null.
  2. Доступ или изменение поля объекта null.
  3. Принимая длину null, как если бы это был массив.
  4. Доступ или изменение слотов null, как если бы это был массив.
  5. Бросок null как будто это было значение Throwable.

Приложения должны бросать экземпляры этого класса, чтобы указать на другие незаконные использования объекта null.

Ссылка: http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html

0
задан Mark Rotteveel 5 April 2019 в 17:46
поделиться

2 ответа

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

Чтобы пояснить причину, по которой был задан этот вопрос, при вызове 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 других организаций? На практике, как это будет получено?

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

/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, и если есть промежуточные сертификаты, они должны быть перед корневыми сертификатами в файле цепочки.

Пример: 

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 обнаружения является частью двоичных файлов, которые загружаются при запуске сценария установки Fabric .

0
ответ дан morpheus 5 April 2019 в 17:46
поделиться

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

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

0
ответ дан guoger 5 April 2019 в 17:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: