Whiteboard Wednesday: When Certificate Errors are a Good Thing – Explaining iForms’ Default Configuration
The first time you visited the Admin web interface for iForms Server, you saw this warning:
Ignoring the warning leads to a prompt for credentials, and then all works perfectly from there on.
This is not an accident, and explaining the rationale behind this development decision will serve to illustrate the nature of the trade-offs inherent to security decisions.
The first incarnation of iForms could only be configured and called from the iSeries menus and commands initially. Tomcat configuration occurred via XML files, and this remained true when the first Windows versions (which was dependent upon the iSeries library, still) came out.
iForms 2.x was a complete rewrite, replacing Tomcat with jetty, fleshing out a brand new RESTful API, moving all the core components to a single server, and demoting the iForms library on the iSeries to mere client application. These changes allowed the iForms server to become truly cross-platform, and in keeping with the new consistency and improved user experience, we created a web interface that would allow for the viewing of vital stats and logs and the viewing and editing of iForms Server settings.
Since the data sources and iSeries resources that would be edited are filled with sensitive information, we knew that under no condition did we wish to present the administrative interface over unsecured HTTP. However, HTTPS had a number of problems; largely, that it requires an SSL certificate to be present and correctly implemented by the application. Only a small fraction of our iForms customers even have their own SSL certificates, and making the acquisition and implementation of an SSL certificate a prerequisite to using our product seemed likely to slow and disrupt the demo process. So we had the iForms installer create and install it’s own certificate; this is known as “self-signing.”
One of the primary uses of SSL certificates is identify verification. It’s all well and good that your bank’s website asserts that it is actually run by your bank; it’s much more reassuring when a trusted third party (such as VeriSign, in this example) seconds the claim, vouching for the veracity of the website’s claimed identity.
A self-signed certificate is next to worthless when accessing your bank’s website; anyone can assert that they are your bank. This is why modern browsers will prevent direct access to sites with self-signed certificates, asking you to verify that, yes, you actually wish to go there against the advice of the browser developers. For sites on the Internet, this is good advice.
But for the administrative screen of a business application, it’s much less of a concern. The installer came from us, a trusted third party, and our automatically generated certificate could always be replaced with the customer’s own afterward. The self-signed certificate was a convenience for our users that outweighed the ongoing inconvenience of having to click through the browser’s warning message. And, importantly, should our customers get sick of the latter inconvenience, they are empowered to remedy it.
That’s all for this week. Coming soon … I’ll be talking about our security recommendations for mounting NFS shares from a Windows server onto the iSeries IFS.
A short addendum has been added to this post.