Installing Apache with PHP5 and SSL support on Debian 7.5

The web server component of our development server has multiple purposes in our environment and is used for

  • the development of client solutions;
  • the development of software products;
  • the hosting of version control software, namely Subversion and Mercurial; and
  • the hosting of project management software, including time and issue tracking, namely Redmine.

Installing Apache

We install the required packages by executing the following command in a “root” shell.

apt-get install apache2 apache2-doc

Installing PHP

To enable the processing of PHP scripts, we install PHP and the PHP Apache Module by executing the following command in a “root” shell.

apt-get install php5 libapache2-mod-php5 php-doc

Installing PHP Modules

To enable the use of some additional functionality in PHP, we install the PHP modules by executing the following command in a “root” shell.

Retrieving files

To enable the retrieval of files, we install the php5-curl package by executing the following command in a “root” shell.

apt-get install php5-curl

Handling graphics

To enable the handling of graphics, we install the php5-gd package by executing the following command in a “root” shell.

apt-get install php5-gd

The module supports the PNG, JPEG, XPM formats as well as Freetype/Truetype fonts.

Finding a Location

To enable the determination of the geographical location of an IP address, we install the php5-geoip package by executing the following command in a “root” shell.

apt-get install php5-geoip

Internationalisation

To enable internationalisation in PHP scripts, we install the php5-intl package by executing the following command in a “root” shell.

apt-get install php5-intl

Encryption

To enable encryption in PHP scripts, we install the php5-mcrypt package by executing the following command in a “root” shell.

apt-get install php5-mcrypt

Memcached

To enable memcached functionality in PHP scripts, we install the php5-memcache package by executing the following command in a “root” shell.

apt-get install php5-memcache

MySQL

To enable MySQL functionality in PHP scripts, we install the php5-mysql package by executing the following command in a “root” shell.

apt-get install php5-mysql

PostScript

To enable PostScript functionality in PHP scripts, we install the php5-ps package by executing the following command in a “root” shell.

apt-get install php5-ps

XML-RPC

To enable XML-RPC functionality in PHP scripts, we install the php5-xmlrpc package by executing the following command in a “root” shell.

apt-get install php5-xmlrpc

XSL parser

To enable the XSL parser functionality in PHP scripts, we install the php5-xsl package by executing the following command in a “root” shell.

apt-get install php5-xsl

PHP Extension and Application Repository

To enable the PHP Extension and Application Repository (PEAR), we install the php-pear package by executing the following command in a “root” shell.

apt-get install php-pear php5-dev
MongoDB

To add the MongoDB extension to the repository, we install the mongo extension by executing the following command in a “root” shell.

pecl install mongo

Once the extension has been compiled and installed, we need to register the extension by executing the following command in a “root” shell.

echo 'extension=mongo.so' > /etc/php5/conf.d/mongo.ini

Enabling SSL support

To enable SSL support for our web server, we execute the following command in a “root” shell.

a2enmod ssl

Once all configuration has been done, we need to restart the web server by executing the following command in a “root” shell.

service apache2 restart

Creating a Client Certificate in OpenSSL

The process to create a client certificate includes the following

  • Generating a certificate request
  • Signing the certificate request
  • Installing the signed certificate

Generating a certificate request

To create a certificate request, we execute the following command in a “root” shell.

/usr/lib/ssl/misc/CA.pl -newreq

During the creation of the certificate request, we are prompted for the following information

  • PEM pass phrase;
  • Country;
  • State;
  • City;
  • Organizational Name;
  • Organizational Unit Name;
  • Common Name; and
  • Email Address.

For the Common Name, we will supply the host name or the domain name that the certificate will certify. The above command will generate the following files

  • newkey.pem, which is the private key; and
  • newreq.pem, which is the request for signing.

Signing a certificate request

To sign a certificate request, we execute the following command in a “root” shell.

/usr/lib/ssl/misc/CA.pl -sign

During the signing of the certificate request, we are prompted for the following information

  • PEM pass phrase for the Certificate Authority key
  • Sign the certificate
  • Commit the certificate

The above command will generate a signed certificate in the newcert.pem file.

Removing the password on the private key

When using the client certificate, we will be prompted to supply the password on the private key. Inside an automated environment, this will cause applications to fail during start-up and be unavailable for use. We can however remove the password on the private key.

To remove the password on the private key, we execute the following command in a “root” shell.

openssl rsa -in newkey.pem -out newkey.pem.nopass

The above command will generate a separate private key file without the password associated on it.

Managing certificates

