Refactor TLS Configuration

[mbrandenburger]

The current core.yaml for an FSC node contains incomplete and inconsistent TLS configuration options across services. This issue proposes a systematic refactor of TLS and mTLS configuration for every client and server exposed or used by an FSC node, with the goal of achieving a consistent, explicit, and extensible TLS model.

Problem

An FSC node exposes and consumes multiple services (gRPC, web, P2P, Fabric services, metrics, tracing, etc.). Today:

• TLS settings differ across services
• Client vs server TLS options are inconsistent
• mTLS is configured differently (or implicitly) depending on the component
• Metrics are coupled to the web service
• Tooling (e.g. FSCCLI) requires special-case configuration

This makes the system harder to reason about, configure, and secure.

FSC Services Overview

An FSC node may provide or consume the following services:

Node services:

• View service
  • gRPC (server)
  • Web (server)
• Node P2P
  • (Client / Server)
• Metrics
  • Server (currently attached to web)
• Tracing
  • Client

Fabric (x) integrations:

• Ordering service (from config block) — client
• Peers (sidecar) — client
• Notification service — client
• Query service — client

Tooling:

• FSCCLI
  • View service gRPC (client)
  • View service Web (server)

Proposed TLS Configuration Model

Each client and server configuration should follow a uniform and explicit structure.

Server configuration

server:
  # TLS
  enabled: bool
  serverCert: string
  serverKey: string

  # mTLS
  clientAuthRequired: bool
  clientRootCAs: []string

Client configuration

client:
  # TLS
  enabled: bool
  serverRootCAs: []string

  # mTLS
  clientAuthEnabled: bool
  clientCert: string
  clientKey: string

This structure should be reused consistently across all services.

Ordering service

The TLS configuration of the ordering service might differ a bit as the endpoint details are extracted from config transactions received from the network. In that case the client.serverRootCAs provided via the config file will be ignored and set via the config transactions and if client.clientAuthEnabled is true, client.clientCert and client.clientKey is used for all orderer connections.

Tasks

• Align TLS configuration across all services (client & server)
• Restructure core.yaml to reflect the new TLS model
• Update NWO configuration generation
• Update each component to consume the new configuration
• Run Metrics via an independent web server
• Update configuration documentation

[mbrandenburger]

This issue aims to resolve #1111

[mbrandenburger]

@adecaro @AkramBitar @pasquale95 @arner WDYT?

[adecaro]

Fabric uses the following format:

  # TLS Settings
  tls:
    # Require server-side TLS
    enabled: false
    # Require client certificates / mutual TLS for inbound connections.
    # Note that clients that are not configured to use a certificate will
    # fail to connect to the peer.
    clientAuthRequired: false
    # X.509 certificate used for TLS server
    cert:
      file: tls/server.crt
    # Private key used for TLS server
    key:
      file: tls/server.key
    # rootcert.file represents the trusted root certificate chain used for verifying certificates
    # of other nodes during outbound connections.
    # It is not required to be set, but can be used to augment the set of TLS CA certificates
    # available from the MSPs of each channel’s configuration.
    rootcert:
      file: tls/ca.crt
    # If mutual TLS is enabled, clientRootCAs.files contains a list of additional root certificates
    # used for verifying certificates of client connections.
    # It augments the set of TLS CA certificates available from the MSPs of each channel’s configuration.
    # Minimally, set your organization's TLS CA root certificate so that the peer can receive join channel requests.
    clientRootCAs:
      files:
        - tls/ca.crt
    # Private key used for TLS when making client connections.
    # If not set, peer.tls.key.file will be used instead
    clientKey:
      file:
    # X.509 certificate used for TLS when making client connections.
    # If not set, peer.tls.cert.file will be used instead
    clientCert:
      file:

which FSC aligned to. Why not sticking with it?

[pasquale95]

@mbrandenburger The configuration proposed by @adecaro can also be fine. At the end is just what you proposed with a slightly different naming. What is important though is that FSC comes at the moment with some tls inconsistencies that should be addressed.
Here I report some I found:

• fabric.<topology>.tls:

fabric:
  mytopos:
    # What does this TLS section mean?
    # Fabric is made by multiple components, i.e. ordering + peer.
    # It makes more sense to define the TLS settings per single connection
    # instead of having a generic section.
    tls:
      enabled: false
      clientAuthRequired: false

• fabric.<topology>.peers:

fabric:
  mytopos:
    peers:
      - address: host.docker.internal:5400
        connectionTimeout: 10s
        tlsRootCertFile: /target/tls/committer-sidecar/ca.crt
        # Here it should be tlsEnabled or similar, since for the other
        # connection settings we set to true if TLS is enabled.
        tlsDisabled: true

• fabric.<topology>.queryService and fabric.<topology>.peers:

fabric:
  mytopos:
    queryService:
      endpoints:
        - address: host.docker.internal:5500
          connectionTimeout: 5s
          tlsEnabled: false
          tlsRootCertFile: /target/tls/committer-query-service/ca.crt
          # For each entry within this array, there should be also the flags to
          # setup mTLS if the service to connect uses mTLS.

• fsc.metrics.prometheus.tls:

fsc:
  metrics:
    provider: prometheus
    prometheus:
      # What does this flag define? If we set to false while the `fsc.web.tls.enabled` is set to `true`, what happens?
      tls: false

[mbrandenburger]

Fabric uses the following format: ...
which FSC aligned to. Why not sticking with it?

I think FSC used to be aligned with the format provided by Fabric and some sections of the config still are. However, @pasquale95 just posted good examples where the config is not aligned anymore. This task is about bring the TLS configuration back in a consistent state easy to use and understand.

[adecaro]

I don't see them as misaligned.
For the fabric platform there is a general tls configuration section that can be overridden for specific cases (no TLS for a specific peer, for example, or a different root certificate.
Moreover, for Fabric, the TLS root certificates are generally in the configuration block via the MSP definitions.

I would keep the changes minimal, if possible.

[adecaro]

@mffrench @saoussen , any comment from your side? Thanks.