#### 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.

- `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`