peer channel creation fails in Hyperledger Fabric

Below solution worked for me.

Go inside your peer docker container. Go to /etc/hyperledger/msp/users/[email protected]/msp and run export CORE_PEER_MSPCONFIGPATH=$PWD

Run your peer channel create command again with appropriate flags.

This has nothing to do with TLS, since the request has reached the orderer. Have it been a TLS issue - you wouln't have gotten the following error:

Error: Got unexpected status: BAD_REQUEST -- Error authorizing update: Error validating DeltaSet: Policy for [Groups] /Channel/Application not satisfied: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining

Now, the error basically means that you tried to send a transaction for channel creation, but the transaction was signed by a user (a client certificate) that isn't a channel admin.

You need to prefix the command with something similar to this:

CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/[email protected]/msp

Error: Got unexpected status: BAD_REQUEST -- Error authorizing update: Error validating DeltaSet: Policy for [Groups] /Channel/Application not satisfied: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining

This usually indicates that the signer of the channel creation transaction does not have admin rights for one of the consortium orgs, however, it may indicate a failure for a number of other reasons.

Unfortunately, the error must be somewhat cryptic, to avoid leaking information about consortium or channel membership. To get the underlying cause, you will need to check the orderer logs. If it is not already set, you will want to turn the log level up to debug in orderer.yaml or alternately by setting FABRIC_LOGGING_SPEC=debug (or for versions of Fabric prior to v1.4.x ORDERER_GENERAL_LOGLEVEL=debug) before starting the orderer. In your orderer logs, you will see the same error text as output by the peer client, but in the preceding lines you will see additional causes for your error.

The most common reasons are:

1. The identity is not in the list of admins for the org.
2. The identity's certificate is not validly signed by the org CA chain.
3. The identity's org is not known to the orderer.

Some other unlikely possibilities because you are using the peer binary and not custom code:

4. The signature does not match the identity or signed bytes.
5. The identity is malformed.

Assuming that the cause is not obvious from the orderer logs, if you post them here, I'd be happy to help diagnose them.

Oh, and as a helpful tip. You may see a more human readable version of your genesisblock by using configtxgen -inspectBlock <genesis.block>.

Edit: Looking back a the top of your post I see this output in the orderer log:

ERRO 02d Principal deserialization failure (The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority) for identity

This would indicate that the certificate claims to be issued by a CA, but is not signed by the CA the orderer knows about (error type 2 above). This would commonly happen if you bootstrapped the orderer, then regenerated the crypto material for your environment without removing the orderer's storage directory.

It's important to remember that the ORDERER_GENERAL_BOOTSTRAPFILE (or prior to v2.0.0 ORDERER_GENERAL_GENESISFILE) is only read if the system is not already bootstrapped, so changing the genesis block for the orderer will have no affect unless the orderer storage is also deleted.