SSL security at different levels

Sometimes a server might have a requirement to receive requests over a secure line. Installing SSL certificates on your server will help you achieve the same. Where you install this certificate on the other hand might affect how your application behaves. Java for example allows you to detect if a line is secure by exposing the isSecure() method in the HTTPServletRequest interface.

So, we had a requirement where users had to submit documents over a secure line. In order to ensure requests were secure, a piece of code checked the same using the isSecure() method. A web server might well have the capability to block insecure requests to a given URL. But the code was written anyway as a backup to check for the line's security.

The code worked well in the DEV and Local environements where the SSL certificate was installed on the application server. When the code went into the QA environment - KABOOM. Every request was declared insecure and thrown out. A little investigation revealed that the certificate in QA was installed on an IIS web server, behind which was our application server. The same configuration was available in the live environment. Testing in the Local and DEV environments was performed with the certificate installed on the application server. A web server was available only in QA, which was one of the reasons this problem slipped past us. Since the line between the web server and the app server is not secure (but the line between the user and the web server is secure ), the isSecure() method returned false all the time.

Secure lines in QA:


Configuration in DEV and Local:


It pays to know your environment well before you design / write code. Code usually fails when we fail to take into account details that would not normally be considered while testing. Configuration settings, Application server patches, batch jobs, scheduled tasks etc are to name a few.