HTTPS Certificate Management

The Sendense Hub Appliance (SHA) presents one TLS certificate on its HTTPS port (443). The same certificate secures both the web interface you sign in to and the appliance's API, so replacing it updates both at once. You manage it from Settings, TLS Certificates: inspect the current certificate, generate a new self-signed one, or upload your own certificate and private key. A successful change takes effect automatically - you do not restart the appliance. After replacing it, reload your browser and confirm the new certificate details are being served.

Viewing the page requires settings read permission; generating or uploading a certificate requires settings write permission, assigned on the Access Control page. Users with read-only settings access still see the Generate and Upload buttons, but any change attempt is refused with a permissions error.

This page does not manage the security between Sendense appliances and agents - see the last section below.

The page shows the certificate the appliance is serving right now, refreshed automatically every 30 seconds, with a Refresh button for on-demand updates.

A status badge summarizes health: green while more than 30 days remain, amber from 30 days down to 1, and red once the certificate is expired. Days remaining round down, so a certificate with less than 24 hours of validity left already displays as Expired.

Generate creates a fresh self-signed certificate entirely on the appliance, using a modern elliptic-curve key. You provide a common name (required - the hostname or IP address you use to reach the appliance, pre-filled from the current certificate), optional subject alternative names (detected as DNS names or IP addresses automatically, duplicates removed, the common name and local loopback names always included), and a validity period from 1 day to 10 years (365 days by default).

Include every DNS name and IP address that people and systems use to reach the appliance. The names on this certificate matter beyond the browser: the install command SHA generates for the CloudStack KVM host agent (snagent) embeds a download address derived from the certificate's first routable name - a DNS name if present, otherwise a non-loopback IP address. If the certificate only names an address your hypervisor hosts cannot reach, the generated install command may point at an unreachable address.

When you confirm, the certificate is created and applied automatically, and the page refreshes to show the new details.

Upload replaces the serving certificate with one issued by your own certificate authority. You supply two PEM-format files: the certificate and its private key. Before anything is applied, the appliance validates the pair: the certificate must parse and be within its validity window, the private key must be an elliptic-curve or RSA key in a standard unencrypted PEM encoding, and the key must match the certificate's public key. If validation fails, nothing changes and the reason is shown; your inputs stay in the form so you can correct and retry.

Passphrase-protected (encrypted) private keys are not supported and are rejected as an unsupported key format - decrypt the key before uploading. Certificate chains are supported: upload one file with the server (leaf) certificate first, followed by the intermediates. Only the first certificate in the file is validated and the file is served exactly as you provide it, so the leaf must come first.

Applying a new certificate reloads the appliance's web front-end, which can briefly interrupt in-flight connections. To protect running work, the page refuses certificate changes while any backup, restore, or replication job is active.

While jobs are running, the Generate and Upload buttons are disabled, and a notice shows how many jobs of each type are active with a link to the active-jobs view so you can watch them drain. The block is also enforced when you submit, so a job that started moments earlier still prevents the change. Other appliance activity does not block certificate changes - only backup, restore, and replication jobs do.

The page warns you as expiry approaches: an amber banner appears when 30 or fewer days remain, prompting you to generate or upload a replacement, and a red banner appears once the certificate has expired, warning that HTTPS connections will show certificate warnings until it is replaced.

These warnings appear only on this page - Sendense does not send email or other alerts about this certificate, and it does not renew it automatically. Self-signed certificates default to one year of validity, so put a reminder in your own calendar or monitoring to revisit this page before expiry.

The HTTPS certificate is separate from the trust material Sendense manages internally between its own components.