TLS Authentication

• Validate the client certificate matches a known or trusted CA
• Extract information from a trusted certificate to provide authentication

The examples in the following sections make use of the certificates you generated locally.

The server can verify a client certificate using a CA certificate. To require verification, add the option verify to the TLS configuration section as follows:

Or via the command line:

nats-server --tlsverify --tlscert=server-cert.pem --tlskey=server-key.pem --tlscacert=rootCA.pem

This option verifies the client’s certificate is signed by the CA specified in the ca_file option. When ca_file is not present it will default to CAs in the system trust store. It also makes sure that the client provides a certificate with the extended key usage TLS Web Client Authentication.

To have TLS Mutual Authentication map certificate attributes to the user’s identity use verify_and_map as shown as follows:

tls {
  cert_file: "server-cert.pem"
  key_file:  "server-key.pem"
  ca_file:   "rootCA.pem"
  # Require a client certificate and map user id from certificate
}

When present, the server will check if a Subject Alternative Name (SAN) maps to a user. It will search all email addresses first, then all DNS names. If no user could be found, it will try the certificate subject.

Output

Certificate:
...
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:localhost, IP Address:0:0:0:0:0:0:0:1, email:email@localhost
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
...

authorization {
  ]
}

Use the syntax to specify a user corresponding to the certificate subject:

Output

Certificate:
    Data:
...
        Subject: O=mkcert development certificate, OU=testuser@MacBook-Pro.local (Test User)
...

The configuration to authorize this user would be as follows:

authorization {
  users = [
    {user: "OU=testuser@MacBook-Pro.local (Test User),O=mkcert development certificate"}
  ]

TLS timeout is described here.