2021-08-19 18:18:55 +00:00
|
|
|
|
#### Common CA Config Options
|
|
|
|
|
|
|
|
|
|
|
|
The following configuration options are supported by all CA providers:
|
|
|
|
|
|
|
|
|
|
|
|
- `CSRMaxConcurrent` / `csr_max_concurrent` (`int: 0`) - Sets a limit on the
|
|
|
|
|
|
number of Certificate Signing Requests that can be processed concurrently. Defaults
|
|
|
|
|
|
to 0 (disabled). This is useful when you want to limit the number of CPU cores
|
|
|
|
|
|
available to the server for certificate signing operations. For example, on an
|
|
|
|
|
|
8 core server, setting this to 1 will ensure that no more than one CPU core
|
|
|
|
|
|
will be consumed when generating or rotating certificates. Setting this is
|
|
|
|
|
|
recommended **instead** of `csr_max_per_second` when you want to limit the
|
|
|
|
|
|
number of cores consumed since it is simpler to reason about limiting CSR
|
|
|
|
|
|
resources this way without artificially slowing down rotations. Added in 1.4.1.
|
|
|
|
|
|
|
|
|
|
|
|
- `CSRMaxPerSecond` / `csr_max_per_second` (`float: 50`) - Sets a rate limit
|
|
|
|
|
|
on the maximum number of Certificate Signing Requests (CSRs) the servers will
|
|
|
|
|
|
accept. This is used to prevent CA rotation from causing unbounded CPU usage
|
|
|
|
|
|
on servers. It defaults to 50 which is conservative – a 2017 MacBook can process
|
|
|
|
|
|
about 100 per second using only ~40% of one CPU core – but sufficient for deployments
|
|
|
|
|
|
up to ~1500 service instances before the time it takes to rotate is impacted.
|
|
|
|
|
|
For larger deployments we recommend increasing this based on the expected number
|
|
|
|
|
|
of server instances and server resources, or use `csr_max_concurrent` instead
|
|
|
|
|
|
if servers have more than one CPU core. Setting this to zero disables rate limiting.
|
|
|
|
|
|
Added in 1.4.1.
|
|
|
|
|
|
|
|
|
|
|
|
- `LeafCertTTL` / `leaf_cert_ttl` (`duration: "72h"`) - The upper bound on the lease
|
|
|
|
|
|
duration of a leaf certificate issued for a service. In most cases a new leaf
|
|
|
|
|
|
certificate will be requested by a proxy before this limit is reached. This
|
|
|
|
|
|
is also the effective limit on how long a server outage can last (with no leader)
|
|
|
|
|
|
before network connections will start being rejected. Defaults to `72h`. This
|
|
|
|
|
|
value cannot be lower than 1 hour or higher than 1 year.
|
|
|
|
|
|
|
|
|
|
|
|
This value is also used when rotating out old root certificates from
|
|
|
|
|
|
the cluster. When a root certificate has been inactive (rotated out)
|
|
|
|
|
|
for more than twice the _current_ `leaf_cert_ttl`, it will be removed
|
|
|
|
|
|
from the trusted list.
|
|
|
|
|
|
|
2021-11-02 18:02:10 +00:00
|
|
|
|
- `RootCertTTL` / `root_cert_ttl` (`duration: "87600h"`) The time to live (TTL) for a root certificate.
|
|
|
|
|
|
Defaults to 10 years as `87600h`. This value, if provided, needs to be higher than the
|
|
|
|
|
|
intermediate certificate TTL.
|
|
|
|
|
|
|
2021-11-04 19:19:08 +00:00
|
|
|
|
This setting applies to all Consul CA providers.
|
2021-11-02 18:02:10 +00:00
|
|
|
|
|
|
|
|
|
|
For the Vault provider, this value is only used if the backend is not initialized at first.
|
|
|
|
|
|
|
2022-09-08 07:26:34 +00:00
|
|
|
|
- `IntermediateCertTTL` / `intermediate_cert_ttl` (`duration: "8760h"`) The time to live (TTL) for
|
|
|
|
|
|
any intermediate certificates signed by root certificate of the primary datacenter. *This field is only
|
|
|
|
|
|
valid in the primary datacenter*.
|
|
|
|
|
|
Defaults to 1 year as `8760h`.
|
|
|
|
|
|
|
|
|
|
|
|
This setting applies to all Consul CA providers.
|
|
|
|
|
|
|
|
|
|
|
|
For the Vault provider, this value is only used if the backend is not initialized at first.
|
|
|
|
|
|
|
2021-08-19 18:18:55 +00:00
|
|
|
|
- `PrivateKeyType` / `private_key_type` (`string: "ec"`) - The type of key to generate
|
|
|
|
|
|
for this CA. This is only used when the provider is generating a new key. If
|
|
|
|
|
|
`private_key` is set for the Consul provider, or existing root or intermediate
|
|
|
|
|
|
PKI paths given for Vault then this will be ignored. Currently supported options
|
|
|
|
|
|
are `ec` or `rsa`. Default is `ec`.
|
|
|
|
|
|
|
|
|
|
|
|
It is required that all servers in a datacenter have
|
|
|
|
|
|
the same config for the CA. It is recommended that servers in
|
|
|
|
|
|
different datacenters use the same key type and size, although the built-in CA
|
|
|
|
|
|
and Vault provider will both allow mixed CA key types.
|
|
|
|
|
|
|
|
|
|
|
|
Some CA providers (currently Vault) will not allow cross-signing a
|
|
|
|
|
|
new CA certificate with a different key type. This means that if you
|
|
|
|
|
|
migrate from an RSA-keyed Vault CA to an EC-keyed CA from any
|
|
|
|
|
|
provider, you may have to proceed without cross-signing which risks
|
|
|
|
|
|
temporary connection issues for workloads during the new certificate
|
|
|
|
|
|
rollout. We highly recommend testing this outside of production to
|
|
|
|
|
|
understand the impact, and suggest sticking to same key type where
|
|
|
|
|
|
possible.
|
|
|
|
|
|
|
|
|
|
|
|
-> **Note**: This only affects _CA_ keys generated by the provider.
|
|
|
|
|
|
Leaf certificate keys are always EC 256 regardless of the CA
|
|
|
|
|
|
configuration.
|
|
|
|
|
|
|
|
|
|
|
|
- `PrivateKeyBits` / `private_key_bits` (`string: ""`) - The length of key to
|
|
|
|
|
|
generate for this CA. This is only used when the provider is generating a new
|
|
|
|
|
|
key. If `private_key` is set for the Consul provider, or existing root or intermediate
|
|
|
|
|
|
PKI paths given for Vault then this will be ignored.
|
|
|
|
|
|
|
|
|
|
|
|
Currently supported values are:
|
|
|
|
|
|
|
|
|
|
|
|
- `private_key_type = ec` (default): `224, 256, 384, 521`
|
|
|
|
|
|
corresponding to the NIST P-\* curves of the same name.
|
|
|
|
|
|
- `private_key_type = rsa`: `2048, 4096`
|
