SSL Certificates — Reference
The SSL Certificates surface is the platform's TLS-certificate management plane. It owns the lifecycle of the certificates the site presents on HTTPS — auto-provisioned certificates issued by the platform's managed certificate authority, customer-uploaded certificates for cases where a specific issuer is required, the per-domain assignment that decides which certificate answers which hostname, expiry monitoring, and the renewal flow that prevents lapses.
This page is a reference for platform engineers and integrators who need to understand the surface before extending it, scripting against it, or scoping a certificate-rotation playbook. Customer-facing how-tos live in the customer docs set; this page describes the shape of the surface, not the steps to drive it.
Overview
SSL certificates live under the Domains → Certificates view in SG-Admin, paired with the domain assignment screen on the adjacent tab. The view renders three primary panels — the certificate list, the certificate detail / edit form, and the upload-new flow — and exposes write operations for provisioning, uploading, assigning, renewing, and revoking certificates.
The platform supports two certificate origins on the same surface. Auto-provisioned certificates are requested by the platform on the operator's behalf when a domain is added; the certificate authority validates the domain (via HTTP-01 or DNS-01 challenge) and the resulting certificate is stored and assigned automatically. Uploaded certificates are PEM-encoded chains the operator brings from an outside issuer; they are stored, validated, and assigned the same way.
Renewal is the operationally important half of the surface. Auto-provisioned certificates are renewed by a background job well before expiry; uploaded certificates do not auto-renew (the platform has no private key to talk to the foreign authority) and instead surface expiry warnings as a dashboard signal and email alert.
Where it lives in SG-Admin:
- Sidebar: SG-Admin → Domains → Certificates
- URL prefix:
/sg-admin/domains/certificates - View templates:
application/views/Admin/Domains/certificates-*.php
┌──────────────────────────────────────────────────────────────────────┐│ SG-Admin → Domains → Certificates [+ Upload new] │├──────────────────────────────────────────────────────────────────────┤│ Domain Origin Issued Expires Status ││ ──────────────────── ──────────── ──────────── ─────────── ─────── ││ example.sgen.com Auto 2026-04-12 2026-07-11 Active ││ www.example.com Auto 2026-04-12 2026-07-11 Active ││ shop.example.com Uploaded 2025-11-20 2026-11-20 Active ││ legacy.example.com Uploaded 2025-02-10 2026-02-10 Expired ││ ││ [⋯ View] [⋯ Renew] [⋯ Replace] [⋯ Revoke] │└──────────────────────────────────────────────────────────────────────┘Actions
The SSL Certificates surface exposes the following operations. Each is described by what it does to the certificate store, not by its internal method name.
List and search
Returns the certificate records visible to the current operator, paginated, with domain, origin, issued date, expiry date, and status columns. Supports column sort, free-text filter on domain name, and a "near expiry" filter for surfacing certificates within 14 days of expiry.
Provision (auto-issued)
Triggered automatically when a new domain is added under the Domains surface, but also exposable as a manual action on this surface when a domain was added without provisioning. The platform issues a certificate-signing request, the managed certificate authority validates the domain, and the resulting certificate is stored and assigned to the domain. The operation is asynchronous — the surface returns immediately with a pending status and updates to active when the issuance job completes.
Upload (operator-supplied)
Accepts a PEM-encoded certificate chain plus the corresponding private key. The surface validates the chain (well-formed, key matches certificate, full chain to a known root), checks the domain CN / SAN list against the configured domains, and stores the bundle. On save, the certificate is assigned to its matching domain unless the operator explicitly defers the assignment.
Assign to domain
A separate action when a certificate covers multiple domains (multi-SAN) or when the operator wants to swap which certificate answers a given hostname. Submit re-points the domain's TLS termination at the named certificate. The change propagates to the edge layer within seconds.
Renew
For auto-provisioned certificates: re-runs the issuance flow against the managed certificate authority. The previous certificate stays active until the new one is issued and verified; there is no off-period. For uploaded certificates: the action opens a replacement-upload flow rather than auto-renewing.
Replace
For uploaded certificates: accepts a new chain and private key for an already-tracked certificate. Used when the operator has obtained a fresh certificate from their external issuer. The new bundle replaces the old one in place, preserving the certificate's domain assignment.
Revoke
Removes the certificate from the store and from any domain it was assigned to. The domain falls back to either another assigned certificate (if one exists for the hostname) or to a temporary platform-default certificate while the operator provisions a replacement. Revocation is logged with timestamp + acting operator.
Inspect
Returns the parsed certificate detail — issuer, subject, SAN list, validity window, key strength, fingerprint, chain. Used both by the form view (as a read-only panel) and by integrators that need to audit a deployed certificate without leaving the platform.
┌──────────┐│ pending │ issuance job running└────┬─────┘│ CA returns cert▼┌──────────┐ renew triggers reissue│ active │ ◄────────────────────────────┐└────┬─────┘ ││ │┌────────────┴────────────┐ │▼ ▼ │expires_at <= now operator revokes ││ │ │▼ ▼ │┌──────────┐ ┌──────────┐ ││ expired │ │ revoked │ │└────┬─────┘ └──────────┘ ││ ││ operator re-provisions or uploads replacement │└─────────────────────────────────────────────────┘Data model
A certificate record carries the following fields. Field names below are the conceptual shape — the on-disk column names match closely but are not contractually stable across releases.
| Field | Type | Notes |
|---|---|---|
id | integer | Primary key. Stable across renewals only when the renewal happens in place. |
origin | enum | auto (issued by the managed CA) or uploaded (operator-supplied). |
domain | string | Primary hostname. Resolves against the Domains surface. |
san_list | list | Additional hostnames covered. |
issuer | string | Issuing authority. |
subject | string | Subject DN. |
fingerprint_sha256 | string | Hex string. Used as a tamper check during renewals. |
issued_at | timestamp | From the certificate. |
expires_at | timestamp | From the certificate. Drives the expiry warning system. |
status | enum | pending (issuance in flight), active, expired, or revoked. |
created_at | timestamp | Set on first save. |
updated_at | timestamp | Touched on renewal or assignment change. |
Multi-SAN certificates: a single certificate covering multiple hostnames produces one record with a populated san_list. Assignment is keyed on the hostname, so the same certificate record can answer for several domains at the edge.
┌──────────────────────────────────────────────────────────────────────┐│ Certificate detail · example.sgen.com │├──────────────────────────────────────────────────────────────────────┤│ Origin Auto (managed CA) ││ Issuer SGEN Trust Services ││ Subject CN=example.sgen.com ││ SAN list example.sgen.com, www.example.sgen.com ││ Fingerprint sha256:8f23…d091 ││ Issued 2026-04-12 09:14 UTC ││ Expires 2026-07-11 09:14 UTC (in 51 days) ││ Status ● Active ││ ││ Assigned domains example.sgen.com ✔ ││ www.example.sgen.com ✔ ││ ││ [Renew now] [Revoke] │└──────────────────────────────────────────────────────────────────────┘Permissions
Access to the SSL Certificates surface is gated at two layers.
Layer 1 — admin gate. Every action under SG-Admin passes through the platform's standard admin access check at request entry. An unauthenticated request never reaches the SSL Certificates surface.
Layer 2 — per-action capability. Within SG-Admin, each certificate action checks a capability associated with the calling operator's role. The default role configuration ships with three roles — Administrator, Editor, Viewer — and the capability map is:
| Capability | Administrator | Editor | Viewer |
|---|---|---|---|
| List certificates | yes | yes | yes |
| Inspect certificate | yes | yes | yes |
| Provision (auto) | yes | no | no |
| Upload | yes | no | no |
| Assign to domain | yes | no | no |
| Renew | yes | no | no |
| Replace | yes | no | no |
| Revoke | yes | no | no |
Self-protection rules. The surface refuses to revoke the certificate currently serving the SG-Admin hostname itself — locking the operator out of the very surface they need to recover is treated as a structural mistake and rejected. The fallback path requires a host-level operator override.
Audit. Every write — provision, upload, assign, renew, replace, revoke — emits an Activity Log entry. The log records the acting operator, the affected certificate, the affected domains, and the change shape. Private-key material is never logged. Activity Log retention is governed by the site's general settings.
Related references
- Domains — Reference. Owns the domain records that certificates are assigned to. Adding a domain there triggers auto-provisioning here.
- SEO — Reference. Indirectly affected — once HTTPS is active, the platform rewrites canonical and Open Graph URLs to the secure scheme.
- Robots.txt — Reference. The served
/robots.txtfollows the active certificate's host; certificate changes propagate into the sitemap pointer the same way domain changes do. - Settings — Reference. Owns the role definitions, expiry-warning thresholds, and Activity Log retention.
- Users — Reference. The acting operator for every audit-logged certificate operation resolves to a user record.
/docs/domains/ssl.