SSL Certificates

The organisation operates a Certificate Authority Service (CA) for creating SSL certificates traceable back to an internal Root Certificate. This page will explain why we have such a service and how to use it.

See this article for background info on encryption:-
Public Key Cryptography

Terms:-

• Plain Text, unencrypted information which can be read by anyone.
• Cypher Text, the encoded output of the encryption process.
• Key, the item of knowledge which is used to encrypt the plain text.

Encryption can be used for several purposes, the two most common are to secure sensitive information whilst in transit across a communications medium and to store information securely whilst in storage on a hard disk or backup tape. Two basic forms of encryption exist, symmetric and asymmetric.

In symmetric encryption, the same key is used to encode the message as is used to decode the message. This works fine as long as the key used is known at both ends. If the key is not known by both partues (usually refered to as Alice and Bob), the problem exists of how to transfer the key securely over an insecure medium ensuring that it is not intercepted by anyone whilst in transit.

In asymmetric encryption, a different key is used to encode the plain text from the key used to decode the cypher text. The most widely used form of asymmetric encryption is known as Public / Private Key encryption. Here, the recipients public, widely known key is used to encrypt the plain text prior to it being sent to the recipient. The private key which is known only by the recipient is used to decode the cypher text back to plain text. This solves the key exchange problem with symmetric encryption, if Alice wants to send an encrypted message to Bob, she just asks Bob for his public key.

Public/Private Key encryption is assumed to be secure. It is not. No form of encryption is secure against enough computer power, it just buys you time. Adding more complexity to the encryption only delays how long it takes to break the encryption key by brute force. The security of public/private key encryption comes from the fact that you can say that “The encryption used here cannot be broken using a desktop computer in 1000 years”, or rather more accurately “A desktop computer built with today's technology will not be able to break this code in 1000 years”. This is only an average of course, depending on how the brute force attack is carried out and how much luck you have, this time might be much shorter. In 10 years time, an average desktop computer will have a very different amount of computational horsepower to machines today so what is considered secure today might not be in years to come.
The strength of the encryption used for a message should reflect the duration that the message has any value.

It is possible to generate a Public / Private key pair very easily:-

[andrew@evo tmp]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/andrew/.ssh/id_rsa): example
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in example.
Your public key has been saved in example.pub.
The key fingerprint is:
a2:0b:ba:dd:62:a6:b2:6d:9e:17:14:fd:bc:68:2a:d8 andrew@evo.unix.domain.pri
[andrew@evo tmp]$ ls -l
total 12
-rw------- 1 andrew andrew 1671 2010-06-29 12:42 example
-rw-r--r-- 1 andrew andrew  405 2010-06-29 12:42 example.pub

The generated files are the private key (example) which is only readable by the owner, and the public key (example.pub) which is world readable.

[andrew@evo tmp]$ cat example
-----BEGIN RSA PRIVATE KEY-----
MIIEoAIBAAKCAQEAn2w5jZUkJtVHxiZA5aDVo8ewNqvEbhBqvKuhxGHUrY17q2Kt
CvA8Qzf7XN5WLOraUvtml0cwKG7RjmafDBK3BtxKcEpWlFEYBCeBApKPWGiwIqeM
gd1nepeocBmCtAvh5r9ZKamgO6qE2QuuoUQz+1R/75cZ8TrvZb4ckS7wmG2KiuDX
...edited...
ObP8idFnUohGWGTrQ30kv8wuMHRidQ6gIiwVAoGAZnSdnngrLvDjDjKAJFhDKaQK
Ap6s5xahck2+xgCkMj1f2mCU9A0iWMw1odd8FDBz49/YU7yQQanMwkUK3VmkE3uC
XnuM61Jame2zi/q0pdmzOxK/v3XUQx+ADclyNDx3xlw7sRJ3VPQ0fmx6vrFmyTby
7BmBlpxmuKxf4CN2RdkCgYBCVgC7sCrENsxLqtjC7Tq8OIUhl9j4QegRv9oxj/M+
SVidlWQGjr+CdyKQgcT+VQcR0VDPZ5GZz3jw831SiYmNczQ1tAAODMKg+F4EqeW/
lY6r52JttIQkqkn0QsDtEHHIBSZhjym6DXEUmHQRdzQ/26IcRx0wD9YZRlQFA7Px
2wKBgFom6Tx1jyOFeygt7vJh7QErpafrx02XARR6hGgimsL6+baiFqCRo4mDUWon
QMTwZx/+VLBVaLh0+iwWjJk/nfQNtCEYGbxTfqpx5kEYz/EKeCTBpvAZNni0+UzL
/dYAiaowLkb61ZjXNbvpOW+OGvOYsYL6GSQT1BAdK0TnQcry
-----END RSA PRIVATE KEY-----
[andrew@evo tmp]$ cat example.pub
ssh-rsa   AAAAB3Nza...edited...5RvhpsjWQoax1MNW2EpL3QqjlwhVplgli5sjK55R89J6QrMzHvLHQLYhwwgvtxa7+LQwxt9HcW+i8QgYjiBT36/66aTDD8DXuE9B+pLuhxL1CGFUto/ezGZ+Mo0J5G2v0nxt1sq6g5w== andrew@evo.unix.domain.pri

As they stand, the keys generated here can be used to automate things like ssh logins, but they have at least one serious flaw, without prior knowledge you cannot be sure that the keys originate from where they say they do. An impostor can generate a key pair himself and the person wishing to send information has no way to establish the true identity of the destination. Clearly you must know if your online bank is who they claim to be.
This problem is overcome by having your private certificate verified by someone who the sender and recipient both trust. This is the role of the Certificate Authority.

On the internet, there are several commercial issuers of ssl certificates, all of whom require money for performing what is basically a simple job, that of verifying that the request for a certificate is coming from some one who has the authority to request one. The commercial Certificate Authorities public certificates are included with web browsers by default, although community driven CA's such as cacert.org's are not yet.

For internal use, there is little point in paying for an external CA to verify an internal web or ftp site, so an internal CA exists to sign requests.

The first step in obtaining a signed certificate is to read the instructions on https://ns0.domain.pri/ca/. This will assist you to generate a Certificate Signing Request or CSR. As your private key should remain private, it cannot be sent to the CA for signing as then it would be compromised. Instead, the important information is extracted from the keys and used to create the CSR. This can be signed by the CA and sent back to the originator of the request and combined with the public key without exposing sensitive information.

Once created, the CSR should be uploaded to https://nc0.domain.pri/ca and the web page details filled in.

When a CSR has been uploaded to ns0, an email will be sent to the people specified in the web page backend. The process to sign a CSR is as follows:-

1. Log in to ns0.server.pri over ssh with the appropriate permissions to sign certificates.
2. cd to /etc/openssl/menu
3. run the menu.sh shell script. This is an interactive menu-driven script which runs openssl commands in the background. Select the “Examine [C]ert signing request file” option (C) and check the details agree with those emailed to you. CSR's are listed in reverse chronological order (ls -1rt *csr.pem). This is why the upload script will object to any other file name formats & extensions for CSR's.
4. Ensure that the request is genuine by liasing with the requestor of the certificate. It is highly likely that the details sent or the format of the CSR is wrong because it seems that most people sending in a CSR do not seem capable of reading and following the instructions on the web upload page. For those capable of following the instructions, you should verify their identity either in person or by phone. As you are saying by signing a csr that you trust that person, you should ensure you are happy with their identity. This part of the process is not sufficiently documented, there should really be a formal checklist to follow.
5. If you are satisfied with the above, select the sign a CSR option. You will need to know the the CA passphrase for this operation.
6. If this completes correctly, the system will email the signed certificate bask to the email you give. Currently I do not have an automatic way to associate the email address from the web page with the CSR. A simple key-pair text file would be an appropriate way to do this.

bash-3.00# ./menu.sh
 ns0.server.pri CA Menu:-
 ========================

 [L]ist Issued Certificates
 [E]xamine Certificate
 Examine [C]ert signing request file
 [S]ign CSR
 E[m]ail Certificate
 [R]evoke CSR
 [Q]uit

 Please select an option letter:-     

Having signed a CSR, it has to be used in an application of some sort. This should really be an app support job, but you will probably get numerous questions on how to do it. Ask Google is probably the best answer, but for the human touch, some application solutions are outlined below. (or suggest https://lmgtfy.app)

The certificates generated need to be uploaded to the webserver in question, the location of them will depend on the operating system and to some extent the preference of the sys admin.

In /etc/apache2/ (Solaris) or /etc/httpd (linux and AIX), edit either the ssl section in the main httpd config file or the ssl.conf file and add the certificates:-

#   Server Certificate:
SSLCertificateFile /etc/apache2/ssl.crt/ns0-cert.pem

#   Server Private Key:
SSLCertificateKeyFile /etc/apache2/ssl.crt/ns0-key.pem

Note that if you have specified a password on the certificate, you will need to enter this manually on httpd server startup. Until this is entered, the ssl server will be unavailable.

Point and click a few icons at random. It might work, but probably not. Just upgrade to Linux.

AIX proFTPd Installation