TLS Certificates
The TLS certificates, also called SSL certificates, that secure your domains over HTTPS; a browser checks them before it shows the padlock. Not the sign-in keys or signing keys the panel uses elsewhere.
You don't set up TLS certificates in Elpan. Every domain is served over TLS from the moment it exists, and real, publicly trusted certificates arrive and renew on their own.
The Certificates pages cover the three cases beyond that default:
- checking what the server currently serves
- requesting a certificate for a name the automatic lifecycle doesn't cover
- bringing your own certificate from a specific authority
The automatic lifecycle
- A certificate the panel already holds, or a placeholder. A new domain first gets a certificate your account already holds, if one covers the name; it's trusted immediately, with no certificate authority involved. Otherwise the domain gets a self-signed placeholder: HTTPS works from the start, but the placeholder isn't trusted, so a browser warns a visitor who arrives this early.
- A real certificate, automatically. In the background, the panel requests one from a public certificate authority over the ACME protocol, the same mechanism as Let's Encrypt. The authority has to verify that the domain reaches this server, so it can only issue once the domain's DNS points here: immediately for a zone the panel hosts, otherwise as soon as you point the name.
- Renewal, always. A certificate renews automatically, well before it expires. There's nothing to remember each year.
Where possible, the server serves a domain with an RSA and an ECC certificate together, and each client negotiates what it supports.
One certificate for a domain and its subdomains
An automatic request asks for the domain and its wildcard together, e.g.
example.com and *.example.com, not for one name. The panel goes up one
label and stops at the top of the zone it holds.
Two things follow, both step 1 above:
- A new subdomain of a covered domain is trusted immediately. The certificate covering it already exists, so no authority is asked and there's no wait.
- Every host under one domain shares one certificate, and one renewal keeps them all current.
The pair above is the default; your hosting provider can set a host to ask for its exact name only. Hosts Certificate Status shows the names each certificate covers.
Hosts Certificate Status
The certificates serving traffic right now, per domain, with issuer, covered domains, and expiry. Use it to answer "is this domain still on its self-signed placeholder?" It also shows an error status if an issue attempt failed.
There's no renew button; the panel schedules every renewal itself.
| What you see | What it means |
|---|---|
| A browser warning on a very new domain | Normal. The placeholder is still in use. It corrects itself within minutes once DNS is right. |
| A warning that persists | Almost always DNS. The domain doesn't resolve to this server yet, so the authority refuses to issue. Check the name at your registrar or under DNS Records. |
Certificate authorities apply strict rate limits, and too many requests can block a domain for days, so the panel retries at a deliberate pace. After you correct DNS, wait; don't force a repeat.
Request a Certificate
Automatic issue applies to a domain with a website. A name without one, e.g. one that points at a container, or a mail host, never starts the lifecycle. The other case is a set of names you want on one certificate of your choosing.
Request a Certificate covers both. Enter the names, one per line, and select Request certificate. All of them go into one certificate.
The names you type are a specification: the panel asks for exactly those, and never widens the set the way an automatic request does.
Each name must be in your account: the panel proves control of a name to the authority, so it can only ask for names it serves or holds the DNS zone for. If a name isn't yours, or nothing in the panel can answer for it, the page says which before it sends the request.
A wildcard is accepted only if the panel holds the domain's DNS zone, because the authority verifies a wildcard through a DNS record that the panel has to write there. It adds the record itself, as a temporary record, and removes it once the authority has read it.
The request is queued. The new certificate appears on Account Certificates when the authority issues it, usually within a minute, and serves the related domains immediately.
A service this server doesn't host
The name doesn't have to point at this server. If the panel holds a name's DNS zone, it can prove control of it to the authority wherever the service itself runs: a device on your network, a mail server of your own, or a machine at another provider.
Request the certificate here, then get it from Account Certificates and install it on that machine yourself. Downloads lists the formats.
Automatic renewal starts from a website this server hosts. Nothing renews a certificate you request here, including a wildcard you type yourself.
Each website you name keeps its own automatic certificate, so those domains stay secure, but the certificate from this page expires on its date. Check it on Account Certificates and request again before then.
A wildcard the automatic lifecycle asks for is different: the panel does renew that one. See One certificate for a domain and its subdomains.
A certificate authority limits how many certificates a domain can get per week, and how often it issues the same set of names; past a limit, it refuses that domain for some days. That also stops the automatic renewals of the domain's other certificates, so a limit you reach by hand can affect your websites.
The panel therefore limits how often you can use this page. Put all the names you want in one request, and don't resend it while you wait.
Account Certificates: bring your own
Automatic issue covers almost every case. Install your own certificate only when something external calls for it: an organization-validated certificate, one from a corporate CA, or one you share with infrastructure outside the panel.
Account Certificates manages the whole lifecycle in four stages:
- Key. Generate a private key in the panel (RSA 2048, 3072, or 4096; ECC P-256, P-384, or P-521), or upload an existing key in PEM format. A key generated here never has to leave the server.
- CSR. Enter the domains the certificate must cover (a wildcard is fine) and, if you want, the organization fields. The panel builds the certificate signing request for you to send to your authority.
- Install. Paste or upload the signed certificate in PEM format, with its chain; a combined "fullchain" file works. The panel verifies that it matches the stored private key and reads the covered domains from the certificate itself.
- Activate. An installed certificate is parked and serves no traffic. Activate puts it into service for its domains, in place of the automatic certificate; Deactivate parks it again.
The gap lets you prepare a certificate before a planned switch.
- After installation, the domains and the organization fields are locked. A changed certificate is a new certificate.
- An active certificate takes precedence over automatic issue for its domains, expiry included. That becomes your responsibility.
Deleting an active certificate is safe: its domains return to automatic issue immediately and HTTPS never stops, though the domain may use the placeholder until the automatic certificate arrives.
Downloads
You can export everything for use elsewhere:
- the private key, as PEM or as PKCS#8 with a password
- the CSR
- the certificate as a leaf, a chain, or a fullchain PEM
- a PKCS#7 bundle
- a PKCS#12 bundle with a password, which Windows and Java keystores import. For Windows Server 2016 and older, and Windows 10 before version 1709, select Legacy encryption (Triple DES): those versions can't import the default AES-256 bundle and report the password as incorrect.
Whoever holds the private key can impersonate the domain. Give a downloaded key the same care.