Update rolling certificates KB article (#989)

content/knowledge_base/tips/rolling_certificates.md

@@ -22,22 +22,65 @@ Validity
    Not After : Apr 13 12:05:46 2023 GMT
 ```
 
+## What happens when the certificate expires?
+
+- When the internal server certificate expires clients will not accept it and
+  they will refuse to communicate. Clients will show as offline in the GUI and
+  buffer data as long as possible, subject to their configured buffer limits.
+- New GUI sessions will fail with "500 Internal Server Error" and the response
+  body `{"code":2,"message":"Must set a username"}` and fail to load.
+
+For Velociraptor versions 0.74 and later there is a mechanism to mitigate the
+impact of unexpected certificate expiry:
+
+- Upon restarting the server service, if the certificate
+  (`Frontend.certificate`) has expired, and if the server.config.yaml contains
+  the CA private key then it will automatically issue a new cert with the same
+  validity period as the expired one. This temporary certificate is held in
+  memory only and is NOT written to the server.config.yaml.
+- In the server log you will see the following messages:
+
+```bash
+[ERROR] <log_date> Frontend Certificate is not valid: Certificate Valid NotBefore <start_date> and Not After <end_date> but Now is <current_date>. See https://docs.velociraptor.app/knowledge_base/tips/rolling_certificates/
+[INFO] <log_date> Found CA private key in config, will automatically rotate keys, but you should consider updating the config file using `velociraptor config rotate`
+```
+If this is the case you should update your server certificate by reissuing a new
+one.
+
+## Rotating certificates
+
 Reissuing a new server certificate can be performed at any time using the
-`config reissue_certs` command. The procedure amounts to generating a new
-server configuration which is derived from the old one, and then replacing the
-old config with the new config.
+`config reissue_certs` command. You can even reissue a certificate with extended
+validity before you deploy your server.
+
+The procedure amounts to generating a new server configuration which is derived
+from the old one, and then replacing the old config with the new config.
+
+The `config rotate_keys` command can be used to regenerate both the server
+certificate and the associated private key. Although this is not necessary for
+operational purposes, it is considered good security practice to rotate keys and
+certificates periodically, and particularly after a suspected systems
+compromise.
+
+{{% notice info %}}
+
+For server versions older than 0.72.3 please use the following commands instead
+of those shown below:
+
+|                         Goal                         | Command for the current version     | Command for versions <0.72.3      |
+|:----------------------------------------------------:|-------------------------------------|-----------------------------------|
+|             Reissue only the server cert             | `velociraptor config reissue_certs` | `velociraptor config reissue_key` |
+| Reissue the server cert and<br> also the private key | `velociraptor config rotate_keys`   | `velociraptor config rotate_key`  |
+
+{{% /notice %}}
 
-Additionally the `config rotate_keys` command can be used to regenerate both
-the server certificate and the associated private key. Although this is not
-necessary for operational purposes, it is considered good security practice
-to rotate keys and certificates periodically, and particularly after a
-suspected systems compromise. 
+#### Setting a non-standard validity
 
-## Setting a non-standard validity
+When reissuing the certificate the `--validity` flag can be used to extend the
+validity beyond the default of one year. For example, to generate a config
+containing a server certificate which is valid for 2 years, you would run the
+command:
 
-The latest release has a `--validity` option can be used to extend the validity
-beyond the default of one year. For example, to generate a config containing a
-server certificate which is valid for 2 years, you would run the command:
 ```sh
 velociraptor --config server.config.yaml config reissue_certs --validity 730  > new.server.config.yaml
 ```
@@ -48,36 +91,48 @@ You can generate a new config on day 1 based on the initial config using the
 `config reissue_certs` command. You can then use the new config for the new
 server installation.
 
-## Rotating certificates
-
-{{% notice info %}}
-
-For server versions older than 0.72.3 please use the following commands instead
-of those shown below:
+{{% notice tip %}}
 
-- *Current command* -> *Command for versions <0.72.3*
-- `velociraptor config reissue_certs` -> `velociraptor config reissue_key`
-- `velociraptor config rotate_keys` -> `velociraptor config rotate_key`
+In version 0.74 and later the configuration wizard (`velociraptor config
+generate -i`) allows you to issue the server certificate with either 1-year,
+2-year or 10-year validity.
 
 {{% /notice %}}
 
-To rotate server certificates, simply use the following command to
-generate a new configuration file containing rotated certificates:
+#### Option 1: Reissue only the server cert
+
+To rotate server certificates, use the following command to generate a new
+configuration file containing rotated certificates:
 
 ```
 $ velociraptor config reissue_certs --config /etc/velociraptor/server.config.yaml > /tmp/new_key.config.yaml
 ```
 
+The `config reissue_key` command updates the following configuration items:
+- `GUI.gw_certificate`
+- `Frontend.certificate`
+
+`CA.private_key`, `Client.ca_certificate`, `GUI.gw_private_key`, and `Frontend.private_key` are preserved.
+
+#### Option 2: Reissue the server cert and also the private key
+
 Alternatively, you can regenerate the server's private keys and rotate the
 certificates at the same time:
 
 ```
 $ velociraptor config rotate_keys --config /etc/velociraptor/server.config.yaml > /tmp/new_key.config.yaml
 ```
 
+The `config rotate_key` command updates the following configuration items:
+- `GUI.gw_certificate`
+- `GUI.gw_private_key`
+- `Frontend.certificate`
+- `Frontend.private_key`
+
+`CA.private_key` and `Client.ca_certificate` are preserved.
+
 The previous two commands will not affect the CA private key and
-certificate, which is valid for 10 years, as described in the
-previous section.
+certificate, which is valid for 10 years, as described previously.
 
 You can view the new certificate using jq and openssl (here `jq` is
 used to show the PEM certificate of the frontend and `openssl` is used

static/kb/data.json

@@ -8,8 +8,8 @@
             "deployment"
         ],
         "author": "predictiple",
-        "author_link": "https://github.com/predictiple",
         "author_avatar": "https://avatars.githubusercontent.com/u/9843422?v=4",
+        "author_link": "https://github.com/predictiple",
         "date": "2024-12-28"
     },
     {