Currently peers and ordering nodes are deployed by hlf-operator using self-signed certs. While that's fine for development/testing, it can easily be a problem is the Fabric network is exposed to the Internet through public DNS names.
It would be desirable to support the ability to deploy peers and ordering nodes (the "public" grpc API of ordering nodes) using TLS certificates which are specified at deployment time. Also, hlf-operator should provide an option to disable TLS-based authentication.
For ordering nodes, things are a bit trickier; in addition to the public grpc service, ordering nodes support raft communications to build consensus in a network of ordering services. While the normal grpc service and raft communication may be supported by the same underlying grpc server, it would be great supporting the ability to split up the services (which is supported in Fabric itself). Now, given that the TLS certificate used by the raft communication side of an ordering service is also used for client/server authentication (and that cannot be disabled), and considering that those certificates are stored in channels' config blocks, it should be possible to create such certificates based on an intermediary root provided by the user.
In general, also when creating a Fabric CA the user should be able to specify intermediate root certs for CA to use, to avoid relying on self signed certs entirely.
I suppose the underlying requirement is that hlf-operator should provide enough "knobs" for user to end up in a situation where the resulting Fabric network doesn't use self-signed certs at all.
Currently peers and ordering nodes are deployed by hlf-operator using self-signed certs. While that's fine for development/testing, it can easily be a problem is the Fabric network is exposed to the Internet through public DNS names. It would be desirable to support the ability to deploy peers and ordering nodes (the "public" grpc API of ordering nodes) using TLS certificates which are specified at deployment time. Also, hlf-operator should provide an option to disable TLS-based authentication. For ordering nodes, things are a bit trickier; in addition to the public grpc service, ordering nodes support raft communications to build consensus in a network of ordering services. While the normal grpc service and raft communication may be supported by the same underlying grpc server, it would be great supporting the ability to split up the services (which is supported in Fabric itself). Now, given that the TLS certificate used by the raft communication side of an ordering service is also used for client/server authentication (and that cannot be disabled), and considering that those certificates are stored in channels' config blocks, it should be possible to create such certificates based on an intermediary root provided by the user. In general, also when creating a Fabric CA the user should be able to specify intermediate root certs for CA to use, to avoid relying on self signed certs entirely.
I suppose the underlying requirement is that hlf-operator should provide enough "knobs" for user to end up in a situation where the resulting Fabric network doesn't use self-signed certs at all.