These days, it is common to see news stories about insecure Internet of Things (IoT) practices such as private keys embedded in downloadable device firmware and readily available to attackers. Potential IoT and IIoT (Industrial Internet of Things) customers are rightly concerned about security, but it doesn’t have to be that way!
With a custom, ACME-enabled issuing CA (also known as a subordinate CA or SubCA) from SSL.com, IoT and IIoT vendors can easily manage and automate validation, installation, renewal, and revocation of SSL/TLS certificates on ACME-capable devices. With ACME, private keys will be securely generated and stored on the device itself, eliminating any need for insecure key handling practices.
What is ACME and how can it work with the IoT?
Automated Certificate Management Environment (ACME) is a standard protocol for automated domain validation and installation of X.509 certificates, documented in IETF RFC 8555. As a well-documented standard with many open-source client implementations, ACME offers IoT vendors a painless way to automatically provision devices such as modems and routers with publicly- or privately-trusted end-entity certificates and keep these certificates updated over time.
SSL.com now offers our enterprise customers the ability to have their devices interface directly with a dedicated, managed ACME-enabled issuing CA, offering the following benefits:
- Automatic domain validation and certificate renewal.
- Continuous SSL/TLS coverage reduces administrative headaches.
- Increases security through shorter end-entity certificate lifespans.
- Manage certificate revocation
- Established, well-documented IETF standard protocol.
- Public or private trust available.
How ACME Works
When an ACME-enabled IoT device is connected to the internet and needs to request certificate issuance or renewal, the embedded ACME client software generates a cryptographic key pair and certificate signing request (CSR) on the device. The CSR is sent to a technically-restrained issuing CA, which returns a signed certificate. The ACME client then handles certificate installation.
The CA/Browser Forum’s Baseline Requirements define a Technically Constrained CA Certificate as
A Subordinate CA certificate which uses a combination of Extended Key Usage settings and Name Constraint settings to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates.
For example, a hosted issuing CA could be technically constrained to issue end-entity SSL/TLS certificates for a restricted set of domain names owned by the IoT vendor for use on its wireless routers. The router would then request a signed certificate associating a domain name like config.company.com to the router’s IP address on its local network. The certificate allows users to make HTTPS connections to the router with that URL rather than having to enter an IP address (e.g. 192.168.1.1). Most important for security, a unique private key is securely generated and stored on each device and can be replaced at any time.
