Skip to content

Commit

Permalink
Fix and improve discovery TLS authentication comments in document
Browse files Browse the repository at this point in the history
Change-Id: I9a39ab88244438ccfb8ce97c235c45ec1c421419
Signed-off-by: yacovm <yacovm@il.ibm.com>
(cherry picked from commit ea7ab2d)
  • Loading branch information
yacovm authored and ale-linux committed Aug 18, 2020
1 parent 50aea5e commit 6491f6a
Showing 1 changed file with 10 additions and 5 deletions.
15 changes: 10 additions & 5 deletions docs/source/discovery-cli.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,12 +87,17 @@ signerconfig:
When the peer runs with TLS enabled, the discovery service on the peer
requires the client to connect to it with mutual TLS, which means it
needs to supply a TLS certificate. The peer is configured by default to
request (but not to verify) client TLS certificates, so supplying a TLS
certificate isn't needed (unless the peer's `tls.clientAuthRequired` is
set to `true`).
expects the client to authenticate using a TLS certificate.
When the discovery CLI's config file has a certificate path for
However, the peer is configured by default to
request (and verify if given, but not require) client TLS certificates.
Therefore, unless the peer's `tls.clientAuthRequired` is
set to `true` (in which case it mandates client-side TLS authentication),
TLS connections can be established to the peer but will be rejected in the
discovery application layer. To that end, the discovery CLI provides a
TLS certificate on its own if the user doesn't explicitly set one.

More concretely, when the discovery CLI's config file has a certificate path for
`peercacertpath`, but the `certpath` and `keypath` aren't configured as
in the above - the discovery CLI generates a self-signed TLS certificate
and uses this to connect to the peer.
Expand Down

0 comments on commit 6491f6a

Please sign in to comment.