TLS, PKI, and certificates

Check certificate identity, trust, expiry and renewal as part of the connection setup. Include certificate failures and recovery in the operating plan.

Overview#

Transport Layer Security (TLS) can provide confidentiality, integrity, and endpoint authentication for a connection. It doesn't decide whether the authenticated peer may view a camera, issue a door command, change configuration, or access another tenant.

Baseline#

• Follow the current BCP 195 / RFC 9325 and its updates rather than freezing cipher advice in application code. It prohibits SSLv2/v3 and TLS 1.0/1.1 and promotes TLS 1.3; exact compatibility policy must account for the deployed product set.
• TLS 1.3 is defined by RFC 8446. Don't enable early data (0 RTT) for state changing operations unless the application specification explicitly makes replay safe.
• X.509 path validation is defined by RFC 5280. A successful cryptographic handshake is insufficient if hostname/service identity, validity, usage, constraints, revocation policy, and trust anchor aren't validated.

Server and mutual authentication#

With server authenticated TLS, the client authenticates the service; the server usually authenticates the client at the application layer. Mutual TLS (mTLS) also presents a client certificate and can strongly identify a device or workload, but still needs mapping to an account/tenant/role and certificate lifecycle.

Keep these identities separate:

• DNS/service name in the certificate;
• product device ID/serial;
• application client or workload;
• human operator;
• tenant/site;
• authorisation role.

Private PKI lifecycle#

Plan the whole lifecycle before enabling certificate only access:

key generation -> enrollment -> approval -> issuance -> distribution
-> validation -> inventory -> renewal/rotation -> revocation/distrust -> retirement

Prefer keys generated and retained in hardware backed storage where available. Use separate issuing CAs/policies for device, workload, and user certificates. Keep offline/restricted root material and test recovery from an expired or lost intermediate. Don't ship the same private key or default certificate across devices.

Embedded and appliance pitfalls#

• self signed certificates silently accepted or “trust on first use” without an authenticated ceremony;
• hostname validation disabled because devices use IP addresses;
• no usable enrolment/renewal interface;
• clock not yet valid, causing certificate failures during bootstrap;
• hard coded trust stores that can't be updated;
• weak legacy protocols retained for compatibility;
• management UI protected while RTSP, events, or SDK traffic remains cleartext;
• certificate replacement resetting on firmware upgrade or factory reset;
• client certificates mapped to a shared administrator role.

If a legacy device can't meet policy, place a managed TLS gateway close to it and constrain the cleartext segment physically and logically. Document that this is compensating containment, not end to end protection.

Validation checklist#

• correct peer identity and full chain, including name and intended usage;
• rejection of unknown CA, wrong name, expired/not yet valid, revoked/distrusted, and malformed certificates according to policy;
• no downgrade to cleartext or obsolete versions;
• certificate/CA rotation without unsafe outage;
• distinct client identities and least privilege mapping;
• protected private keys, sanitised TLS logs, and observable expiry;
• session resumption and load balancer behaviour understood;
• trust store and time source recovery documented.

Don't paste private keys or live certificate bundles into this knowledge base.

Section overview · Wiki home