> For the complete documentation index, see [llms.txt](https://platform9.com/kb/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://platform9.com/kb/smcp/solution/monitoring-cert-and-ca-expiry-on-lts1-deployments.md).

# Monitoring Cert and CA expiry on LTS1 Deployments

There are 3 categories of certificates and their CAs on a Platform9 Edge Cloud Deployment, each with different expiry times. This document covers how these CAs and certs can be monitored for expiry as well as manual steps to either regenerate the CA or ensure that the generated certs continue to be valid.

## Monitoring Certs

### Monitoring Hostagent CA and Certs

1. ssh to DU VM (192.168.120.254) from DU host.
2. `cd /etc/pf9/certs`
3. There can be v\[1-9] directories created here as part of the upgrade process (so, cd to the latest v\* dir). If you don't see a v\* directory, it implies that the cert version is v0, and these certs are present in the above directory itself. Within each cert version, you should see a `ca/` directory as well as a `hostagent/` directory.
4. To check the **CA** expiry, go into `ca/` directory and run `openssl x509 -in cert.pem -noout -startdate -enddate`
5. To check the **hostagent certs** expiry, go into `hostagent/` directory and run `openssl x509 -in cert.pem -noout -startdate -enddate`

If you observe that the CA or certs are expiring, please following the manual steps mentioned in the below article to regenerate them: <https://platform9.com/kb/PEC/how-to-regenerate-certs-if-hostagent-certificates-have-expired>

### Monitoring Sunpike CA and Certs

ssh to DU VM (192.168.120.254) and run the below steps:

{% tabs %}
{% tab title="Bash" %}

```bash
sudo su
export VAULT_TOKEN=$(mysql qbert -Bse "SELECT credential_value FROM qbert_secrets where credential_name='root_token'")
export VAULT_ADDR=http://127.0.0.1:8200
/usr/local/bin/vault read pki/cert/ca -format=json | jq -r '.data.certificate'| openssl x509 -noout -dates

# TTL 

/usr/local/bin/vault read pki/roles/sunpike | grep ttl
```

{% endtab %}
{% endtabs %}

If you observe that the Sunpike CA is expiring, please follow the manual steps mentioned in the following article to regenerate it: <https://platform9.com/kb/PEC/refresh-sunpike-ca>

To check the `sunpike-kube-apiserver` certificate expiry:

{% tabs %}
{% tab title="Bash" %}

```bash
# docker exec -it <sunpike-kube-apiserver-container-ID> sh -c "openssl s_client -connect localhost -port 6443 -showcerts 2>/dev/null </dev/null | openssl x509 -noout -dates"
```

{% endtab %}
{% endtabs %}

### Monitoring Cluster CA and Certs

ssh to DU VM (192.168.120.254) and run the below steps:

{% tabs %}
{% tab title="Bash" %}

```bash
sudo su
export VAULT_TOKEN=$(mysql qbert -Bse "SELECT credential_value FROM qbert_secrets where credential_name='root_token'")
export VAULT_ADDR=http://127.0.0.1:8200
export PATH=$PATH:/usr/local/bin
secrets_list=$(vault secrets list | awk '$2 == "pki" {print $1}' | grep "pmk-ca")
echo "$secrets_list" | while read secret; do echo -n "Certificate for Cluster: "; echo -n "$secret" | awk -F 'pmk-ca-' '{print $2}'; vault read "${secret}cert/ca" -format=json | jq -r '.data.certificate'| openssl x509 -noout -dates; done


# TTL 
cat /etc/pf9-vault.d/server-config.hcl | grep ttl
```

{% endtab %}
{% endtabs %}

This outputs the date on which the CA is created and the date on which it expires, per cluster. If you observe that the certs are expiring, please follow the manual steps mentioned in the following article to regenerate it: <https://platform9.com/kb/PEC/refresh-cluster-ca>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://platform9.com/kb/smcp/solution/monitoring-cert-and-ca-expiry-on-lts1-deployments.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.