Whether you are deploying, evaluating, testing, and/or developing a web-based application; experimenting with Apache configuration; learning about web-based security technologies; or any of many other possible scenarios, you may find yourself needing to secure a web site with a TLS certificate (commonly referred to as an SSL certificate). Securing a web server with TLS is a multi-step process. The general procedure is:
- The system administrator uses locally-installed TLS software (like OpenSSL) to generate a private key and a Certificate Signing Request (CSR) for a particular site e.g., onezeroone.dev.
- The CSR is submitted to a trusted TLS Certificate Provider, e.g. Verisign, Thawte, Comodo, etc.
- For a fee, the trusted provider uses the CSR to generate a TLS certificate for return to the systems administrator. There are a variety of certificate types with increasing complexity and cost.
- The system administrator copies the TLS certificate to the server, and configures the web server daemon to use TLS for one or more resources.
The trusted TLS Certificate Provider is an important part of the puzzle in a production environment, and especially on a publicly-accessible web server. When a visitor requests an https resource on a site, their browser negotiates a session by (a) obtaining identity information from the site (the TLS certificate), and (b) verifying the authenticity of the site with the [indicated] trusted provider. If the provider does not have a record of the certificate, a secure session can not be established.
In a private, controlled environment such as a testing or development server, you may wish to employ TLS to develop and test in an https environment. However, for any number of reasons (budget, time, complexity, etc.) it may not be feasible to purchase a trusted provider TLS certificate for each additional host. In this case, you may act as your own “
trusted TLS certificate provider”, using your CSR to generate your own self-signed certificate. This authenticity of this kind of certificate can not be validated by the browser, but may be acceptable if the development environment is otherwise adequately secured. Self-signed certificates are usually not appropriate for public-facing resources.
|Operating System||CentOS/RedHat Linux|
|Prerequisite Services||Apache HTTPD|
# yum install openssl mod_ssl
Generate a Key and CSR
/usr/bin/openssl req -sha256 -nodes -newkey rsa:2048 -keyout /etc/pki/tls/private/server.key -out /etc/pki/tls/private/server.csr -subj "/C=<country>/ST=<state>/L=<city>/O=<organization>/OU=<division>/CN=<server common name>"
# openssl req -nodes -newkey rsa:2048 -keyout /etc/pki/tls/private/onezeroone_dev.key -out /etc/pki/tls/private/onezeroone_dev.csr -subj "/C=US/ST=Florida/L=Springfield/O=One Zero One/OU=WWW/CN=onezeroone.dev"
Generate a Self-Signed TLS Cert
A self-signed certificate will allow the use of https, but does not permit third-party verification, so while communication between a client and server using a self-signed certificate is encrypted, there is no method to ensure that the TLS host is your intended destination.
/usr/bin/openssl x509 -req -days 999 -in /etc/pki/tls/private/server.csr -signkey /etc/pki/tls/private/server.key -out /etc/pki/tls/certs/server.cer
# openssl x509 -req -days 999 -in /etc/pki/tls/private/onezeroone_dev.csr -signkey /etc/pki/tls/private/onezeroone_dev.key -out /etc/pki/tls/certs/onezeroone_dev.cer
Per Apache’s recommendations, HTTPD can be configured as follows to accept only strong encryption:
SSLEngine On SSLProtocol all -SSLv2 -SSLv3 SSLHonorCipherOrder on SSLCipherSuite HIGH:!aNULL:!MD5 SSLCertificateFile /etc/pki/tls/certs/server.cer SSLCertificateKeyFile /etc/pki/tls/private/server.key SSLCertificateChainFile /etc/pki/tls/certs/server.cer
SSLEngine On SSLProtocol all -SSLv2 -SSLv3 SSLHonorCipherOrder on SSLCipherSuite HIGH:!aNULL:!MD5 SSLCertificateFile /etc/pki/tls/certs/onezeroone_dev.cer SSLCertificateKeyFile /etc/pki/tls/private/onezeroone_dev.key SSLCertificateChainFile /etc/pki/tls/certs/onezeroone_dev.cer