Console TLS certificates

Skyrsoft Autologon Manager’s admin console serves its own TLS certificate on port 443 — a different certificate from the internal CA that secures every agent’s connection to the server. Three modes decide where that one comes from: generated by the console itself, obtained automatically through built-in ACME, or supplied by something else entirely, whether that is an external certificate manager or you, uploading a PFX by hand. All three switch live, with nothing to restart to change mode.

How it works

One HTTPS listener serves whichever certificate the current mode has installed, and both a mode change and a certificate renewal replace it on that running listener without dropping port 443.

Only Manual mode will accept a certificate from outside the console — the other two only ever install something they generated or fetched themselves, which is what stops a stray upload or push from landing while the console is meant to be managing its own certificate.

Built-in ACME (DNS-01)

Built-in ACME needs no inbound port at all. Rather than answering an HTTP challenge on the console itself, it proves domain control by placing a TXT record at _acme-challenge.<domain> through your DNS provider’s API, waits for Let’s Encrypt to validate it, then deletes the record again. Cloudflare, AWS Route 53 and Azure DNS are the supported providers, and wildcard domains are allowed.

Set the Server FQDN at the top of Settings → Server first — it is the domain the certificate gets issued for. Staging is unticked by default, so Save requests a real certificate straight away; tick it for a first test, which issues an untrusted certificate against Let’s Encrypt’s staging service without touching the production rate limit. Test DNS provider checks that the saved credential can create and delete a record without ever contacting Let’s Encrypt, so a bad or under-permissioned credential is caught before a real request needs it to work. Once issued, renewal is automatic and starts roughly 30 days before expiry.

Letting an external manager push the certificate

Manual mode exists for exactly this: something elsewhere obtains and renews the certificate, then installs it here over the admin REST API, with no local access to this server and no restart. Skyrsoft CertOps can be that manager — its deployment targets include one built for this endpoint, and certificate deployment covers how a target reaches it from the CertOps side. CertOps sends the leaf certificate, its private key and any intermediate chain as PEM to PUT /api/admin/console-certificate, authenticated with the admin API token described below.

Remote push is refused unless the console is already set to Manual mode here — every other mode answers with HTTP 409, which is what stops a pushed certificate fighting the console’s own ACME or self-signed one. A rejected push, whether for the wrong mode or invalid material, never touches the certificate currently being served, so 443 does not go down over a bad push.

Uploading a PFX yourself

Manual mode also has its own upload panel in the console: pick a PKCS#12/PFX file — leaf, private key and any intermediates — enter its password if it has one, and install it directly, with the same validation and live hot-swap as a remote push. It is the option for a certificate you already hold and would rather not wire an integration for.

Per-mode certificate storage

Each mode keeps its own certificate in its own slot, encrypted at rest — one for self-signed, one for Manual (a push or an upload), one for ACME — and switching modes never touches the other two. Mode selection only decides which slot the console reads from next: a certificate CertOps pushed under Manual mode is still sitting in its slot, untouched, if you switch to ACME for a while and back again, and resurfaces rather than needing to be pushed a second time.

Within a slot, a new write does replace what was there — a second push overwrites the first, and an ACME renewal overwrites the certificate it is renewing — and validation always runs before that swap rather than after it, so an invalid certificate is refused rather than briefly served and then replaced. If a mode’s own slot is empty, or the certificate in it has expired, that mode falls back to a self-signed certificate rather than serving nothing on 443.

Server FQDN, hostname pinning and HSTS

The Server FQDN at the top of Settings → Server is the one name for this server: operators reach the console at it, and the Deploy page, push installs and enrolment files give it to agents as the server address (a wildcard is skipped for agents). It also feeds the ACME domain above and two toggles beside it. Pin to this hostname refuses admin and console traffic addressed to anything else — a raw IP address, say — once DNS and a certificate for that FQDN both exist. It is off by default and a no-op while the FQDN field is blank, so turning it on can never lock out a fresh install, and it applies immediately. Agent traffic and the admin API stay exempt from pinning either way, because both authenticate themselves and are routinely reached by callers with no reason to know this hostname. Enable HSTS tells browsers to use HTTPS only for this console from then on, and unlike pinning it needs a service restart to take effect whichever way you’re setting it — a browser that has already cached an HSTS policy is much harder to walk back than most settings, so that extra step is deliberate.

Ports and the admin API token

HTTP and HTTPS ports default to 80 and 443. The HTTP port always redirects to HTTPS and cannot be turned off; both ports are read once when the console starts, so changing either needs a restart, and the save check requires the two to differ from each other and from the agent and admin API ports, so a typo can’t take the whole console down at the next restart instead of failing here. Restart service applies a pending port or HSTS change immediately: it schedules the Windows service to stop and start a few seconds out, giving the response time to reach your browser first, then the page polls until the console is back and reconnects on its own.

The X-Admin-Token that authorises the certificate push — and the rest of the admin REST API — is created automatically on first run and stored encrypted, never in plain text on disk. Reveal and copy it from Settings → Server to set up an integration, or rotate it to issue a new one; the old token stops working immediately, so update anything using it, CertOps included, right after.

Limits

Agents keep the server address they enrolled with. New agents get the Server FQDN, but an agent that has already enrolled keeps the address it enrolled with, so changing the Server FQDN means redeploying the agents.

A self-signed certificate follows the Server FQDN. It names the Server FQDN when one is set, then the machine’s own name and localhost, and it is re-issued when those names change. Browsers still warn about it until an uploaded, pushed or ACME certificate replaces it.

A write to the Manual slot has no undo. A push or upload replaces whatever certificate was already in that slot, so a certificate that turns out to be wrong in some way validation does not catch — the wrong SAN for how you actually front the console, for instance — is fixed with another push or upload. Switching away to a different mode does not help either, since the flawed certificate is simply what is waiting in the Manual slot when you switch back.

Certificate material and the admin API token are encrypted to this specific machine. That is not portable: rebuilding the server does not carry either across, whichever mode you were running, and a fresh install starts from self-signed again regardless of what the old one was.

Only built-in ACME can issue a wildcard. A Manual push or upload serves exactly whatever certificate the external manager or the file you chose contains, wildcard or not.