SSL certificate management in Roxy-WI 9.2

Open the service's SSL page, titled Certificates, and select a server. Use search to filter by name, path or domain, and Refresh to read the server again. The catalog includes uploaded PEM, CRT and KEY files; HAProxy also reports certificates loaded in its running process.

For HAProxy, compare the In HAProxy and On disk columns. Actions → Details shows the path and separate runtime and disk metadata. Fingerprints are labeled with their algorithm; runtime metadata uses SHA-1 and disk metadata uses SHA-256, so their displayed strings are not directly comparable.

• Configure the server's SSH credentials, Python 3 and root access or noninteractive sudo. Check cert_path in the current group's settings.
• For live HAProxy changes, configure haproxy_sock_port and an accessible Runtime API socket with admin-level access. The running HAProxy must support the certificate commands used by the requested operation.
• Keep Scheduler, Operations and RabbitMQ running: manual HAProxy application is queued work. Check that Roxy-WI can discover the complete HAProxy configuration from its systemd or Docker startup settings.
• For Docker HAProxy, persist the certificate directories and any crt-list directory. Set the correct container name and paths. Individual file mounts cannot be atomically replaced through this workflow.
• For live changes across HA servers, all linked Slaves must belong to the same group and be accessible. Certificate actions enforce service permissions, protected-server restrictions and the group's direct-deployment policy. Check permissions on every target.

Runtime application accepts a PEM bundle containing the leaf certificate first, its chain and exactly one unencrypted matching private key, up to 1 MiB. Roxy-WI checks the key and validity dates and previews the certificate's names, expiry and fingerprint. Confirm that those names cover the intended HTTPS host.

1. Select the server and click Add below the certificate catalog.
2. Enter a certificate name and choose Pem, Key or Crt (chain). Use a filename such as example.pem, without directory separators.
3. For HAProxy, leave After upload → Save to disk only selected. NGINX and Apache use the file workflow without a Runtime application selector.
4. Choose a local file or paste its contents, then click Add. Refresh the catalog and inspect the result.

The file is saved under cert_path on the selected server and linked Slaves. This action does not reload the service or create a Let's Encrypt renewal schedule. An existing filename can be overwritten: if a configuration already references it, the new material may take effect on a later reload. To replace a certificate currently served by HAProxy, use Update certificate.

Disk-only uploads do not run the live-application PEM preview. Check the file contents and the resulting service configuration before applying them. File copying is separate from the queued HAProxy transaction and does not provide its cross-target rollback.

Use this when an HTTPS bind already loads a certificate directory or crt-list. The destination selector lists existing sources reported by HAProxy; it does not create a new listener. For the first HTTPS bind, follow the SSL offloading guide.

1. Select the HAProxy server, click Add and enter a new, unused .pem name.
2. Choose Pem and After upload → Apply immediately to HAProxy without reload.
3. Select a Certificate destination: an already loaded crt-list or directory. The selected source must be usable on every linked HA target. A PEM path used in a crt-list cannot contain whitespace or #.
4. Select a PEM file or paste the bundle. Review the validated certificate preview and click Add.
5. The History dialog opens. Wait for Completed and inspect the result for each server, then check the certificate presented for the intended hostname.

Roxy-WI saves the PEM and, for a crt-list, its file entry, validates the complete HAProxy configuration, and attaches the certificate through Runtime API. New TLS connections can use it without a reload; existing connections remain open. Disk state is preserved for subsequent service starts. A name collision on any target blocks creation; use the update action for an existing certificate.

1. Find the certificate and confirm that it is loaded and On disk shows Matches.
2. Open Actions → Update certificate. Review the current certificate and its path.
3. Choose the replacement PEM file or paste the complete bundle. Review the new names, expiry and fingerprint.
4. Click Save and apply to HAProxy and follow the operation in History.

The operation updates the same file on disk and the certificate loaded by HAProxy, validates the full configuration and verifies the result through Runtime API. It also applies to linked Slaves. No reload is requested for this manual workflow. A disk/runtime mismatch, changed file, another active certificate transaction, unavailable Runtime API or insufficient permissions blocks application.

If a certificate is Not loaded, configure and apply its HTTPS bind first. If it Differs, inspect the runtime and disk details, decide which certificate should be served and reconcile them through your normal validated configuration/reload procedure before retrying.

Click History for the selected HAProxy server. It shows operation time, certificate, action, status and Results by server. Use the page controls or choose 10, 25 or 50 rows per page. Queued and running operations refresh automatically.

A failure during application triggers rollback of the attempted targets. Check whether each target is Applied, Rolled back, Not applied or Failed. A failed operation is not proof that every server has recovered.

If finalization or rollback remains incomplete, restore connectivity and use Resume recovery when offered. This resumes the saved recovery phase. For a failed operation whose rollback has finished, refresh the catalog and submit a new update after correcting the cause. Do not overwrite files or start a competing certificate change while recovery is pending.

For Runtime is unavailable, check HAProxy and its socket port; for missing admin access or unsupported commands, correct the socket permissions or service capability. For configuration validation errors, correct the complete configuration. If HAProxy restarted during an update, inspect History and refresh the catalog before retrying.

Actions → View displays the certificate blocks from PEM/CRT files without their bundled private keys. Viewing a separate KEY file requires write-level permission. Details is the metadata view.

Actions → Delete removes a file from the selected server after confirmation. It is not an HA-wide deletion. For HAProxy, deletion is blocked while the file is loaded or Runtime state cannot be verified. Remove the configuration references and apply that configuration first, then refresh the catalog. The deletion also checks the file revision and validates the complete HAProxy configuration, restoring the file if validation fails.

Deleting a file does not revoke a certificate or stop a managed Let's Encrypt renewal. To stop managed issuance, use the separate Let's Encrypt deletion workflow.

The NGINX and Apache SSL pages provide a disk catalog, search, upload, Details, View and Delete. They do not show HAProxy runtime state, Update certificate, immediate Runtime application or its History dialog.

After uploading the certificate and key, reference the correct files in the selected service's configuration, validate and apply it through that service's normal workflow. File upload does not reload NGINX or Apache. Before deleting a file, check those configuration references yourself: the HAProxy loaded-certificate safeguard does not apply to these services.

The Let's Encrypt table remains a separate part of the SSL page, with Create, DNS profiles, staging checks, renewal status and its own operation diagnostics. Follow Save draft → Check setup (staging) → Issue certificate to create an ACME-managed certificate.

In 9.2, managed deployment uses the shared certificate engine: a certificate already loaded by HAProxy is replaced through Runtime API; a first deployment that is not loaded follows the validated reload path. Do not assume that every Let's Encrypt operation is reload-free. Manual uploads and replacements do not create or change ACME renewal settings; a later managed renewal can replace manually supplied material at the managed PEM path.