I'm replicating this tutorial on a machine with centos. and it works well till I've to start the orderer. If I don't add a config.yaml and follow the instructions as they are, when submitting this to the CLI of ORG1:
peer channel create -c mychannel -f /tmp/hyperledger/org1/peer1/assets/channel.tx -o orderer1-org0:7050 --outputBlock /tmp/hyperledger/org1/peer1/assets/mychannel.block --tls --cafile /tmp/hyperledger/org1/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem
I get the error:
2022-04-24 08:24:17.756 UTC [main] InitCmd -> ERRO 03b Cannot run peer
because error when setting up MSP of type bccsp from directory
/tmp/hyperledger/org1/admin/msp: admin 0 is invalid [The identity does
not contain OU [CLIENT], MSP: [org1MSP],The identity does not contain
OU [ADMIN], MSP: [org1MSP]]
If I add a config.yaml file to the MSP folder as this link suggests I should I cannot even initiate the orderer with this error when I try to do docker-compose up
orderer1-org0 | 2022-04-24 08:15:40.373 UTC [orderer.common.server] initializeServerConfig -> INFO 004 Starting orderer with TLS enabled
orderer1-org0 | 2022-04-24 08:15:40.445 UTC [orderer.common.server] Main -> PANI 005 Failed validating bootstrap block: initializing channelconfig failed: could not create channel Consortiums sub-group config: setting up the MSP manager failed: admin 0 is invalid [The identity does not contain OU [CLIENT], MSP: [org1MSP],The identity does not contain OU [ADMIN], MSP: [org1MSP]] orderer1-org0 | panic:
Failed validating bootstrap block: initializing channelconfig failed: could not create channel Consortiums sub-group config: setting up the MSP manager failed: admin 0 is invalid [The identity does not contain OU [CLIENT], MSP: [org1MSP],The identity does not contain OU [ADMIN], MSP: [org1MSP]]
I'm not seeing how to solve this issue.
On version 2.2 it is mentioned when deploying an orderer. It mentions a different but possible related PANI 005:
but the solution is just creating the config.yaml and it's not working
Solution:
The system channel configuration is missing config.yaml
file. If you are creating a new ordering service, the MSPDir
referenced in configtx.yaml file is missing the config.yaml file.
Follow instructions in the Fabric CA documentation to generate this
file and then rerun configtxgen to regenerate the genesis block for
the system channel.
thanks
Related
2022-06-11 05:12:53.108 UTC [orderer.common.server] initializeServerConfig -> INFO 004 Starting orderer with TLS enabled
2022-06-11 05:12:53.120 UTC [blkstorage] NewProvider -> INFO 005 Creating new file ledger directory at /var/hyperledger/production/orderer/chains
2022-06-11 05:12:53.128 UTC [orderer.common.server] Main -> PANI 006 Failed validating bootstrap block: initializing channelconfig failed: could not create channel Orderer sub-group config: setting up the MSP manager failed: the supplied identity is not valid: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "ca.example.com")
panic: Failed validating bootstrap block: initializing channelconfig failed: could not create channel Orderer sub-group config: setting up the MSP manager failed: the supplied identity is not valid: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "ca.example.com")
We are trying to establish a grpcs (TLS) connection between a docker container running API server (based on Node.js) and another docker container running peer0 from Fabric network.
All containers are orchestated by docker swarm, and both containers happen to be running on the same Linux host.
The error log thrown by API container is the following:
2021-01-07T18:27:38.110Z - error: [Remote.js]: Error: Failed to
connect before the deadline URL:grpcs://10.0.1.2:9051 Query has
completed, checking results error from query = { Error: Failed to
connect before the deadline URL:grpcs://10.0.1.2:9051
at checkState (/usr/src/app/node_modules/grpc/src/client.js:833:16) connectFailed:
true } sampleEvent ERROR : Error: 14 UNAVAILABLE: Connect Failed E0107
18:27:53.602719124 16 ssl_transport_security.cc:1229] Handshake
failed with fatal error SSL_ERROR_SSL: error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed.
And the error log thrown from peer0 is:
2021-01-07 18:50:22.224 UTC [core.comm] ServerHandshake -> ERRO 043 TLS handshake failed with error EOF server=PeerServer remoteaddress=10.0.1.4:46212
IP addresses layout
IP address for API container is 10.0.1.94
IP address for peer0 container is 10.0.1.3
virtual IP address for docker service peer0 is 10.0.1.2
IP address for docker swarm load balancer endpoint is 10.0.1.4
Any suggestion of where to further troubleshoot? At this point is not clear if the problem is with the docker swarm internal networking, or an issue with ssl certificates in either side of the network.
UPDATE Feb 2 2021
The original TLS handshake error was fixed by upgrading the javascript used in NodeSDK. Among other things we started using the addToWallet.js script contained in the commercial-paper example
After being able to stablish TLS succesfully between Node.js API and peer0, we get a new access denied error when making a simple query to chaincode_example02
Facts:
We are running the query with 2 Admin users
One Admin is first-network original Admin#org1.example.com, with credentials generated by cryptogen tool
The other Admin is Admin#buyer.dlt.com whose credentials were created with openssl and a self signed in-company CA
From CLI, both Admin are good and are allowed to run peer commands interchangeably
From Node.js app, only Admin#org1.example.com is allowed to run queries. The message printed to console.log is:
Transaction has been evaluated, result is: 100
When running queries with Admin#buyer.dlt.com we get the following error logs:
Error logs from peer0#buyer.dlt.com
2021-02-02T04:08:45.291086617Z ^[[36m2021-02-02 04:08:45.290 UTC [protoutils] checkSignatureFromCreator -> DEBU 6e637^[[0m creator is &{BuyerMSP 8b7cc2ee996be4f7e5dbb1a4f64db67afd2ff8a2f41276c9bd7f33a2447dd9df}
2021-02-02T04:08:45.291094817Z ^[[36m2021-02-02 04:08:45.290 UTC [protoutils] checkSignatureFromCreator -> DEBU 6e638^[[0m creator is valid
2021-02-02T04:08:45.291100418Z ^[[36m2021-02-02 04:08:45.290 UTC [msp.identity] 2021-02-02T04:08:45.303821799Z ^[[33m2021-02-02 04:08:45.303 UTC [protoutils] ValidateProposalMessage -> WARN 6e63b^[[0m channel [mychannel]: creator's signature over the proposal is not valid: The signature is invalid
2021-02-02T04:08:45.303891604Z ^[[36m2021-02-02 04:08:45.303 UTC [endorser] func1 -> DEBU 6e63c^[[0m Exit: request from 10.0.1.84:52696
2021-02-02T04:08:45.303902005Z ^[[34m2021-02-02 04:08:45.303 UTC [comm.grpc.server] 1 -> INFO 6e63d^[[0m unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=10.0.1.84:52696 error="access denied: channel [mychannel] creator org [BuyerMSP]" grpc.code=Unknown grpc.call_duration=13.783655ms
Error log on console.log from script query.js:
2021-02-02T04:08:45.305Z - error: [Channel.js]: Error: 2 UNKNOWN: access denied: channel [mychannel] creator org [BuyerMSP]
2021-02-02T04:08:45.307Z - error: [Network]: _initializeInternalChannel: Unable to initialize channel. Attempted to contact 1 Peers. Last error was Error: 2 UNKNOWN: access denied: channel [mychannel] creator org [BuyerMSP]
Failed to evaluate transaction: Error: Unable to initialize channel. Attempted to contact 1 Peers. Last error was Error: 2 UNKNOWN: access denied: channel [mychannel] creator org [BuyerMSP]
In the end, this issue turned out to be two issues, in a 'russian doll like' style.
1. First issue: TLS Handshake error
This was fixed by upgrading the SDK library to the latest release
2. Second issue: Node SDK query triggers error "The signature is invalid".
The reason turned out to be that the CLI (written on Go) is using the Go crypto support which allows it to generate a signature from a hash without any knowledge of the curve used for the key. Instead, the SDK libraries used by the Node implementation require a specific curve to be specified by the code generating the signature, separately from the private key itself.
Bottom line, private keys used within Node SDK should be P-256.
As an alternative, as suggested by hyperledger dev team:
If you really must use a curve other than P-256 then you might be able
to use one of the following approaches:
-Use the off-line signing approach included in the documentation but specify an alternative curve instead of 'p256'. The supported curves
for the elliptic package documented here:
https://github.com/indutny/elliptic
-Set your own CryptoSuite implementation on the Client that underpins the Gateway object, with your own CryptoSuite.sign() implementation:
https://hyperledger.github.io/fabric-sdk-node/release-2.2/CryptoSuite.html#sign
I am new to hyperledger fabric. I used the byfn example and it worked fine and I am now working on my own network. I created crypto-config, config.tx all docker files (including base) as the byfn example.
Every thing works fine untill I run the command "docker-compose -f docker-compose-cli.yaml up -d"
all the nodes are generated but the order node fails within a few seconds.
I think the problem could be in my artifacts/genesis.block file, but I could not solve it.
orderer.expleoFabric.com | 2020-05-21 16:17:59.624 UTC [orderer.common.server] initializeServerConfig -> INFO 003 Starting orderer with TLS enabled
orderer.expleoFabric.com | 2020-05-21 16:17:59.741 UTC [orderer.common.server] Main -> PANI 004 Failed validating bootstrap block: initializing configtx manager failed: bad channel ID: 'Orderer-channel' contains illegal characters
orderer.expleoFabric.com | panic: Failed validating bootstrap block: initializing configtx manager failed: bad channel ID: 'Orderer-channel' contains illegal characters
orderer.expleoFabric.com |
This is from my logs but I could not find Ordrer-channel in any of my files.
channel ID can only contain lowercase alphabetical character.
for more information : https://github.com/hyperledger/fabric/blob/0c3f3f78178f8a639374fba1a12344f381877459/common/configtx/validator.go#L72..L74
I'm running Kubernetes on an AWS (version 1.5.2). I have installed helm using
helm init --node-selectors="nodeType=master"
forcing it running on the master.
When I try to run helm list i get the following error Error: Get https://192.0.0.1:443/api/v1/namespaces/kube-system/configmaps?labelSelector=OWNER%3DTILLER: x509: certificate signed by unknown authority
The logs from the tiller container (seems the issue is from the tiller to Kubernetes-api):
E0219 08:15:12.546100 1 config.go:330] Expected to load root CA config from /var/run/secrets/kubernetes.io/serviceaccount/ca.crt, but got err: open /var/run/secrets/kubernetes.io/serviceaccount/ca.crt: no such file or directory
E0219 08:15:12.547957 1 config.go:330] Expected to load root CA config from /var/run/secrets/kubernetes.io/serviceaccount/ca.crt, but got err: open /var/run/secrets/kubernetes.io/serviceaccount/ca.crt: no such file or directory
[main] 2018/02/19 08:15:12 Starting Tiller v2.7.0 (tls=false)
[main] 2018/02/19 08:15:12 GRPC listening on :44134
[main] 2018/02/19 08:15:12 Probes listening on :44135
[main] 2018/02/19 08:15:12 Storage driver is ConfigMap
[main] 2018/02/19 08:15:12 Max history per release is 0
[storage] 2018/02/19 08:20:47 listing all releases with filter
[storage/driver] 2018/02/19 08:20:47 list: failed to list: Get https://192.0.0.1:443/api/v1/namespaces/kube-system/configmaps?labelSelector=OWNER%3DTILLER: x509: certificate signed by unknown authority
Is there a way to configure tiller to ignore the untrusted certificate?
It looks like your Kubernetes cluster isn't properly configured. Usually there is a CA certificate for every pod in /var/run/secrets/kubernetes.io/serviceaccount/ca.crt that allows pods to communicate with the API server.
The first two lines in your log show that no such file could be found:
Expected to load root CA config from /var/run/secrets/kubernetes.io/serviceaccount/ca.crt, but got err: open /var/run/secrets/kubernetes.io/serviceaccount/ca.crt: no such file or directory.
I am trying create a channel according to documentation
Hyperledger Fabric v1.0 docs
Have an issue with certificate. On the docker "hyperledger/fabric-tools" node I can find certificate with current name - tlsca.example.com. But the channel cannot be created. I have certificate hand shake issue. Should I check/mount certificate to the peer node ?
root#4b6423da537b:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com# peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
2017-07-27 16:49:58.949 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-07-27 16:49:58.949 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-07-27 16:49:58.954 UTC [grpc] Printf -> DEBU 003 Failed to dial orderer.example.com:7050: connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"tlsca.example.com\")"; please retry.
Error: Error connecting due to rpc error: code = Internal desc = connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority (possibly because of \"x509: ECDSA verification failure\" while trying to verify candidate authority certificate \"tlsca.example.com\")"
Usage:
Thanks.
i meet the same problem. And run this command to close the network.
./network_setup.sh down mychannel
The reason that cause my problem is that the source code exists a error. So i modify this code error and reopen the network. This problem work out.
It would seem that you are in the incorrect working directory. When running the sample manually, you start the cli container and it places you in the /opt/gopath/src/github.com/hyperledger/fabric/peer directory. That is where you should be running the peer command. It would seem from your post that you were running the peer command in the /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com directory in the container, and it is not finding the configuration files that were mounted for the example.