System configuration
System Configuration is where you manage Citrix SecurSpaces™ at the platform level. From one place, you handle your license and its features, assign platform roles, connect identity providers, turn on integrations, set up regions, and adjust a few other platform-wide options.
Note:
Only platform administrators can open System Configuration. It's separate from Platform Settings, which covers other platform-wide options such as general settings, security settings, and analytics.
Open System Configuration
Sign in as a platform administrator and select System Configuration in the top navigation bar. It opens on the License page.
To go straight there, browse to
https://<your-sds-hostname>/platform/system_configuration.
Configuration areas
The left navigation groups everything into these areas:
| Area | What you do here |
|---|---|
| License | Upload your license, review what it covers, and turn platform features on or off. |
| Platform Roles | Give users and groups platform-wide roles, such as security officer. |
| Identity Providers | Connect OAuth, SAML, and SCIM providers so users sign in and sync automatically. |
| Integrations | Connect code repositories, third-party applications, storage, and Citrix DaaS™. |
| Regions | Add regions and warm nodes for multi-region deployments. |
| Others | Set up the email gateway, data breach contact, SSH server key, terms of service, and project labels. Community Edition also includes TLS certificate management. |
Manage the platform TLS certificate
Community Edition platform administrators can open System Configuration > Others > TLS certificate to review the issuer, hostnames, and expiration date of the platform's configured Kubernetes TLS certificates.
This feature reads the configured platform and proxy TLS Secrets in the primary region. It doesn't manage external-region certificates or certificates terminated outside that configuration. OpenShift and Istio deployments don't expose certificates through this page. Certificates managed by cert-manager or another Kubernetes controller can't be replaced manually here.
Review expiration warnings
The platform checks certificates hourly. For manually managed certificates, it notifies platform administrators when fewer than 30, 14, or 7 days remain, and after expiration. It also publishes a maintenance banner for signed-in users and records an audit event. These are in-product notifications, not email.
For cert-manager-managed certificates, the platform suppresses the 30-day and 14-day warnings to allow normal automatic renewal. A warning with fewer than 7 days remaining, an expired certificate, or unreadable certificate data requires investigation. The maintenance banner clears after a subsequent check finds healthy certificates.
Replace a manually managed certificate
Before you start, keep a secure backup of the current certificate and private key and confirm that you can access the cluster if HTTPS becomes unavailable. There is no automatic rollback.
Prepare a PEM chain of 2–10 certificates with the server certificate first, followed by its issuers, and the matching unencrypted private key. The certificate must be valid now, have a Common Name, and cover both the platform hostname and the wildcard for workspace hostnames. Each field is limited to 64 KiB. Accepted key types are RSA with at least 2048 bits or ECDSA P-256 or P-384.
-
Open System Configuration > Others > TLS certificate and select Replace certificate.
-
Paste the full chain into Certificate chain (PEM) and its key into Private key (PEM).
-
Select Check certificate. Correct failed checks and review any warnings before continuing.
-
Review the listed Secrets that will be replaced, then type the platform hostname to confirm.
-
Select Replace certificate.
-
Check the new expiration date and verify HTTPS access to the platform and a workspace.
The replacement updates the listed replaceable Secrets and records the result in the audit log. Allow the ingress controller time to load the new certificate; the Azure Marketplace ingress normally takes about 15 seconds. If replacement fails after updating some Secrets, don't assume that none changed. Inspect each listed Secret and use your backup and cluster access to recover before retrying.
Caution:
The private key is visible while you paste it. Avoid screen sharing and clear your clipboard afterward. A public-trust warning doesn't prevent replacement. Use a private certificate authority only when every client trusts it; a test certificate can make the platform inaccessible.
For Azure Marketplace cluster access, backup, verification, and recovery instructions, see Renew the TLS certificate.