Join channel fails with imported ordering service

[TsvetanG]

There is an issue (seems to be a regression as it works with earlier console images - i.e. v1.0.8-18) joining a peer on a channel using an imported ordering service.
The error is:
_An unexpected error occurred.

Hide error details
{"details":{"function_name":"getChannelBlockFromOrderer","error":true,"msp_id":"orderingsrvmsp","stitch_msg":"["Missing an argument - client certificate (\"client_cert_b64pem\"). Provide a ECDSA signed certificate that is a base 64 encoded PEM file.","Missing an argument - client private key (\"client_prv_key_b64pem\"). Provide a ECDSA private key that is a base 64 encoded PEM file."]","grpc_resp":null,"orderer_host":"https://demo-hlf-console-console.texas.demo.senofi.net:443/grpcwp/https%3A%2F%2Fdemo-orderingsrvnode1-_

The setup:

• Two consoles for 2 different orgs. One of the consoles operates the ordering service and an MSP. The second console operates a single MSP.
• The MSP of the second console is part of the channel.
• The MSP definition of the first org and the ordering service definition are imported to the second console.
• The second console fails to join the channel with an error (see above). Console -> Channels (Peer Channels) -> Join Channel -> Select the imported ordering service (Next) -> Enter the Channel Name (Next) -> Error occurs.
  The same error appears when the join channel is triggered from the Peer page.

Expected result:
The console should list the peers to join the channels and allow the user to finish the process.

[TsvetanG]

After further investigation, it looks like the following change introduced the issue:
6a8befd
See line 487, where the error is introduced in the filterPeers method if the config block cannot be retrieved.

The change above seems to resolve an issue with filtering the peers that belong to MSPs on the channel.

However, when the ordering service is imported and managed outside of the console instance (i.e. by another organization), there will be no admin identities of the ordering service available in the wallet. Therefore the getChannelConfigBlock of OrdererRestApi will fail (internally it gets the cert/private key of the ordering node associated admin identity).
To solve this problem the API should rather use the admin identity certs of the MSP of the peer to fetch the ordering service config block (considering the ordering service update is already done to include the joining MSP certs).

There are 2 paths of joining peer to channel that are affected:
(1) Trigger the join to channel from the peer page
In this scenario, we know the peer and the MSP of the peer. In case there are no ordering service identities available the impl can use the MSP admin to fetch the config block

(2) Trigger the join to channel from the channels page
In this case, there is no peer/MSP context and there is no ordering service identity available the console cannot fetch the config block. Note that at this point there is no information about the MSPs of the peers that are joining the channel. Therefore the console cannot detect and use the proper MSP admin user to fetch the config block.
There is an option to try fetching the block using the available MSP admins but this has side effects like performance impacts. Furthermore, the user may not be aware of what exact admin identities the console is using to fetch the block (the console may expose unnecessary admin certs to the ordering service). The console may expose an input to the user to choose the MSP admin for the call, however, this requires a change of the current screen.

Proposed solution:

• Pass the MSP id from the JoinChannelModal to the OrdererRestApi getChannelConfigBlock. Adjust the impl of the getChannelConfigBlock to use the MSP admin certs to fetch the config block when there is no ordering service admin identity available.
• Adjust the logic in getChannelConfigBlock of the OrdererRestApi to return a specific error in case no certs are determined for the call to fetch the block.
• Adjust the code in JoinChannelModal when processing the error in the catch block to consider the specific error when no certs are determined, the config cannot be fetched and therefore the MSPs on the channel are currently unknown. Let the user continue with the process and decide what peers to join. The admin should be already aware what are the MSPs on the channel based on the out-of-band communication with the admin of the other organizations.

I am available to contribute a fix once the proposed solution has been reviewed and accepted by the maintainers.