From a70141e997bd3d9ac11aa75f05ece8af7cea9a13 Mon Sep 17 00:00:00 2001 From: Matthias Hanel Date: Wed, 30 Jun 2021 14:46:55 -0400 Subject: [PATCH] document pinned_certs --- nats-server/configuration/securing_nats/tls.md | 1 + 1 file changed, 1 insertion(+) diff --git a/nats-server/configuration/securing_nats/tls.md b/nats-server/configuration/securing_nats/tls.md index baa4cd3..2375ae8 100644 --- a/nats-server/configuration/securing_nats/tls.md +++ b/nats-server/configuration/securing_nats/tls.md @@ -14,6 +14,7 @@ The NATS server uses modern TLS semantics to encrypt client, route, and monitori | `verify` | If `true`, require and [verify](auth_intro/tls_mutual_auth.md#validating-a-client-certificate) client certificates. To support use by Browser, this option does not apply to monitoring. | | `verify_and_map` | If `true`, require and verify client certificates and [map](auth_intro/tls_mutual_auth.md#mapping-client-certificates-to-a-user) certificate values for authentication purposes. Does not apply to monitoring either. | | `verify_cert_and_check_known_urls` | Only settable in a non client context where `verify: true` is the default \([cluster](../clustering/)/[gateway](../gateways/)\). The incoming connections certificate's `X509v3 Subject Alternative Name` `DNS` entries will be matched against all urls in the configuration context that contains this tls map. If a match is found, the connection is accepted and rejected otherwise. Meaning for gateways we will match all DNS entries in the certificate against all gateway urls. For cluster we will match against all route urls. As a consequence of this, dynamic cluster growth may require config changes in other cluster where this flag is true. DNS name checking is performed according to [rfc6125](https://tools.ietf.org/html/rfc6125#section-6.4.1). Only the full wildcard `*` is supported for the left most label. This would be one way to keep cluster growth flexible. | +| `pinned_certs` | List of hex-encoded SHA256 of DER encoded public key fingerprints. When present, during the TLS handshake, the provided certificate's fingerprint is required to be present in the list or the connection is closed. This sequence of commands generates an entry for a provided certificate: `openssl x509 -noout -pubkey -in | openssl pkey -pubin -outform DER | openssl dgst -sha256`. | The simplest configuration: