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.

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.