Key pairs
A key pair is a piece of cryptography: two matching keys. What one of them encrypts or signs, only the other one can undo.
- The private key stays put. It is never sent anywhere, and whoever holds it is the identity.
- The public key is not a secret. It is handed out freely and ends up inside the certificate.
The private key cannot be worked out from the public one. That gives you signing: sign with the private key, and anyone with the public key can check it was you and that nothing was altered.
Which device stands on which side depends on the exchange: over HTTPS the camera proves itself to your browser, under 802.1X to the authentication server. In EAP-TLS both sides prove themselves.
The data being signed is fresh every time and chosen by the other side. A signature captured yesterday is worth nothing today.
Two key types are in normal use. RSA (2048 or 3072 bit) is accepted everywhere, elliptic curve (usually P-256) does the same job with smaller keys and less work, which suits cameras and switches.
What a certificate is
A public key on its own carries no name. A certificate binds it to one and adds the signature of an authority that vouches for the binding. The format is X.509, the same on cameras, switches, servers and websites.
Every field above is public. That is why sending someone a certificate costs you nothing.
The private key is not in the certificate. That is what tells the files apart:
- .crt, .cer, .pem: certificate only, safe to mail or upload anywhere. PEM is the text form, DER the same content in binary.
- .p12, .pfx (PKCS#12): certificate and private key in one password protected file. An identity in a file.
- .csr: a request for a certificate. It carries the public key and the wanted name, while the private key stays behind.
CAs and the chain
A certificate authority is a key pair with one job: signing other certificates. Its own certificate is what other machines are told to trust.
- A root CA signs its own certificate. Nothing in the file proves it is genuine, it is trusted only because someone installed it on purpose.
- An issuing CA (also called intermediate) is signed by the root and does the daily issuing, so a mistake there can be replaced without touching your devices.
- An end entity certificate is the one on a camera, a server or a user. It is marked as not a CA, so it cannot sign anything further.
Each certificate names the one above it. Verification walks upward and has to end at something already trusted. Drag the nodes if you like.
The camera certificate names its issuer, the issuer names the root. If that walk ends at a root the checking machine does not have, verification fails, however correct the rest is. That is the browser warning on a device that otherwise works fine.
A device sends its own certificate and any intermediates, never the root. Anyone can send a root, so sending it would prove nothing.
How it is checked
Valid is shorthand for a fixed list of checks, and all of them have to pass. Failures come back as one unhelpful error, so it pays to know which line actually broke.
- SignatureEvery certificate in the chain is verified with the public key of the one above it.
- Trusted issuerThe chain has to end at a root that is already in this machine's trust store.
- Validity datesThe current time has to sit inside not before and not after, on every certificate in the chain.
- NameThe name that was asked for has to appear in the Subject Alternative Name.
- PurposeThe key usage has to allow this role, server authentication or client authentication.
- RevocationWhere a revocation list is configured, the serial number must not be on it.
- Proof of the private keyThe peer signs fresh data from this connection. Without this, a certificate copied off the wire would be enough to impersonate.
Pick a scenario to play it through.
Two of them bite most often. A camera with a wrong clock rejects perfectly good certificates and only logs a failed handshake, and the proof of the private key is what makes public certificates safe to hand around at all.
Trust is local
There is no global list of trusted certificates. Every machine keeps its own, so a certificate a laptop accepts can be refused by the camera next to it, and both are correct.
Missing the root in one place is the usual reason something works from one PC and not from another.
A private root therefore has to be installed everywhere a check happens:
- The PCs you browse from. On Windows, Trusted Root Certification Authorities. Local Machine covers every user, Current User only your account.
- The VMS or recording server. It checks every camera it connects to. Forgetting it looks like a VMS that will not add a camera over HTTPS while the browser opens it fine.
- The cameras, so they trust the servers they talk to.
- The authentication server, as the list of client CAs it accepts.
Installing a root is a real decision: from then on its holder can issue a certificate for any name that machine will accept. Keep the root private key where it was generated, and check the fingerprint when you import.
Expiry and renewal
Every certificate has an end date, and that is the point. It caps how long a leaked key stays useful, whether or not anyone noticed the leak.
A new key pair and a new certificate, requested before the old one runs out. Nobody is standing at the switch when it happens.
Short lifetimes are only safe if renewal happens without a person. Renewing sixty cameras by hand is where certificate projects die: an expired client certificate closes the switch port, and the switch reports a failed login rather than an expired certificate.
Three rules follow.
- Automate renewal. A device that can request a new certificate before the old one runs out never has an expiry problem. That is the entire job of EST, covered in chapter 2.
- Keep time correct. Validity is measured against the device clock, so push NTP to everything that holds a certificate.
- Watch expiry ahead of time. A warning window that raises an event weeks before the date turns an outage into a task.
Where it sits in Trustlix
The same pieces, under the names Trustlix gives them.
Two ways to ask for a certificate, one authority that signs it, three services that use the result. All of it on the same Axis device.
- Root CA. Generated on the device on first run. The private key stays there. First run
- Trust step. Installing that root on the PC you browse from, which is the trust store discussion above. First run
- Templates. The subject fields, key type and size, validity and key usages that get stamped onto every certificate issued from them. Certificates
- Local and external CAs. A local CA holds its private key and can sign. An external CA is a trust anchor only. Certificates
- Authentication server. Presents a server certificate, and decides which client CAs it accepts. Authentication server
- EST enrollment. Devices request and renew their own certificates, which is the automated renewal above. EST enrollment
- Expiry events. Certificate expiry raised as a camera event with a warning window. Events and logs
Terms in one place
The same ideas, under the names you meet in switch manuals, camera menus and Windows dialogs.
- PKI
- Public key infrastructure. The whole arrangement: keys, certificates, the authorities that sign them and the rules for checking them.
- Key pair
- Two matching keys. What one of them encrypts or signs, only the other one can undo.
- Certificate
- A file binding a public key to a name, signed by an authority. Format X.509.
- CA
- Certificate authority. The key pair and certificate used to sign other certificates.
- Root CA
- A CA that signed its own certificate. Trusted only because it was installed on purpose.
- Intermediate CA
- A CA signed by the root, used for the actual issuing. Also called an issuing CA.
- Self-signed
- A certificate signed with its own key. Every root is self-signed. A self-signed server certificate is a root nobody trusts.
- CSR
- Certificate signing request. The public key plus the requested name, sent to a CA to be signed.
- Subject
- Who the certificate is for.
- Issuer
- Who signed it.
- SAN
- Subject Alternative Name. The host names and IP addresses actually compared during a connection.
- EKU
- Extended key usage. What a certificate is allowed to do, such as server authentication or client authentication.
- Trust store
- The local list of root certificates a machine accepts. Per machine, sometimes per user.
- Fingerprint
- A hash of the whole certificate, used to compare two copies by eye.
- PEM and DER
- Text and binary encodings of the same certificate.
- PKCS#12
- A password protected file holding a certificate together with its private key. Extension .p12 or .pfx.
- CRL
- Certificate revocation list. How an issuer announces that a certificate is no longer valid before its end date.
- Chain
- The line from a certificate up through its issuers to a root. Verification follows it.
- 802.1X
- The standard that keeps a switch port closed until whatever is plugged into it has authenticated. Chapter 3.
- EST
- Enrollment over Secure Transport, RFC 7030. How a device requests and renews its own certificates. Chapter 2.
What EST does
EST (Enrollment over Secure Transport, RFC 7030) lets a device ask a CA for its own certificate over HTTPS, and ask again for a fresh one before the old one runs out. That removes the part of chapter 1 that does not scale: issuing and renewing by hand.
- The device makes its own key pair, so no private key travels and there is no file to hand around.
- Both ends check each other's certificate before anything is issued.
- The same setup covers the first certificate and every renewal after it.
You point the device at the server once, during deployment. After that it looks after its own certificates.
One enrollment
An enrollment is five steps, and the device drives all of them.
- 1The device generates a key pairThe private key is created on the device and stays there.
- 2It builds a requestThe public key plus the name it wants, signed with the private key to prove it holds it.
- 3It connects to the EST serverThe device shows a certificate it already has, and checks the server's certificate in return.
- 4The server decidesIt checks whether it trusts the device, then applies the profile: which CA signs, for how long, and for what.
- 5The CA signs, the device installsThe new certificate goes straight into the service it was issued for, and the device schedules its next renewal.
No operator, no file transfer, nothing to copy. A request goes out, a certificate comes back, and both are public.
When an enrollment fails it is almost always one of four things: the EST port is not reachable, the device's own certificate is not trusted by the server, the profile is disabled, or a clock is wrong.
The first certificate
Step 3 needs a certificate the device already has. EST does not create that first identity, and there are three ways a device gets one.
- Axis devices ship with one. The factory AXIS Device ID certificate identifies a genuine device, so it can enroll out of the box if the server trusts the Axis device ID roots.
- A device you already issued to uses that certificate to enroll for anything else it needs.
- Everything else gets one pushed. Trustlix's deployment signs in to the device with stored credentials, installs a certificate, and points it at the EST server for everything after that. Fleet deployment
Profiles
A profile is one enrollment address, and it carries every issuing decision behind that address. Its name is part of what you point the device at.
- Which CA signs, and for how long.
- Key type and size, and the allowed usages: server authentication, client authentication, or both.
- What names are accepted or enforced in the SAN.
A camera web server certificate and an 802.1X client certificate want different usages and often different lifetimes, so they come from different profiles.
A disabled profile still exists but refuses enrollment, which is the clean way to close one endpoint without touching the devices using another.
Renewal
A certificate that renews itself never expires in service. The device re-enrolls well before the end date, presenting its current certificate as the identity for the request.
Same protocol, same profile, new key pair and new certificate. This runs for the life of the device.
Two things still need watching. A device that stays powered off past its expiry date loses the identity it renews with and falls back to the bootstrap case, and a device with a wrong clock can decide it is not time to renew yet, or refuse the certificate it gets back.
Where it sits in Trustlix
Trustlix runs the EST server on the camera itself.
- The server listens on port 22224 by default, so that port has to be reachable from the cameras. Changing who it trusts takes effect immediately, with no restart. EST enrollment
- Two profiles are seeded, https and dot1x, ready to use. EST enrollment
- The Axis device ID roots are preinstalled as trust anchors, so genuine Axis devices can enroll immediately. Certificates
- Deployment binds profiles to services on the target device (web server, 802.1X, RTSPS), and the device takes over the lifecycle from there. Fleet deployment
- EST issued and EST denied are camera events, so refusals are visible without reading logs. Events and logs
What 802.1X does
802.1X keeps a switch port shut until whatever is plugged into it has proved who it is. Until then the port carries nothing: no IP address, no video, no access to the rest of the network.
That matters in surveillance because cameras hang in corridors, car parks and stairwells. Anyone who can reach the cable can unplug a camera and plug in a laptop, and without 802.1X that laptop is on your network.
The switch never decides anything itself. It relays the conversation and then does what the server tells it.
- The device holds a certificate and proves it, which is the signing from chapter 1.
- The switch blocks the port, passes messages through, and opens or leaves it closed.
- The authentication server (RADIUS) checks the certificate and answers accept or reject.
Why EAP-TLS
RADIUS is the language the switch and the server speak. What travels inside it is EAP, and EAP comes in several methods. The method decides what counts as proof.
- Password methods (PEAP, EAP-TTLS) still put a shared secret on the device. That is the problem from chapter 1, moved onto the switch port.
- EAP-TLS uses certificates on both sides. The device proves it holds a private key, the server proves the same, and there is nothing to type, store or rotate.
Trustlix's authentication server speaks EAP-TLS, so every device that wants a port needs a client certificate. That is the same certificate EST issues and renews in chapter 2, which is why the two features are usually set up together.
One port login
From plugging in the cable to having a network is six steps, and it usually takes under a second.
- 1The camera is plugged inThe port is up but blocked. Nothing passes.
- 2The switch asks who is thereIt forwards the answer to the authentication server, and nothing else.
- 3The two ends swap certificatesThe camera sends its client certificate, the server sends its server certificate, and each checks the other.
- 4The camera proves the private keyIt signs fresh data from this session, so a copied certificate is not enough.
- 5The server runs the checks from chapter 1Trusted issuer, dates, purpose. Any failure is a reject.
- 6The switch opens the portOn accept, and on the VLAN the server names. On reject it stays closed.
No password exists anywhere in this exchange, so there is none to leak, share or rotate.
What the server needs
An authentication server needs three things set before any port will open.
- Its own server certificate. The device checks it, so it has to be issued by a CA the devices trust.
- A list of client CAs it accepts. This is the real access rule: a device whose certificate does not chain to one of them is rejected, however genuine it is.
- Every switch registered by IP address with a shared secret that matches on both sides. Requests from an unknown address are dropped without an answer.
VLAN assignment
Accept does not have to mean the same network for everyone. The server can name a VLAN in its answer, and the switch puts that port there.
The useful rule is to key it off the CA that issued the certificate. Cameras issued by the camera CA land on the camera VLAN, anything issued elsewhere lands somewhere with less to reach.
Decided per port, at the moment the device authenticates. Move a camera to another port and its VLAN follows it.
- One issuing CA maps to one VLAN ID, in the range 1 to 4094.
- A CA that already has a policy cannot be mapped twice, so a device can only land in one place.
- The switch has to know the VLAN as well. The server names it, the switch has to have it configured.
MACsec
802.1X decides who gets on the network. MACsec (IEEE 802.1AE) protects what runs over the link afterwards, by encrypting the traffic on the wire itself.
It is optional and off by default, and it only works if the switch is set up for it on that link. Turning it on at one end alone breaks the connection.
- Dynamic CAK derives the key from the 802.1X session that just succeeded. Preferred, because there is no key to distribute or store.
- Static CAK and CKN are a key and its name, entered by hand and matching exactly on both ends. This is the shared secret problem again, so use it only where dynamic is not available.
When a port stays closed
The switch reports a failed login and little else, so work down this list.
- The camera has no client certificate, or it is not the one the port expects.
- The certificate expired, or a clock is wrong on either end.
- The issuing CA is not in the server's client CA list.
- The switch is not registered on the server, or the shared secret does not match.
- The port is not configured for 802.1X, or is in the wrong mode for a device that authenticates.
The first four are the certificate checks from chapter 1, seen from the other end. This is why automatic renewal from chapter 2 matters: it removes the two most common of them.
Where it sits in Trustlix
The authentication server runs on the camera, alongside the CA that issues the certificates it checks.
- The server answers RADIUS on udp/1812, so switches have to reach that port. Authentication server
- Server certificate and client CA trust are set separately: one proves the server, the other decides who may connect. Authentication server
- Switches are registered by IP address with a shared secret, and at least one is required. Authentication server
- VLAN policy maps one issuing CA to one VLAN ID. VLAN and MACsec
- Deployment pushes client certificates, trusted CAs and the identity to a whole fleet at once. Fleet deployment
- Authentication accepted and rejected are camera events, and the dashboard shows live sessions. Events and logs