SharkTrust is a service that completely eliminates the hassle of dealing with Public Key Infrastructure for embedded web servers deployed in private networks. If you have a product or are planning to design a product with an integrated secure web server, SharkTrust can help you eliminate the otherwise huge support burden put on your organization when it comes to managing the required public key infrastructure.
The SharkTrust service includes a component that must be integrated into your device software solution. This component works with any SSL enabled embedded web server product and is super easy for a computer programmer to integrate. In this presentation, we will use a component designed for the Barracuda App Server running on a Windows computer. Having the browser and server on the same computer, during this presentation, simplifies the understanding of the service.
We navigate to the IP address 127.0.0.1 where a web server is running on the same computer as the browser. To switch to a secure connection, we enter HTTPS in front of the IP address. As you can see, the browser does not trust the default SSL certificate that the server presents to the browser.
As soon as we start the web server example in the presentation, the SharkTrust client integrated into the embedded web server solution, starts communicating with the online SharkTrust service. Since this is a new device connecting to the online SharkTrust service for the first time, the online service sends an email to the zone administrator asking for permission to accept the new device.
The SharkTrust service groups a set of devices into a group called a zone. Each zone registered with the SharkTrust service is a domain name and each domain name may be used by multiple end customers. Larger customers typically operate their own zone. Each zone has a zone administrator and the administrator is in charge of managing the devices belonging to the zone.
A user navigating to the zone's domain name navigates to the online SharkTrust service. In our example, any person may navigate to the domain name defibrillator.tk to get a list of local devices. The person must be within the same network as the devices. Only devices on the same network are listed.
All devices running on the local network are assigned a zone subdomain name. In our example, the local device web server is named "RTL dev". When we navigate to the local web server using the given secure HTTPS URL, no certificate errors display in the browser. We can, in fact, show that we access the local web server by stopping the server running in the command window. Pressing the browser's refresh button shows if the server works or not.
Let's navigate from the web server running on our local computer to the online SharkTrust service by removing the sub-domain name. The online SharkTrust service's login button is available to the zone administrator. In this example, we use the fictitious user "joe-admin" for our demo zone "defibrillator.tk". The zone administrator may change the name of any of the zone's registered devices. In our example, we change the initially given name from "RTL dev" to "building A". The exact details of how devices are initially named can be found in the SharkTrust protocol specification.
When clicking the updated device link in the online SharkTrust service, we navigate to the same local web server running on our local computer. As you can see in the browser's URL bar, the local web server is now named "building A.defibrillator.tk". Each device associated with a zone has its own unique sub-domain name. You can also see from the browser's URL bar that the server's certificate is trusted. The SharkTrust service's root certificate is directly trusted by all major browsers and operating systems. This means that, when using this service, any browser on any client computer will automatically trust certificates signed with the SharkTrust service’s root certificate. You may have experienced customers with a deep technical knowledge that are capable of setting up their own Public Key Infrastructure, but there is another problem with setting up a private Public Key Infrastructure -- the process of installing the Public Key Infrastructure’s root certificate in all client devices. When you create your own public key infrastructure, you initially create a root certificate and the corresponding private key. The root certificate must be installed in all client computers for them to trust any device with an SSL certificate signed by the root certificate. Most companies will probably want to use a myriad of client computers. You probably get the picture that installing the root certificate in all phones and tablets used by the company’s staff creates a management problem.