Skip to main content

How to configure Avassa certificates for extended offline periods

In scenarios where an Avassa-managed site is expected to be offline for extended periods, such as 6 months, the system's certificates must be configured accordingly to ensure seamless reconnection when the site returns online. Typically, setting the disconnected-grace-period is sufficient, as default values for certificates are automatically derived from it.

Step-by-step instructions​

Set the Offline Grace Period​

Update the disconnected-grace-period to reflect your expected maximum offline duration. For a site offline for 6 months, set it as follows:

system:
  sites:
    disconnected-grace-period: 180d

Certificate Expiry Alerts​

Avassa generates alert notifications when a site or host certificate is nearing expiration. These alerts appear on the system:alerts topic as a host-certificate-expires event and include information such as the hostname, site name, and expiration date.

Example of an alert notification:

supctl do volga topics system:alerts consume --follow --payload-only
{
  "alert": "host-certificate-expires",
  "time": "2025-03-26T13:34:05.509Z",
  "id": "host-certificate-expires/udc1/h05",
  "site": "topdc",
  "kind": "security",
  "severity": "critical",
  "description": "Host certificate will expire soon.",
  "expiry-time": "2025-03-27T13:34:05.509Z",
  "cleared": false,
  "data": {
    "hostname": "h05",
    "site": "udc1",
    "expires": "2028-10-18T13:33:56Z"
  }
}

Monitoring Certificate Status​

You can monitor the status of CA and host certificates for sites using the following commands:

  • Site-level certificate status:
supctl show system site-status sites

Example output:

- name: udc1
  hosts-with-critical-certificates: 0
  cluster-ca-certificate-expires: 2y349d23h59m28s
  api-ca-certificate-expires: 1y39d23h59m28s
  • Host-level certificate status:
supctl show system site-status sites <site-name> hosts-summary

Example output:

hosts:
  - host-id: 33245851-e8aa-4e9c-9007-20c23f129b64
    hostname: h05
    cluster-certificate-expires: 134d23h59m38s
    api-certificate-expires: 134d23h59m38s

Recovering Expired Certificates​

If a host detects that its certificates have expired due to prolonged offline periods or downtime, it will automatically attempt to recover new certificates from the Control Tower using its recovery token. When Control Tower receives such a recovery request, it generates a critical alert reauthorize-requested. An example alert is:

{
  "alert": "reauthorize-requested",
  "id": "reauthorize-requested/udc1/udc1-001",
  "site": "topdc",
  "kind": "security",
  "severity": "critical",
  "description": "Host certificate recovery requested.",
  "data": {
    "cluster-hostname": "udc1-001",
    "site": "udc1",
    "peer-ip": "...",
    "permitted": true,
    "successful": true
  }
}

Administrators may then explicitly allow the host to retrieve new certificates by invoking the reauthorize action:

supctl do system sites <site-name> hosts <host-id> reauthorize <host-name>

This operation enables the host to fetch new certificates exactly once, restoring connectivity to the Control Tower.