A service by ADARAZ P.S.A.
devicessl issues publicly trusted TLS certificates for devices that live on local networks — behind NAT, on addresses handed out by DHCP. The padlock closes, and the private key never leaves the device.
The problem
So the panel of a camera, a controller or a gateway on a customer's LAN has two options: drop TLS altogether, or greet its user with a red warning screen. Neither is a good look on a product you sell.
W3C closes its working group on the problem without a solution.
The IETF forms the SETTLE working group to tackle local-network TLS.
Still no standard. Devices ship either without TLS or with a warning — unless you work around it.
How it works
Every device gets its own private zone and a wildcard certificate for it. The device's local IP address is encoded as a label in the hostname, and our DNS computes the answer from the name itself — there are no records to keep, update or get wrong.
Read straight out of the label. When DHCP moves the device, it simply shows a new name.
Unique per device. Two devices on the same IP in different networks never collide.
Answered by a stateless authoritative DNS. No stale records, ever.
On first boot it generates its own private key, keeps it, and sends us nothing but a certificate request.
We handle the certificate authority, the DNS challenge and the whole issuance dance. The device just asks once a day whether something new is waiting.
The panel opens over HTTPS with no warning — on the installer's laptop, on the customer's phone, on a network you have never seen.
The exchange
Everything the device has to implement fits on one screen. No agent, no tunnel, no permanent connection — just two HTTPS calls it already knows how to make.
never sentThe private key stays on the device.
It is generated on the device, stored on the device, and never crosses the wire. Everything below carries a certificate request and a certificate — public material only. We could not hand your key over, leak it or lose it, because we never have it.
POST /v1/csrHere is what I want a certificate for.
A certificate request: the device's public key and the name it wants, signed by the key it keeps. Sent once, on first boot. This is the only thing we ever receive from it.
202 AcceptedGot it. We will take it from here.
From this point devicessl talks to the certificate authority, proves the name and orders the certificate. The device is not involved.
GET /v1/certAnything new for me?
Every 30 seconds until the first certificate arrives — then once a day, at a random hour, for the rest of the device's life.
certificateSigned, with a fresh expiry date.
The device saves it and reloads its TLS server. Renewals arrive the same way, so the padlock never lapses.
The important part
This is where devicessl differs from the well-known workarounds, which generate keys centrally and ship them out. Here the key is made on the device and stays there — we only ever see a signing request and a public key.
It matters beyond good hygiene: under EN 18031-1, a private key shared across a fleet is a breach of CCK-3, the rule against static default values in pre-installed cryptographic keys.
Why it matters
The certificate covers the whole device zone, so a new DHCP lease needs no new certificate and no call home. The device just composes a new name.
Certificates are getting shorter every year. All the renewal logic, spreading and backoff sits on our side — your firmware polls once a day and reloads.
Names resolve without a database behind them. If our service goes down, devices already holding a certificate keep serving HTTPS — only new activations wait.
Register a device, send a signing request, poll for the certificate. Three calls, and it works the same on device one and on device one hundred thousand.
For the curious
Whether devicessl fits depends on your firmware, your fleet and how your customers install the product. Write to us and we will tell you plainly whether it makes sense — and what it takes.
contact@adaraz.com