Once we’ve created the certificate, we perform the following operations on the files

  • Rename newreq.pem to hostname.req;
  • Move hostname.req to /etc/ssl/CA/requests;
  • Rename newkey.pem to hostname.key;
  • Move hostname.key to /etc/ssl/CA/private;
  • Rename newkey.pem.nopass to hostname.key.nopass;
  • Move hostname.key.nopass to /etc/ssl/CA/private;
  • Rename newcert.pem to hostname.cert; and
  • Move hostname.cert to /etc/ssl/CA/certs.

Installing the Certificate Authority certificate on workstations

The certificate is distributed to the workstations by copying the cacert.pem file to the workstation.

Installing in Internet Explorer

We install the certificate by accessing the Content Tab under Internet Options and clicking on the “Certificates” button, followed by clicking the “Import” button, selecting the cacert.pem file and “Trusted Root Certification Authorities” as the Certificate Store.

Installing in Google Chrome

We install the certificate by accessing the advanced settings under Settings and clicking on the “Manage Certificates” button under the HTTPS/SSL section, followed by clicking the “Import” button, selecting the cacert.pem file and “Trusted Root Certification Authorities” as the Certificate Store.

Installing in Mozilla Firefox

We install the certificate by accessing the Encryption Tab under Options – Advanced and clicking on the “View Certificates” button, followed by clicking the “Import” button under the Authorities Tab, selecting the cacert.pem file and checking the “This certificate can identify websites” option.

Creating a Certificate Authority in OpenSSL

Why use a Certificate Authority?

When using self-signed certificates in web applications, web browsers will issue a security warning when visiting these applications. To prevent the display of these warnings, we need to install the certificate of the web application in our web browser.

If we will be using many self-signed certificates, it will be a very cumbersome process to manage the installation of each certificate in our web browser. It would therefore be much easier to setup a Certificate Authority, install its self-signed certificate in the web browser and then issue certificates signed by the Certificate Authority – that way we minimize the administration burden of installing each and every self-signed certificate.

When we issue a new certificate signed by our Certificate Authority, it is automatically trusted since we implicitly trust the Certificate Authority.

Configuring the Certificate Authority

To create a Certificate Authority area called CA, which would store all files related to the Certificate Authority, we execute the following command in a “root” shell.

mkdir -p /etc/ssl/CA

Changes to CA.pl

The CA.pl file is a script used to manage certificates related to the Certificate Authority, which is located in the /usr/lib/ssl/misc directory.

To define the default validity period of a certificate, we set a value for the variable $DAYS. The default value is set to 365 days; we set this value to 3650 days, or 10 years.

$DAYS="-days 3650";     # 10 years

To define the default validity period of the Certificate Authority certificate, we set a value for the variable $CADAYS. The default value is set to 1095 days; we set this value to 5475 days, or 15 years.

$CADAYS="-days 5475";   # 15 years

To define the location of the Certificate Authority files, we set a value for the variable $CATOP. The default value is set to ./demoCA; we set this value to /etc/ssl/CA.

$CATOP="/etc/ssl/CA";

Changes to CA.sh

The CA.sh file is a script used to manage certificates related to the Certificate Authority, which is located in the /usr/lib/ssl/misc directory.

To define the default validity period of a certificate, we set a value for the variable DAYS. The default value is set to 365 days; we set this value to 3650 days, or 10 years.

if [ -z "$DAYS" ] ; then DAYS="-days 3650" ; fi # 10 years

To define the default validity period of the Certificate Authority certificate, we set a value for the variable CADAYS. The default value is set to 1095 days; we set this value to 5475 days, or 15 years.

CADAYS="-days 5475"     # 15 years

To define the location of the Certificate Authority files, we set a value for the variable CATOP. The default value is set to ./demoCA; we set this value to /etc/ssl/CA.

if [ -z "$CATOP" ] ; then CATOP=/etc/ssl/CA ; fi

Changes to openssl.cnf

The openssl.cnf file is a configuration file containing the default configuration settings for certificates, which is located in the /etc/ssl directory.

To define the location of the Certificate Authority files, we set a value for the variable dir. The default value is set to ./demoCA; we set this value to /etc/ssl/CA.

dir             = /etc/ssl/CA           # Where everything is kept

To define the default validity period of a certificate, we set a value for the variable default_days. The default value is set to 365 days; we set this value to 3650 days, or 10 years.

default_days    = 3650                  # how long to certify for

Creating our Certificate Authority

To create a self-signed certificate for use in our Certificate Authority, we execute the following command in a “root” shell.

