Trust and Identity #

Deevnet runs its own private PKI: every certificate on a Deevnet site comes from Deevnet’s own certificate authorities, and is trusted only where Deevnet has installed its root. Every TLS connection verifies against that one anchor, the Deevnet Root CA. The root and each site’s Site CA are held offline by a person, never by a system. Under each Site CA, three issuing CAs separate the kinds of identity a site has:

• the Substrate CA issues the substrate’s server certificates, through automation;
• the Tenant Device CA issues tenants’ device certificates, through the tenant interface as devices are registered;
• the Tenant Service CA issues server certificates for tenants’ own services, through the tenant interface, for names in a tenant’s own zone ( ADR-0037).

The substrate builds itself without either tenant CA, and no tenant ever touches the Substrate CA.

Deevnet uses a private PKI because a public CA cannot certify what a site serves: private addresses, internal names, and device client certificates. The comparison with Let’s Encrypt and commercial CAs is in ADR-0031.

New to certificates? The Cryptography and PKI Primer explains keys, signatures, chains and CAs from the beginning.

The hierarchy: Deevnet Root CA → Site CA → three issuing CAs

For maximum integrity, the Root CA and every Site CA are generated and kept offline. Whatever holds a CA’s key can mint anything under it. With the root and Site CA held offline, no compromise of a site system, automation’s included, can create a new CA. The worst a site loses is one issuing CA, which the operator replaces in a short ceremony while every client keeps trusting the root.

Everything under a Site CA can vouch only for Deevnet’s own names and private addresses. Each Site CA is name-constrained to deevnet.net, localhost and private and loopback address ranges, so even a leaked key below it cannot make a certificate a computer trusting the Deevnet Root CA would accept for a public site.

One Deevnet Root CA serves every site; each site has its own Site CA under it. An operator’s computer, a tenant’s tooling or a device that works at more than one site trusts one anchor. A site’s own CA still bounds that site: a Site CA lost at one site is replaced without touching another.

Only a separate transfer medium crosses between the offline and online sides, and it never carries a key. The offline keys sit on media that never leaves the offline side. The transfer medium carries a signing request in, under a manifest of hashes, and a signed certificate back, under another.

Each side checks the manifest, refuses any private key on the medium, and checks the request or certificate against what it expects. The online side checks the chain against its own copy of the root. Tooling does the moving and the checking; the decision to sign is a person’s.

Substrate certificates come from automation, never from the secret store #

The substrate is built in order: the network, the hypervisors, then the service VMs, one of which runs the secret store. Each step needs certificates for the steps before it. If those came from the secret store, a site rebuilt from nothing would wait on itself.

So every substrate certificate comes from the Substrate CA, issued by automation on the control node. That covers every bare-metal host, appliance and service VM, and the services on them, the secret store’s own interface included. The Substrate CA’s key lives where automation’s other secrets do. The secret store issues nothing the substrate needs.

Server identity and device identity come from separate CAs #

Every edge device belongs to a tenant ( ADR-0032), so device identity is always a tenant’s: the tenant is named in every device certificate.

A tenant’s service is a server, and is still not the substrate’s. Its certificate comes from a CA of its own, so a tenant never holds a key certified by the CA that identifies the substrate. The API builds every name from a label and the tenant’s zone, and reads a tenant’s signing request for its public key alone, so a tenant cannot ask for a name that is not its own. The secret store’s signing role refuses a name outside tenant space as well, so the two checks do not share a fault.

A certificate is a server’s or a client’s, never both. A service that accepts devices trusts only the Tenant Device CA for its clients, so a stolen server certificate cannot log in as a device, and a device certificate cannot impersonate a service.

Tenant devices will prove their identity with client certificates (mTLS) #

This is the target for tenant devices; today they authenticate to the message broker with a username and password over TLS ( ADR-0012 §8).

1. The device makes its own key and signing request. A device that cannot do so has the tenant’s own computer make them. The tenant submits the request through the tenant interface, for a device the tenant has registered.
2. The Tenant Device CA signs it, for a registered device only. The platform checks the request names that tenant’s registered device. The certificate is valid one year, for client authentication only, with the identity urn:deevnet:<site>:tenant:<tenant>:device:<device>. It goes back to the tenant; the key never left the device.
3. Device and service each present a certificate. For example, at the message broker:
   • the service shows its substrate server certificate, and the device checks it against the Deevnet Root CA;
   • the device shows its client certificate, and the service checks it against the Tenant Device CA.
4. The service authorizes the device by the identity in its certificate. It applies that device’s permissions: its tenant’s topics, and nothing else.
5. The device renews yearly, by repeating steps 1 and 2 with a new request before the year runs out.
6. Deregistering a lost or retired device revokes it at once. The platform stops authorizing its identity, whatever its certificate says.

What crosses the substrate–tenant boundary is a signing request in and a certificate out. Device keys, and the firmware-signing keys that are the tenant’s alone ( ADR-0011 §4), never do.

Where the Deevnet Root CA is trusted #

The rules are in the Certificates standard #

The certificates themselves (subjects, names, keys, lifetimes, where each key may live) are set by the Certificates standard. The decision and its alternatives are ADR-0031.