luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

Add docs section on regenerating expired CA certificates (#9709) 

* Updated docs on regenerating built in CA

* review feedback

* Add sentence about expected behavior after update CA endpoint is used.
This commit is contained in:
Preetha 2021-02-11 15:38:12 -06:00 committed by GitHub
parent d8f10deda3
commit 89c2b9c97d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 26 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
website/content/commands/tls/ca.mdx
View File

@ -40,3 +40,8 @@ Usage: `consul tls ca create [filename-prefix] [options]`
will be added to the allowed DNS. If the UI is going to be served over HTTPS
its DNS has to be added with `-additional-constraint`. It is not possible to
add that after the fact! Defaults to false.
- `cluster-id` - ClusterID of the consul cluster, requires `-domain` to be set as well.
When used this will cause URIs to be set with spiffeid.
- `common-name` - Common Name of CA. Defaults to Consul Agent CA.

21
website/content/docs/connect/ca/index.mdx
View File

@ -211,3 +211,24 @@ servers.
Currently both Consul and Vault CA providers _do_ support cross signing. As more
providers are added this documentation will list any that this section applies
to.
### Recovering From Expired Certificates
If the built-in CA provider is misconfigured or unavailable, Consul service mesh requests eventually
stop functioning due to expiration of intermediate and root certificates. To recover manually, use the
[CLI helper](/commands/tls/ca#consul-tls-ca-create) to generate CA certificates.
#### Example - Regenerating the built in CA
```shell-session
$ consul tls ca create -cluster-id test -common-name "Consul Agent CA" -days=365 -domain consul
==> Saved consul-agent-ca.pem
==> Saved consul-agent-ca-key.pem
```
The example above generates a new CA with a validity of 365 days. The cluster-id argument is specific
to each cluster and can be looked up by examining the `TrustDomain` field in
the [List CA Roots](/api-docs/connect/ca#list-ca-root-certificates) endpoint.
The contents of the generated cert and private key files from the above step should then be used with
the [Update CA Configuration](/api/connect/ca#update-ca-configuration) endpoint. Once the CA configuration is
updated on the primary datacenter, all secondary datacenters will pick up the changes and regenerate their intermediate
and leaf certificates, after which any new requests that require certificate verification will succeed.