The console certificate

Cert Camel

Home Guides Security

Cert Camel serves its own page over HTTPS using a certificate it issued itself. This page is about that one certificate: where it lives, how to replace it by hand, and how to get back in when it stops working — because the thing that would normally warn you is the thing that is down.

1. Where it lives

Inside the Cert Camel folder, one directory per certificate, named for the name it covers. Nothing is in the Windows certificate store, and nothing is machine-wide.

<install folder>\certs\tracker.example.com\
    fullchain.pfx     <- what the server loads and serves
    cert.cer          <- what discovery reads to decide which certificate covers the name
    cert.pem, chain.pem, fullchain.pem, cert.key
    history\          <- previous certificates, archived on every renewal
Two files decide whether it is used at all

The server asks which certificate on disk covers its own name. That search skips any folder missing either cert.cer or fullchain.pfx — so a perfectly good certificate copied into the right folder can be ignored with no error anywhere, while the console quietly falls back to plain HTTP.

The .pfx also has to open with the one password the server uses. That password is Posh-ACME's default and protects nothing — the matching private key sits beside it in cert.key in the clear — but a .pfx exported with any other password is simply skipped.

You do not need to know any of that to replace one. Section 3 is a script that handles both traps.

2. There is no HTTPS switch

There used to be a tick-box marked “Serve this page over HTTPS” beside the hostname. It is gone, and its absence is deliberate: two controls for one meaning could disagree, and the disagreement was resolved by the server coming up on plain HTTP and writing the reason to a log nobody had open.

The hostname is the switch. Set a name under Settings → Tracker address and the console serves HTTPS on it. Clear the name and it serves plain HTTP on 127.0.0.1. There is no third state.

127.0.0.1 keeps working either way, on the same port. That is not a leftover — it is the way back in when the name stops resolving or the certificate lapses, and section 4 depends on it.

3. Replacing it by hand

Run these from a PowerShell window in the Cert Camel folder. They need administrator, like everything else that writes here.

See what has been archived. Every renewal keeps the certificate it replaced, complete with its fullchain.pfx:

powershell -ExecutionPolicy Bypass -File .\resources\import-console-cert.ps1 -HostName tracker.example.com -List

Put one back. This needs nothing from outside the folder and is the fastest way out of a renewal that produced a certificate you cannot use:

powershell -ExecutionPolicy Bypass -File .\resources\import-console-cert.ps1 -HostName tracker.example.com -FromHistory

That restores the newest archive that is still valid, not simply the newest. The archive directly behind a dead certificate is very often the one that just expired, and handing it back is not a recovery. Name a specific one with -Stamp if you want a different answer.

Import one from elsewhere. A .pfx carries the certificate, its chain and its private key in one file:

powershell -ExecutionPolicy Bypass -File .\resources\import-console-cert.ps1 -HostName tracker.example.com -Path C:\temp\tracker.pfx -Password <its password>

Every check happens before anything on disk moves. A certificate that does not cover the name, or has expired, or has no private key is refused with the folder untouched — replacing a working certificate with a broken one takes the console down, and the console is what would have explained why.

A PEM pair has to be converted first

Windows PowerShell 5.1 runs on .NET Framework, which cannot read a PEM private key. Convert it and import the result:

openssl pkcs12 -export -out tracker.pfx -inkey cert.key -in cert.cer -certfile chain.cer

If the certificate is one Cert Camel issued, -FromHistory needs none of this.

The running console picks up a replacement within two minutes, or immediately if you restart it.

4. Getting back in

Three ways, in the order worth trying.

Use the loopback address. http://127.0.0.1:<port> works whether or not the name resolves and whether or not the certificate is valid. The port and the one-time token are both in jobs\session.json; opening Open Tracker.bat reads them for you.

Start it without TLS. If the certificate is the problem, -NoTls brings the console up on plain HTTP and skips loading it entirely:

powershell -ExecutionPolicy Bypass -File .\resources\serve.ps1 -NoTls

Use the recovery script. sos-plain-http.ps1 in the install folder exists for the case where the settings themselves are what is wrong.

HSTS is the one that can genuinely lock you out

If you turned on Strict-Transport-Security, a browser that has seen this name will refuse to reach it over HTTP and will not offer a way past a certificate error. Turning the setting off does not clear a policy a browser already holds.

127.0.0.1 is unaffected — the policy is attached to the name, not the machine — which is the other reason loopback is never turned off.

5. Why it might stop renewing

The console's certificate is renewed like any other, which means it needs the same two things: the name has to be watched, and a configured DNS credential has to cover its zone. Renewal validates through the DNS API, so a certificate in a zone no provider can see is one nothing will renew, however it was issued.

Settings → Tracker address reports both, along with whether the name is in the hosts file and whether anything else holds the port. If renewal there is red, that is the answer — and it is worth acting on before the ninety days are up rather than after, because the page that tells you is the page that goes down.

A certificate issued by hand outside Cert Camel is picked up automatically once a provider covers the zone. Renewal has an explicit branch for certificates it did not issue.