/usr/lib/ssl/misc/CA.pl -newca

During the creation of the certificate, we are prompted for the following information

  • PEM pass phrase;
  • Country;
  • State;
  • City;
  • Organizational Name;
  • Organizational Unit Name;
  • Common Name; and
  • Email Address.

When prompted to "Enter pass phrase for /etc/ssl/CA/private/cakey.pem:", enter the PEM pass phrase supplied earlier. For the Common Name, we should choose a meaningful name and possibly include “Certificate Authority”.

Creating a PKCS12 version of the Certificate Authority certificate

Some systems require the certificate to be in pkcs12 format. To create the Certificate Authority certificate in pkcs12 format, we execute the following command in a “root” shell.

openssl pkcs12 -export -in /etc/ssl/CA/cacert.pem -inkey /etc/ssl/CA/private/cakey.pem -out /etc/ssl/CA/cacert.p12

When prompted to "Enter pass phrase for /etc/ssl/CA/private/cakey.pem:", enter the PEM pass phrase supplied earlier.

Installing OpenSSL on Debian 7.5

The development server caters for certain functions where we may require secure communication between our server and workstations. These include

  • the hosting of database administration software, e.g. phpMyAdmin;
  • the hosting of version control software, e.g. Subversion; and
  • the hosting of project management software, including time and issue tracking, e.g. Redmine.

To enable the secure communication between our server and workstations, we make use of certificates. These can either be self-signed or issued by a Certificate Authority, with the latter being more trustworthy. In the case of a Certificate Authority, we have the option to use an existing Authority, which could have financial implications, or setup our own internal Authority. To self-sign a certificate or setup a Certificate Authority, we use OpenSSL. To install OpenSSL, we execute the following command in a “root” shell.

apt-get install openssl ssl-cert

Setting up your own development server in Debian

In this series of articles, we will be setting up a new development environment under Debian 7.5. This will include a base server operating system, GUI Desktop Environment, Network Time Server, DNS server, Mail server, Database server and Web server. We will also be hosting our own Version Control System with integration into a Project Management and Issue and Time Tracking solution. We will also require our own Certificate Authority to request and sign digital certificates to use on our internal network and web server.

Operating System and Desktop Environment

As stated above, we will be making use of Debian 7.5 for our server operating system and either log in remotely to a shell over SSH or directly via a Desktop Environment.

Our Desktop Environment will be LXDE, due to the fact that it is designed to work well with computers on the lower end of the performance spectrum – in my case, I am running my Debian server on a Pentium IV 1.7GHz with 512MB of RAM and 2 drives of 40GB and 160GB each – the latter being used as my data drive and the former to host the operating system. We’ll also be installing Gnome and KDE as well, which are both very common Desktop Environments.

Network Time

For us to be able to broadcast Coordinated Universal Time on our internal network, we will be using NTP.

DNS Server

For us to be able to host domains on our internal network, we will be using Bind.

Mail Server

For us to be able to send and receive email messages on our internal network, we will be using Exim 4 with ClamAV, SpamAssassin and Greylistd enabled.

Data storage

For us to be able to provide data storage for our applications, we will be making use of

  • Relational databases;
  • In-memory object caching; and
  • NoSQL databases.

Relational database

MySQL Server 5.5 will provide our relational database back-end and we will be administering it through a web front-end making use of phpMyAdmin.

Object-caching

Memcached will provide our object-caching back-end and we will be administering it through a web front-end making use of phpMemcachedAdmin.

NoSQL database

MongoDB will provide our NoSQL database back-end and we will be administering it through a web front-end making use of RockMongo.

Web Server

The web front-ends will be hosted on Apache 2.2, with virtual hosts configured for each specific web front-end and SSL certificates securing the communication between the web front-ends and clients.

Java Application Server

Tomcat will provide our Java Application Server functionality.

Zend Framework

Zend Framework 2 is an open source framework for developing web applications and services using PHP 5.3+. Apigility provides the functionality to implement a WebAPI on top of the Zend Framework.

Version Control System

For us to provide our own version control system, we will be using Subversion and Mercurial and also enable access to it over the HTTPS protocol.

Project Management and Issue and Time Tracking

For us to provide our project management solution, we will be using Redmine and configure access to both Subversion and Mercurial as well as enable access to it over the HTTPS protocol.


The articles will be published in the order below and as these become available, I will update the list with the appropriate links.

At the end of this series, we will have a comprehensive development server for internal use. A note on this, we are setting up the server behind an existing firewall making use of the 192.168.100.x range of IP addresses.