Как отличить клиентский и одноранговый сертификат, сгенерированный `cryptogen` в Hyperledger Fabric?

Question

Я сгенерировал сертификаты с cryptogen.

и проверил сгенерированные сертификаты с openssl и заметил, что в нем отсутствует информация, которая может использоваться для различения ролей партнеров и клиентов. Я считаю, что admin можно различить, потому что admincerts написаны в блокчейне, но нет никакой информации о клиенте и пирах.

Certificate:
    Data:
        Version: 3 (0x2)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = US, ST = California, L = San Francisco, O = test.com, CN = ca.test.com
        Validity
            Not Before: Sep 19 01:49:00 2019 GMT
            Not After : Sep 16 01:49:00 2029 GMT
        Subject: C = US, ST = California, L = San Francisco, CN = User1@test.com
...

Certificate:
    Data:
        Version: 3 (0x2)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = US, ST = California, L = San Francisco, O = test.com, CN = ca.test.com
        Validity
            Not Before: Sep 19 01:49:00 2019 GMT
            Not After : Sep 16 01:49:00 2029 GMT
        Subject: C = US, ST = California, L = San Francisco, CN = p0.test.com
...

(Единственные различия, которые я вижу, это CN, ключ и ID субъектасвязанные вещи)

Причина, по которой я задаюсь вопросом, заключается в том, что, хотя их роли не могут быть различены, установка подтверждающего узла с MSP клиента не будет работать из-за сбоя CSCC при присоединении к каналу.

Error: proposal failed (err: bad proposal response 500: access denied for [JoinChain][testc]: [Failed verifying that proposal's creator satisfies local MSP principal during channelless check policy with policy [Admins]: [This identity is not an admin]])

(другим партнерам со своим MSP удалось присоединиться к каналу между прочим)

Таким образом, система ролей работает, как предполагалось, но как CSCC фактически узнал роль сертификата? Есть ли скрытый механизм?

Answer 1

Мой ответ основан на Fabric 1.4.3 и более поздних версиях.

Конкретная ошибка, которую вы видите, означает, что вы не вызываете API JoinChannel с использованием идентификатора (пары ключ / сертификат), который считаетсяадмин для сверстника. До версии 1.4.3 администраторы определялись путем явного помещения сертификатов в папку admincerts в локальном каталоге MSP ваших партнеров. В 1.4.3 и более поздних версиях вы также можете разрешить идентификацию администраторов через определенное OU в общем имени (подробнее см. Ниже).

Так что вам нужно вызвать JoinChannelAPI с равноправным администратором. При использовании cryptogen в папке users создается пользователь-администратор. Вы должны использовать это удостоверение при вызове JoinChannel.

Подробная информация о ролях MSP и их определении:

Существует 5 возможных ролей:

• admin
• peer
• client
• orderer
• member

Чтобы использовать peer, клиент и заказчикролей, вам нужно включить функцию «идентификация личности» . При использовании структуры MSP на основе папок это достигается установкой включения «NodeOUs» в файле config.yaml в корне каталога MSP:

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/ca.sampleorg-cert.pem
    OrganizationalUnitIdentifier: orderer

Это определяет, какразличать роли MSP по OU , присутствующим в атрибуте CommonName сертификата X509. В приведенном выше примере говорится, что любой сертификат, выданный cacerts / ca.sampleorg-cert.pem с OU = client , будет идентифицирован как клиент, OU = peer как узел и т. д. Начиная с версии 1.4.3, есть также организационная единица для администраторов, поэтому вам больше не нужно явно размещать сертификаты в папке admincerts каталога MSP.

Когдаиспользуя cryptogen , вы можете включить эту функцию, установив EnableNodeOUs в значение true в вашем файле crypto-config.yaml и запустив cryptogen generate --config crypto-config.yaml . Например, это включит NodeOU для одноранговой организации:

PeerOrgs:
  - Name: org1
    Domain: org1.example.com
    EnableNodeOUs: true
    Template:
      Count: 2
      SANS:
         - "localhost"
         - "127.0.0.1"
         - "{{.Hostname}}-{{.Domain}}"
    Users:
      Count: 1

Answer 2

Это очень простой, ничего сложного или скрытого механизма, это PKI, как вы знаете.

У каждой сущности, равной или заказывающей, есть свой собственный MSP

, так что присутствует вMSP

.
├── admincerts
├── cacerts
├── keystore
├── signcerts
└── tlscacerts

, поскольку вы видите, что каждый одноранговый узел генерирует доверие из-за локального MSP, выше структуры однорангового MSP у нас есть admincerts , поэтому, какую бы идентичность мы ни упоминали, партнер будет предполагать, что идентичность какАдминистратор и вам необходимо подписать канал создания, присоединиться к каналу или установить цепной код транзакция с этими учетными данными администратора,

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

Точно так же cacerts : узел примет любую цепочку сертификатов rootCA, присутствующую в папке cacerts, он примет любой запрос от клиента с идентификацией, выданной этим ca

Приходя к клиенту и коллегам :

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

check this

Answer 3

Сертификат администратора хранится в admincerts каталоге msp. Если подпись транзакции может быть подтверждена этим, мы можем сказать, что отправитель транзакции admincerts. Короче говоря, ткань узнает роль сертификата не от самого сертификата, а от msp.

Answer 4

Это то, что сама платформа Hyperledger обрабатывает сама. нам просто нужно обработать сертификат, основанный на атрибутах поддержки матрицы клиента. так что вы можете идентифицировать различные сертификаты через их атрибут.

в сети Fabric каждый компонент имеет свою собственную идентификацию. Это означает, что каждый компонент имеет свой собственный сертификат, который обрабатывает сама ткань.