Fix certPath in assetTransfer.go

[thejjw]

Following the latest tutorial, the current version of network.sh does not generate cert.pem as filename under msp/signcerts but instead created [email protected]. I have edited the application file to reflect such difference.

[denyeart]

The problem is that test-network with crytpgen puts the cert in /signcerts/[email protected] while test-network with fabric-ca puts the cert in /signcerts/cert.pem. This is unfortunate. Most of the tests use test-network with fabric-ca so I don't think we'll want to make the change as initially proposed here.

I think the solution is to make the applications work regardless of the cert file name. The apps do this for the keystore directory but not the signcerts or tls ca directories.

See the example at:
https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-basic/application-gateway-go/assetTransfer.go#L31-L33

The apps use the first file found in the keystore directory. I think it should do this for signcerts and tls ca directories as well, so that the approach is consistent, and will work regardless of the cert file names.

If you want to contribute this change that would be great. Otherwise we can open an issue for the backlog to do this across all the app samples.

But let's make sure the author @bestbeforetoday agrees with the approach.

[bestbeforetoday]

I'm not clear what the conditions are whereby the certificate has a different filename from the one currently used by the code. The repository tests seem to be passing with the current code, and this PR build is failing because the modified filename does not exist.

If there are cases where the certificate filename can be different and the certificate directory will only hold one certificate file (as with the private key filename), picking the first file in the directory (again, as we do with the private key file, and as suggested by @denyeart above) sounds like a good approach to me.

[denyeart]

@bestbeforetoday See my first paragraph above. Basically it comes down to whether the certificate was created by cryptogen versus fabric-ca.

Regardless, we are in agreement that the solution is to change the samples to read any certificate file in the signcerts directory, rather than reading a hardcoded file name.

[bestbeforetoday]

Oops, my sloppy reading. Your previous explanation was perfect!

It sounds like whichever is the first file in that directory should be usable. It would be good to break out the logic to read the first file from a directory to a separate function that can be shared by both the signer and identity creation functions. The same change will need to be made to all three language variants of the application-gateway-* application. Likely other samples too.

[bestbeforetoday]

I raised PR #1183 to address this issue for all the relevant sample applications.