Set up a site and SSL by mapping the domain to the target service, creating the site in the panel’s current interface, validating the application on a staging hostname, and issuing or revalidating a certificate for the exact names in use.
Separate the layers
A panel is an administrative layer over a web server, DNS service, runtime, and often a database or mail stack. CyberPanel uses OpenLiteSpeed, HestiaCP can use Nginx and/or Apache, CloudPanel is Nginx-only, and ISPConfig supports Apache or Nginx. DNS is built in for some panels and external for others. These differences affect which fields exist and which service answers a request; there is no universal menu sequence.
Map the domain first
List the apex name, subdomains, aliases, mail names, and any wildcard that the application needs. Confirm which DNS provider is authoritative and where the A, AAAA, CNAME, and validation records will live. Keep a temporary hostname for staging. A certificate request made before DNS points to the intended service can validate the wrong endpoint or fail for reasons unrelated to the panel.
Create the site without guessing labels
In your panel web interface, create the site using the controls exposed by the installed release. Select the document root, runtime, database relationship, and redirect policy only after checking what the application expects. Some panels expose a combined site form; others separate web, database, and DNS objects. Use the panel’s current documentation instead of assuming that a field named site, virtual host, or domain means the same thing everywhere.
Issue or revalidate the certificate
Use the certificate method supported by the panel and its current release, commonly an ACME-compatible flow when available. Verify the exact hostname set, including aliases and mail names that need TLS. Wildcard and multi-domain certificates are migration-sensitive: the certificate may need to be reissued or revalidated in the new panel’s certificate store rather than copied into place. Confirm the served certificate from an external client and check that the private key is not exposed in logs or tickets.
Test before DNS cutover
- Load the staging hostname over HTTPS and inspect the certificate name and chain.
- Submit forms, sign in, read and write application data, and check redirects.
- Review web-server and application logs for wrong roots, permissions, mixed content, or hardcoded hostnames.
- Only after sign-off, lower TTL as appropriate and change public DNS.
Keep the process release-aware
Panel releases can change certificate helpers, validation prompts, web-server defaults, and DNS integrations. Record the release and the certificate names you tested. The migration guide explains why staging and revalidation matter when a site moves between panels.