A Guide to Secure Internal Websites in 15 Minutes
Secure by default
It is common to not think about the security of the data stored and processed in your software system, until a disaster strikes. This can lead to significant difficulties later on, due to business interruptions, loss of customer trust, legal ramifications and challenges in securing the data. It is possible to secure your systems right from the start, for relevant attack vectors, while focusing on business goals.
The two distinct systems that need to be secured, especially if you are on the web, are (i) customer-facing and (ii) internal. The customer facing web applications are typically secured by a Web Application Firewall, which monitors and filters traffic to the application, and prevents potential attacks. While internal web applications are secured with tighter measures such as VPN, TLS certificates and/or Single Sign-On.
The easiest method to secure internal web applications is by TLS client certificates. The necessary tools are already part of the Linux distributions and popular web servers already support them. We can use OpenSSL’s x509 command to create the required certificates,
The x509 command is a multi purpose certificate utility. It can be used to display certificate information, convert certificates to various forms, sign
certificate requests like a “mini CA” or edit certificate trust settings.
Web servers, such as httpd and nginx, can be configured to request and verify client certificate on every TLS connection made to the web server. If the client fails to provide a valid certificate, the connection can simply be closed. Hence, this approach stops attackers and unauthorized users from accessing your application.
To configure client certificate verification, at least two certificates are needed, (i) a X.509 certificate for the client who initiates the connection (my.p12), and (ii) X.509 certificate for the trusted certificate authority (my.ca) who signs the client certificate. The following commands should work on any modern Linux distribution,
openssl req -x509 -newkey rsa:2048 -keyout tmp.key -out my.ca
openssl req -new -newkey rsa:2048 -keyout my.key -out tmp.csr
echo -e "[usr]\n
authorityKeyIdentifier=keyid,issuer\n" > tmp.cnf
openssl x509 -req -in tmp.csr -out my.cert -CAkey tmp.key -CA my.ca -set_serial 1 -extfile tmp.cnf -extensions usr
openssl pkcs12 -export -out my.p12 -inkey my.key -in my.cert
rm -i tmp.key tmp.csr tmp.cnf my.key my.cert
After running the above commands, you will have exactly two files, namely my.ca and my.p12.
Web Server Configuration
It is quite simple to configure web servers to enforce client certificate verification. The configuration for Apache httpd and nginx are as follows,
Apache HTTP Server (httpd)
Engine X (nginx)
Import Client Certificate
With the web server configured, the client certificate can be imported into the browser to access the web application.
On most devices, Android / iOS / Windows / Mac, simply opening the my.p12 file is sufficient to import the certificate.
On Linux, Firefox / Opera browser, Search for “certificates” in the browser settings or preferences, and you will likely find “Manage Certificates” or “View Certificates”. On opening it, click the Import button under “Your Certificates” or “Personal Certificates” tab and choose the client certificate, my.p12.
Now, every time you open the web application, the client certificate will be automatically used in the verification process. This is a quick way to secure internal web applications. However, if you want an easier way to manage client certificates within your organization, do check out our product.
0th Root Secure Network — 0SNet provides a certificate manager for seamless management of TLS certificates, a user manager for authentication and a role based access controls system for authorization.