SSL/TLS Automation for the Internet of Things (IoT)

If securing the Internet of Things (IoT) was simple and straightforward, we wouldn’t be reading high-profile stories each week about routers with exposed private keys and breached home security cameras. With news like this, it’s no wonder that many consumers are still suspicious of internet-connected devices. The number of IoT devices is expected to reach over 38 billion in 2020 (an almost threefold increase just since 2015), and the time has come for manufacturers and vendors to get serious about security.

SSL.com is here to help you get that done! As a publicly trusted certificate authority (CA) and member of the CA/Browser Forum, SSL.com has the deep expertise and proven technology needed to help manufacturers secure their IoT and IIoT (Industrial Internet of Things) devices with best-in-class public key infrastructure (PKI), automation, management, and monitoring.

If you need to issue and manage thousands (or even hundreds of thousands) of publicly or privately trusted X.509 certificates for your internet-connected devices, SSL.com has everything you need.

Example: Securing a Wireless Router

As a simple illustration, we’ll describe a scenario featuring a typical embedded device—a home wireless router. You probably know all about how logging into one of those can be; you type something like http://10.254.255.1 into your browser (if you can remember it), maybe click through a security warning, and then hope no one is snooping when you enter your login credentials. Thankfully, IoT manufacturers can now offer their customers a much more convenient—and more importantly, secure—experience through the tools and technology offered by SSL.com.

In our example scenario, a manufacturer wants to let its customers connect to their router’s admin interface securely via HTTPS, not HTTP. The company also wants to let customers use an easy-to-remember domain name (router.example.com), rather than the device’s default local IP address (192.168.1.1). The SSL/TLS certificate protecting the router’s internal web server must be publicly trusted, or users will face security error messages in their browsers. Yet another complication is that each publicly trusted SSL/TLS certificate has a hard-coded lifespan upon issuance (currently effectively limited by browser policies to about a year). Because of this limitation, the manufacturer must include a means for remotely replacing a device’s security certificate when necessary. Finally, the manufacturer would like to do all of these things with minimal or no inconvenience to its customers.

Working with SSL.com, the manufacturer can take the following steps to provision each router’s internal web server with a publicly trusted, domain validated (DV) SSL/TLS certificate:

1. The manufacturer creates DNS A records associating the desired domain name (router.example.com) and a wildcard (*.router.example.com) to the chosen local IP address (192.168.1.1).
2. The manufacturer demonstrates control of its base domain name (example.com) to SSL.com through an applicable domain validation (DV) method (in this case, either email contact or CNAME lookup would be appropriate).
3. Using an SSL.com-issued technically constrained issuing subordinate CA (or SubCA) (contact us for more information on how to get your own technically constrained issuing subordinate CA), the company is able to issue publicly trusted SSL/TLS certificates for its validated router domain name(s). For our example we will stick with router.example.com, but depending on the use case this could also be a wildcard, such as *.router.example.com. The wildcard would allow the issuance of certificates covering subdomains like www.router.example.com or mail.router.example.com.
4. During manufacture, each device is provisioned with a unique cryptographic key pair and publicly trusted DV SSL/TLS certificate protecting router.example.com.
5. When a customer first connects the device to the internet, two scenarios are possible:
   1. The included SSL/TLS certificate has not expired since manufacture. In this case the user can simply connect directly to the router’s control panel at https://router.example.com/ with a web browser, and will not experience any browser trust errors.
   2. The included SSL/TLS certificate has expired since manufacture. An expiring certificate must be replaced by a newly issued one. Depending on the capabilities of the device and the manufacturer’s preferences, the device can now either:
      1. Generate a new key pair and certificate signing request internally, then submit it to their constrained SubCA for signing. The SubCA will then return a signed SSL/TLS certificate.
      2. Issue a request for a new key pair and CSR that will be generated in an external key management system, signed by the SubCA, and delivered to the device.
6. When a new certificate is needed for the device, the user’s login credentials, an included client certificate, and/or key attestation process can be used to authenticate the device with the constrained SubCA.
7. During the device’s lifetime, its SSL/TLS certificate will be replaced before expiration, at regular intervals. In this way the user will enjoy continuous access via HTTPS for the lifetime of the device.

IoT Automation Options

SSL.com offers IoT device manufacturers multiple powerful automation and management tools for working with their custom SSL.com issuing CA:

• SSL Web Services (SWS) API: Automate every aspect of certificate issuance and lifecycle with SSL.com’s RESTful API.
• ACME Protocol: ACME is an established, standard protocol for domain validation and certificate management with many open-source client implementations.

And no matter which automation technology (or mix of technologies) is most appropriate for a given situation, manufacturers and vendors will have access to state-of-the-art tools for managing and monitoring certificate issuance, lifecycle, and revocation on their devices. Each new Iot and IIoT device presents its own unique challenges, and SSL.com is ready, willing, and able to work with manufacturers to create optimized solutions for supplying their devices with publicly or privately trusted X.509 certificates. If it connects to the internet, we can help you secure it!