89 lines
4.7 KiB
Plaintext
89 lines
4.7 KiB
Plaintext
#### 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.
|
||
|
||
- `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.
|
||
|
||
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.
|
||
|
||
- `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.
|
||
|
||
- `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`
|