Embedded web servers have been used as a device management solution for eons. Now as web browser vendors start flagging non SSL/TLS enabled web servers as insecure, more and more device manufacturers are moving to HTTPS. If you are not yet using TLS for your embedded web server solution, you should know that browser vendors are gradually making it more and more difficult to use plain old HTTP.
In this article, we will look into the challenges with providing secure trusted communication and how to provide a super easy to use and hassle free solution.
The challenges:
If your product is already using a TLS enabled web server, you must have realized the challenges in configuring a certificate solution that does not throw a red flag in the browser. If you are not using TLS today, you will be up for a few surprises when TLS enabling your embedded web server solution. Many think about TLS as a solution for encrypting the communication between the web browser and the web server. Although this is correct, another very important part of TLS is to provide trust. In fact, the encryption part of TLS completely falls apart if the browser is unable to trust the server. It is for this reason web browsers throw a big red flag when a web server returns a non trusted SSL certificate to the web browser. The following figure shows a typical warning displayed in the web browser when the web server returns a non trusted certificate to the web browser.
TLS completely falls apart if the browser is unable to trust the server!
For a web browser to trust a TLS enabled web server, the following criteria must be met:
- The server's SSL certificate must have been signed by a Certificate Authority (CA) trusted by the browser (*).
- The domain name or IP address in the browser's URL bar must match the name in the web server's signed X.509 certificate. For example, when navigating to https://device.company.com, the browser checks that the domain name (URL) matches the name stored in the certificate received from the server.
- The server's SSL certificate must be valid and not expired.
(*) The client computers, including PCs, tablets, phones, must have the Certificate Authority (CA) certificate stored in the Certificate Store. A web server is simply not trusted if the CA that signed the server's certificate is not pre-installed in the Certificate Store. To better understand the Certificate Store, view the pre-installed CA certificates on your computer; for example, on Windows run the command certmgr.msc to open the Certificate Store.
You are probably at this point getting the picture that this is not so easy to manage for embedded devices. Maybe you already sell a TLS enabled product and simply push this problem to your end customer(s); however, it is virtually impossible for non technical users to get this working. As we mentioned above, using a non trusted HTTPS connection is no more secure than using a non secure HTTP connection. The reason for this is that the browser cannot distinguish between a man in the middle and the real device if the web browser is unable to trust the embedded web server.
If your customers are super techies, they may elect to be their own Certificate Authority, however, the administrative work involved, even for SSL experts, is just enormous. In any event, your product would look much more professional if you could provide a solution that completely automates the certificate management. What you need is a solution that enables your customers to simply browse to their newly purchased devices without getting any errors in the browser.
The solution:
If you want to have happy customers and want to avoid the support hassle with explaining the certificate process for your customers, check out our SharkTrust service, which completely automates the certificate management process for devices. The SharkTrust service completely automates the process of dealing with Public Key Infrastructure (PKI), thus making it super easy for the end customer to use a secure connection.