1
0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00

Provide guidance on TLS ca_file directives

This commit is contained in:
Phil Pennock
2020-10-30 15:30:06 -04:00
parent 1eca5d0c38
commit f5f1ff8718
2 changed files with 35 additions and 2 deletions

View File

@@ -6,7 +6,7 @@ The NATS server uses modern TLS semantics to encrypt client, route, and monitori
| :--- | :--- |
| `cert_file` | TLS certificate file. |
| `key_file` | TLS certificate key file. |
| `ca_file` | TLS certificate authority file. When not present, default to the system trust store. |
| `ca_file` | TLS [certificate authority file](tls.md#certificate-authorities). When not present, default to the system trust store. |
| `cipher_suites` | When set, only the specified TLS cipher suites will be allowed. Values must match the golang version used to build the server. |
| `curve_preferences` | List of TLS cipher curves to use in order. |
| `insecure` | Skip certificate verification. **NOT Recommended** |
@@ -59,6 +59,24 @@ tls: {
}
```
## Certificate Authorities
The `ca_file` file should contain one or more Certificate Authorities in PEM
format, in a bundle. This is a common format.
When a certificate is issued, it is often accompanied by a copy of the
intermediate certificate used to issue it. This is useful for validating that
certificate. It is not necessarily a good choice as the only CA suitable for
use in verifying other certificates a server may see.
Do consider though that organizations issuing certificates will change the
intermediate they use. For instance, a CA might issue intermediates in pairs,
with an active and a standby, and reserve the right to switch to the standby
without notice. You probably would want to trust _both_ of those for the
`ca_file` directive, to be prepared for such a day, and then after the first
CA has been compromised you can remove it. This way the roll from one CA to
another will not break your NATS server deployment.
## Self Signed Certificates for Testing
Explaining [Public key infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure), [Certificate Authorities \(CA\)](https://en.wikipedia.org/wiki/Certificate_authority) and [x509](https://tools.ietf.org/html/rfc5280) [certificates](https://en.wikipedia.org/wiki/Public_key_certificate) fall well outside the scope of this document. So does an explanation on how to obtain a properly trusted certificates.