TLS certificates

Networking & Edge → TLS Certificates (/gravity/networks/certificates) is where you keep an inventory of the TLS certificates protecting your domains, see how close each one is to expiring, and get an audit-logged alert before that happens.

Caution

Adding a certificate here records one you already have - it does not request or issue a new certificate from a certificate authority on your behalf. You still obtain and renew certificates through your usual process (Let’s Encrypt, your cloud provider’s certificate manager, or another issuer); this screen tracks them and warns you about expiry.

Certificate inventory

The table shows each certificate’s domain, provider label (Let’s Encrypt, AWS ACM, Azure Key Vault, Cloudflare, or Custom/Manual), status, expiry date, issuer, and when it was last checked, plus summary counts at the top for total, active, and expiring/expired certificates.

Add Certificate records a domain, a provider label, and - if you already know them - issued and expiry dates, and whether it auto-renews through your own process. It does not talk to any certificate authority.

Checking and renewing

• Refresh status re-reads the certificate’s current state and updates the recorded status, issuer, and expiry date - useful after you’ve renewed a certificate yourself and want the inventory to reflect that. It is also the only way to resolve a row stuck in issuing.
• Renew behaves differently depending on the certificate type:
  • For Let’s Encrypt certificates it starts a real issuance. The row shows issuing until it completes; use Refresh status to resolve it. Do not start a second renewal while one is in flight - that forces a fresh issuance rather than resuming the first.
  • For AWS ACM, Azure Key Vault, Cloudflare and certificates you added manually, there is no issuance integration. The button is disabled and states why - renew through your own process, then use Refresh status to update the record.

Expiry alerting

Once a day, the platform compares every active certificate’s recorded expiry date against today. Any certificate expiring within 30 days is marked expiring soon and logged as a high-priority entry in your organization’s audit log - this only works if the certificate’s expiry date in the inventory is accurate, which is why running Refresh status (or keeping auto-renew information up to date) matters.

Cert rotation policies

Below the certificate table, a second list tracks rotation for individual services rather than public-facing domains - each entry has a service name, its certificate’s current expiry, when it was last rotated, a rotation interval, and an auto-rotate toggle.

Note

This list is for reviewing and acting on entries that already exist - it doesn’t currently have a way to add a new entry from this screen.

• Rotate now records that you’ve rotated a service’s certificate, updating the last-rotated timestamp and status. Like certificate renewal above, this is a record of a rotation you performed yourself, not an automated call to a certificate authority.
• The auto-rotate toggle marks whether a service is meant to rotate on its own schedule; treat the resulting status as what the platform has recorded, not independent proof a rotation actually ran.

How to use this screen

Use this screen as your source of truth for “which certificates exist and when do they expire,” and rely on the daily alert rather than remembering expiry dates yourself. For the actual issuance and renewal work, you’re still using your certificate authority or cloud provider directly - this screen doesn’t replace that step today.

What’s next

• DNS - certificates are often tied to a DNS zone you manage here
• Audit log - where expiry alerts show up
• CDN
• Firewalls & security groups