SSL Certificates HOWTO

Franck Martin

Revision History
Revision v0.52002-10-20Revised by: FM
Adding IPsec information from Nate Carlson, / Adding IMAPS and POPS information from Bill Shirley, / Adding WinCrypt information from Colin McKinnon,
Revision v0.42002-06-22Revised by: FM
Various corrections - adding ASCII Art
Revision v0.32002-05-09Revised by: FM
Adding x509v3 extension information - Correcting spelling
Revision v0.22001-12-06Revised by: FM
Adding openssl.cnf file / Adding CRL info from Averroes, / Correcting spelling
Revision v0.12001-11-18Revised by: FM
Creation of the HOWTO

Table of Contents
1. Generalities
1.1. Introduction
1.2. What is SSL and what are Certificates?
1.3. What about S/Mime or other protocols?
2. Certificate Management
2.1. Installation
2.2. Create a Root Certification Authority Certificate.
2.3. Create a non root Certification Authority Certificate.
2.4. Install the CA root certificate as a Trusted Root Certificate
2.5. Certificate management
3. Using Certificates in Applications
3.1. Securing Internet Protocols.
3.2. Securing E-mails.
3.3. Securing Files
3.4. Securing Code
3.5. IPSec
4. Global PKI
4.1. Current PKIs
4.2. The need for a Global PKI

Chapter 1. Generalities

1.1. Introduction

Dear reader, like myself, you have intensively read the man pages of the applications of the OpenSSL project, and like myself, you couldn't figure out where to start, and how to work securely with certificates. Here is the answer to most of your questions.

This HOWTO will also deal with non-linux applications: there is no use to issue certificates if you can't use them... All applications won't be listed here, but please, send me additional paragraphs and corrections. I can be reached at the following

This HOWTO is published on The Linux Documentation Project this is where you will find the lastest version of this document.

1.1.1. Disclaimer and Licence

This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

In short, if the advises given here break the security of your e-commerce application, then tough luck- it's never our fault. Sorry.

Copyright (c) 2001 by Franck Martin and others from the openssl-users mailing list under GFDL (the GNU Free Documentation License).

Please freely copy and distribute (sell or give away) this document in any format. It's requested that corrections and/or comments be forwarded to the document maintainer. You may create a derivative work and distribute it provided that you:

  1. Send your derivative work (in the most suitable format such as sgml) to the LDP (Linux Documentation Project) or the like for posting on the Internet. If not the LDP, then let the LDP know where it is available.

  2. License the derivative work with this same license or use GPL. Include a copyright notice and at least a pointer to the license used.

  3. Give due credit to previous authors and major contributors. If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer.

It is also requested that if you publish this HOWTO in hardcopy that you send the authors some samples for 'review purposes' :-). You may also want to send something to cook my noodles ;-)

1.2. What is SSL and what are Certificates?

The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works.

  1. A browser requests a secure page (usually https://).

  2. The web server sends its public key with its certificate.

  3. The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.

  4. The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.

  5. The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data.

  6. The web server sends back the requested html document and http data encrypted with the symmetric key.

  7. The browser decrypts the http data and html document using the symmetric key and displays the information.

Several concepts have to be understood here.

1.2.2. The Certificate:

How do you know that you are dealing with the right person or rather the right web site. Well, someone has taken great length (if they are serious) to ensure that the web site owners are who they claim to be. This someone, you have to implicitly trust: you have his/her certificate loaded in your browser (a root Certificate). A certificate, contains information about the owner of the certificate, like e-mail address, owner's name, certificate usage, duration of validity, resource location or Distinguished Name (DN) which includes the Common Name (CN) (web site address or e-mail address depending of the usage) and the certificate ID of the person who certifies (signs) this information. It contains also the public key and finally a hash to ensure that the certificate has not been tampered with. As you made the choice to trust the person who signs this certificate, therefore you also trust this certificate. This is a certificate trust tree or certificate path. Usually your browser or application has already loaded the root certificate of well known Certification Authorities (CA) or root CA Certificates. The CA maintains a list of all signed certificates as well as a list of revoked certificates. A certificate is insecure until it is signed, as only a signed certificate cannot be modified. You can sign a certificate using itself, it is called a self signed certificate. All root CA certificates are self signed.

        Version: 3 (0x2) 
        Serial Number: 1 (0x1) 
        Signature Algorithm: md5WithRSAEncryption 
        Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/ 
            Not Before: Nov 20 05:47:44 2001 GMT 
            Not After : Nov 20 05:47:44 2002 GMT 
        Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, 
        Subject Public Key Info: 
            Public Key Algorithm: rsaEncryption  
            RSA Public Key: (1024 bit) 
                Modulus (1024 bit): 
                Exponent: 65537 (0x10001) 
         X509v3 extensions: 
             X509v3 Basic Constraints: 
             Netscape Comment: 
                 OpenSSL Generated Certificate
             X509v3 Subject Key Identifier:
             X509v3 Authority Key Identifier:
                 DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/ 
    Signature Algorithm: md5WithRSAEncryption

As You may have noticed, the certificate contains the reference to the issuer, the public key of the owner of this certificate, the dates of validity of this certificate and the signature of the certificate to ensure this certificate hasen't been tampered with. The certificate does not contain the private key as it should never be transmitted in any form whatsoever. This certificate has all the elements to send an encrypted message to the owner (using the public key) or to verify a message signed by the author of this certificate.

Chapter 2. Certificate Management

2.1. Installation

Nowadays, you do not have to worry too much about installing OpenSSL: most distributions use package management applications. Refer to your distribution documentation, or read the README and INSTALL file inside the OpenSSL tarball. I want also to avoid to make this HOWTO, an installation HOWTO rather than an HOWTO use certificates.

I describe here some standard installation options which are necessary to know for the samples following. Your installation may differ.

The directory for all OpenSSL certificates is /var/ssl/. All commands and paths in this document are issued from this directory, it is not mandatory but it will help the examples.

OpenSSL by default looks for a configuration file in /usr/lib/ssl/openssl.cnf so always add -config /etc/openssl.cnf to the commands openssl ca or openssl req for instance. I use /etc/openssl.cnf so all my configuration files are all in /etc.

Utilities and other libraries are located in /usr/lib/ssl.

2.1.2. The openssl.cnf file

/etc/openssl.cnf must be configured accordingly to minimize input entry.

# OpenSSL example configuration file. 
# This is mostly being used for generation of certificate requests. 
oid_file  = $ENV::HOME/.oid 
oid_section  = new_oids
# To use this configuration file with the "-extfile" option of the 
# "openssl x509" utility, name here the section containing the 
# X.509v3 extensions to use: 
# extensions  = 
# (Alternatively, use a configuration file that has only 
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# We can add new OIDs in here for use by 'ca' and 'req'. 
# Add a simple OID like this: 
# testoid1= 
# Or use config file substitution like this: 
# testoid2=${testoid1}.5.6
[ ca ] 
default_ca = CA_default  # The default ca section
[ CA_default ]
dir             = /var/ssl                # Where everything is kept 
certs           = $dir/certs              # Where the issued certs are kept 
crl_dir         = $dir/crl                # Where the issued crl are kept 
database        = $dir/index.txt          # database index file. 
new_certs_dir   = $dir/newcerts           # default place for new certs.
certificate     = $dir/cacert.pem         # The CA certificate 
serial          = $dir/serial             # The current serial number 
crl             = $dir/crl.pem            # The current CRL 
private_key     = $dir/private/cakey.pem  # The private key 
RANDFILE        = $dir/private/.rand      # private random number file
x509_extensions = usr_cert                # The extentions to add to the cert
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs 
# so this is commented out by default to leave a V1 CRL.
# crl_extensions = crl_ext
default_days    = 365                     # how long to certify for 
default_crl_days= 7                       # how long before next CRL 
default_md      = sha1                    # which md to use. 
preserve        = no                      # keep passed DN ordering
# A few difference way of specifying how similar the request should look 
# For type CA, the listed attributes must be the same, and the optional 
# and supplied fields are just that :-) 
policy  = policy_match
# For the CA policy 
[ policy_match ] 
countryName            = match 
stateOrProvinceName    = optional 
localityName           = match 
organizationName       = match 
organizationalUnitName = optional 
commonName             = supplied 
emailAddress           = optional
# For the 'anything' policy 
# At this point in time, you must list all acceptable 'object' 
# types. 
[ policy_anything ] 
countryName            = optional 
stateOrProvinceName    = optional 
localityName           = optional 
organizationName       = optional 
organizationalUnitName = optional 
commonName             = supplied 
emailAddress           = optional
[ req ] 
default_bits       = 1024 
default_keyfile    = privkey.pem 
distinguished_name = req_distinguished_name 
attributes         = req_attributes 
default_md         = sha1
x509_extensions    = v3_ca # The extentions to add to the self signed cert
# Passwords for private keys if not present they will be prompted for 
# input_password = secret 
# output_password = secret
# This sets a mask for permitted string types. There are several options. 
# default: PrintableString, T61String, BMPString. 
# pkix : PrintableString, BMPString. 
# utf8only: only UTF8Strings. 
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). 
# MASK:XXXX a literal mask value. 
# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings 
# so use this option with caution! 
string_mask = nombstr
# req_extensions = v3_req # The extensions to add to a certificate request
[ req_distinguished_name ] 
countryName         = Country Name (2 letter code) 
countryName_default = FJ 
countryName_min     = 2 
countryName_max     = 2
stateOrProvinceName         = State or Province Name (full name) 
stateOrProvinceName_default = Fiji
localityName          = Locality Name (eg, city) 
localityName_default  = Suva
0.organizationName         = Organization Name (eg, company) 
0.organizationName_default = SOPAC
# we can do this but it is not needed normally :-) 
#1.organizationName         = Second Organization Name (eg, company) 
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName         = Organizational Unit Name (eg, section) 
organizationalUnitName_default = ITU
commonName       = Common Name (eg, YOUR name) 
commonName_max   = 64
emailAddress     = Email Address 
emailAddress_max = 40
# SET-ex3   = SET extension number 3
[ req_attributes ] 
challengePassword     = A challenge password 
challengePassword_min = 4 
challengePassword_max = 20
unstructuredName      = An optional company name
[ usr_cert ]
# These extensions are added when 'ca' signs a request.
# This goes against PKIX guidelines but some CAs do it and some software 
# requires this to avoid interpreting an end user certificate as a CA.
# Here are some examples of the usage of nsCertType. If it is omitted 
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server. 
# nsCertType   = server
# For an object signing certificate this would be used. 
# nsCertType = objsign
# For normal client use this is typical 
# nsCertType = client, email
# and for everything including object signing: 
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate. 
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox. 
nsComment  = "Certificate issued by"
# PKIX recommendations harmless if included in all certificates. 
# This stuff is for subjectAltName and issuerAltname. 
# Import the email address. 
# subjectAltName=email:copy
# Copy subject details 
# issuerAltName=issuer:copy
# This is the base URL for all others URL addresses 
# if not supplied
nsBaseUrl  =
# This is the link where to download the latest Certificate
# Revocation List (CRL)
nsCaRevocationUrl =
# This is the link where to revoke the certificate
nsRevocationUrl  = 
# This is the location where the certificate can be renewed
nsRenewalUrl  = 
# This is the link where the CA policy can be found
nsCaPolicyUrl  = 
# This is the link where we can get the issuer certificate
issuerAltName = URI:
# This is the link where to get the latest CRL
crlDistributionPoints = URI:
[ v3_ca ]
# Extensions for a typical CA
# PKIX recommendation.
# This is what PKIX recommends but some broken software chokes on critical 
# extensions. 
# basicConstraints = critical,CA:true 
# So we do this instead. 
basicConstraints = CA:true
# Key usage: this is typical for a CA certificate. However since it will 
# prevent it being used as an test self-signed certificate it is best 
# left out by default. 
# keyUsage = cRLSign, keyCertSign
# Some might want this also 
# nsCertType = sslCA, emailCA
# Include email address in subject alt name: another PKIX recommendation 
# subjectAltName=email:copy 
# Copy issuer details 
# issuerAltName=issuer:copy
# RAW DER hex encoding of an extension: beware experts only! 
# You can even override a supported extension: 
# basicConstraints= critical, RAW:30:03:01:01:FF
# This will be displayed in Netscape's comment listbox. 
nsComment  = "Certificate issued by"
# This is the base URL for all others URL addresses 
# if not supplied
nsBaseUrl  =
# This is the link where to download the latest Certificate
# Revocation List (CRL)
nsCaRevocationUrl =
# This is the link where to revoke the certificate
nsRevocationUrl  = 
# This is the location where the certificate can be renewed
nsRenewalUrl  = 
# This is the link where the CA policy can be found
nsCaPolicyUrl  = 
# This is the link where we can get the issuer certificate
issuerAltName = URI:
# This is the link where to get the latest CRL
crlDistributionPoints = URI:
[ crl_ext ]
# CRL extensions. 
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
# issuerAltName=issuer:copy 

A few comments on openssl.cnf.

2.2. Create a Root Certification Authority Certificate. -newcert 
(openssl req -config /etc/openssl.cnf -new -x509 -keyout newreq.pem \
-out newreq.pem -days 365) 

creates a self signed certificate (for Certificate Authority). The resulting file goes into newreq.pem. For the common Name (CN) use something like “ACME root Certificate”. This file needs to be split into 2 files cacert.pem and private/cakey.pem. The part -RSA PRIVATE KEY- goes into private/cakey.pem while the part -CERTIFICATE- goes into cacert.pem. Delete newreq.pem when finished.

Now ensure that the file index.txt is empty and that the file serial contains 01.

You may want to increase the number of days so that your root certificate and all the certificates signed by this root does not have to be changed when the root certificate expires. I think professional companies work over 5 years to 10 years for their root certificates.

openssl req -config /etc/openssl.cnf -new -x509 -keyout private/cakey.pem \
-out cacert.pem -days 3650

This last command is better than “ -newcert” as it will place the files in the required locations and create a root CA valid for 10 years.

Now ensure that this self signed root certificate is used only to sign other certificates. The private key is highly sensible, never compromise it, by removing the passphrase that protects it. Some people will place the private key on a floppy and will load it only when signing other certificates. If you computer gets hacked they can't physically get hold of the private key, if it is on a floppy.

Now you have a root Certification Authority. Other people need to trust your self-signed root CA Certificate, and therefore download it and register it on their browser.

You will have to type the passphrase each time you want to sign another certificate with it.

2.4. Install the CA root certificate as a Trusted Root Certificate

First strip the certificate from all its text to keep only the -CERTIFICATE- section

openssl x509 -in cacert.pem -out cacert.crt

Place this file on your web site as Your web server should have a mime entry for .crt files. Your certificate is ready to be downloaded by any browser and saved.

It is important to publish the root CA Certificate on a web site as it is unlikely that people will have it already loaded on their browser. Beware, somebody could fake your web site and fake your root CA Certificate. If you can have more than one way for users to get your certificate, it is unlikely that a hacker will be able to corrupt everything.

Microsoft proposes a windows update feature that will push approved root certificate to internet explorers out there. You can contact Microsoft to have your root certificate added in their database and maybe in their future releases.

2.5. Certificate management

2.5.1. Generate and Sign a certificate request -newreq 
(openssl req -config /etc/openssl.cnf -new -keyout newreq.pem -out newreq.pem \
-days 365) 

creates a new private key and a certificate request and place it as newreq.pem. Enter a Common Name (CN) the main usage of the certificate for instance if you want to secure the website, or enter if you want to use to secure the e-mails of -sign 
(openssl ca -config /etc/openssl.cnf -policy policy_anything -out newcert.pem \
-infiles newreq.pem) 

will sign the request using the cacert.pem and commit the certificate as newcert.pem. You will need to enter the passphrase of the cacert.pem (your CA Certificate). The file newcerts/xx.pem will be created and index.txt and serial will be updated.

You private key is in newreq.pem -PRIVATE KEY- and your certificate is in newcert.pem -CERTIFICATE-

A copy of newcert.pem is placed in newcerts/ with an adequate entry in index.txt so that a client can request this information via a web server to ensure the authenticity of the certificate.

Beware of your newreq.pem file, because it contains a certificate request, but also your private key. The -PRIVATE KEY- section is not required when you sign it. So if you request someone else to sign your certificate request, ensure that you have removed the -PRIVATE KEY- section from the file. If you sign someone else certificate request, request from this person its -CERTIFICATE REQUEST- section not its private key.

Chapter 3. Using Certificates in Applications

3.1. Securing Internet Protocols.

3.1.1. Using a certificate with mod_ssl in apache

First never use your self-signed root CA Certificate with any application and especially with apache as it requires you to remove the passphrase on your private key.

First generate and sign a certificate request with the Common Name (CN) as Remove any extra information to keep only the ---CERTIFCATE --- part.

The key needs to be made insecure, so no password is required when reading the private key. Take the newreq.pem files that contains your private key and remove the passphrase from it.

openssl rsa -in newreq.pem -out wwwkeyunsecure.pem

Because the key (PRIVATE Key) is insecure, you must know what you are doing: check file permissions, etc... If someone gets its hand on it, your site is compromised (you have been warned). Now you can use the newcert and cakeyunsecure.pem for apache.

Copy wwwkeyunsecure.pem and newcert.pem in the directory /etc/httpd/conf/ssl/ as wwwkeyunsecure.pem and wwwcert.crt respectively.

Edit /etc/httpd/conf/ssl/ssl.default-vhost.conf.

# Server Certificate: 
# Point SSLCertificateFile at a PEM encoded certificate. If 
# the certificate is encrypted, then you will be prompted for a 
# pass phrase. Note that a kill -HUP will prompt again. A test 
# certificate can be generated with `make certificate' under 
# built time. 
#SSLCertificateFile conf/ssl/ca.crt 
SSLCertificateFile wwwcert.crt
# Server Private Key: 
# If the key is not combined with the certificate, use this 
# directive to point at the key file. 
#SSLCertificateKeyFile conf/ssl/ca.key.unsecure 
SSLCertificateKeyFile wwwkeyunsecure.pem 

Stop and start httpd (/etc/rc.d/init.d/httpd stop) ensure that all processes are dead (killall httpd) and start httpd (/etc/rc.d/init.d/httpd start)

3.2. Securing E-mails.

3.2.2. To use this certificate with MS Outlook

You need to import it in Outlook as a pkcs12 file. To generate the pkcs12 file from your newcert.pem and newreq.pem: -pkcs12 "Franck Martin"
(openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -out newcert.p12 \
-name "Franck Martin")

or use this command to bundle the signing certificate with your pkcs12 file

openssl pkcs12 -export -in newcert.pem -inkey newreq.pem -certfile cacert.pem \
-out newcert.p12 -name "Franck Martin"

Beware this certificate contains your public and private key and is only secured by the passphrase. This is a file not to let into everybody's hand.

In MS Outlook go to Tools, Options and Security, Click on the import/export button select to import the newcert.p12 file, enter the export password and the Digital ID "Franck Martin" (That's my name so use your name in the above examples). And Click on Ok.

Now click on the Settings button, MS Outlook should have selected the default setting so just click on New. And finally click on Ok, except if you want to change the default settings. You are ready to send signed e-mails. When you send a signed e-mail the user at the other end will receive your public key, and will therefore be able to send you encrypted e-mails.

As you have issued this certificate from a self-signed certificate (root CA Certificate), the trust path won't be valid because the application does not know the root CA Certificate. The root CA certificate has to be downloaded and installed. Refer to the chapter "Install the CA root certificate as a Trusted Root Certificate in Internet Explorer".

You can send your message as encrypted signed messages or clear text message. The encryption is not really an encryption as the message contains everything needed to decrypt the message, but it ensures that the recipient won't read the message if he does not have an s/mime compliant reader.

Note that early version of MS-Outlook XP will search the Internet to verify the validy of the certificate. It can take several seconds before the e-mail is displayed and several minutes for MS-Outlook XP to timeout when you don't have a full time or on-demand Internet connection. The bug is that this process is exclusive, the whole machine freezes till MS-Outlook XP has finished somehow.

3.3. Securing Files

3.3.1. WinCrypt

WinCrypt uses the Microsoft crypto API to encrypt and /or sign files. It will optionnaly create a zip archive of the selected files/folders before signing. It provides a front end to the certificate store, allowing the user to browse the installed certificate store, install and delete certificates and choose the certificate to use for WinCrypt signing.

The procedure for creating a certificate is the same as for Microsoft Outlook. Indeed it uses the same certificate store, you can point WinCrypt to a certificate previously installed for Outlook and vice-versa.

It is possible to verify a WinCrypt signed file filename.sgn using:

openssl smime -verify -inform der -in filename.sgn -CAfile cacert.crt

To sign a file with openSSL in a compatible format use:

openssl smime -sign -outform der -nodetach -out filename.sgn \
-signer certificate.pem -in filename.txt

To view the structure of a signed file:

openssl asn1parse -inform der -in filename.sgn

3.5. IPSec

IPSec is a new protocol that sits on top of IP that provides ad-hoc encrypted links between 2 hosts on the Internet. The IPSec implementation is mandatory for IPv6 and can be added to IPv4. If IPSec is part of IPv6, it does not mean that it is deployed by network managers. IPSec is not simple to implement due to the difficulty of having mechanisms to exchange keys automatically between machines. DNS can help, but it is not mainstream, and well known Certificate Authorities do not yet deliver adequate certification facilities for a wide deployement in the enterprise.

3.5.1. FreeS/WAN

FreeS/WAN is a popular implementation of IPSec for GNU/Linux. At its current version (1.9.7) it needs to be patched to incorporate X.509 capability. You can find a patched version on this site. Some GNU/Linux distrubutions have applied the patch for you so check your package. The advantage of this version is that you can use openssl to create certificates to use with FreeS/WAN and DNS CERT records, but more specifically you can interact with the Microsoft Implementation of IPSec. For more information check Nate's page. FreeS/WAN gateway machine

Generate a certificate with the CN beeing the fully qualified domain name of your IPSec gateway: Do not forget to sign the certificate. You have two files newcert.pem and newreq.pem. The file newreq.pem contains the private key and some extra information therefore needs to be edited to contain only the private key. Delete everything outside the --BEGIN RSA PRIVATE KEY-- and --END RSA PRIVATE KEY--. Move the files to the appropriate locations on your gateway machine. Make sure that you do that securely. On my distribution all configuration files for FreeS/WAN are located in /etc/freeswan, it could be different in yours.

mv newreq.pem /etc/freeswan/ipsec.d/private/
mv newcert.pem /etc/freeswan/ipsec.d/

Copy also your root certificate to the FreeS/WAN configuration directory. Copy only the certificate, not the key.

mv cacert.pem /etc/freeswan/ipsec.d/cacerts

Generate a certificate revocation list or copy yours to the right location.

openssl ca -genrcl -out /etc/freeswan/ipsec.d/crls/crl.pem

Still on the gateway machine, configure the ipsec.secrets file by including the line:

: RSA “password”

The password being the one used to generate the key pair. Configure ipsec.conf as following:

config setup
conn %default
conn roadwarrior-net
conn roadwarrior

As you can see there are 2 connections beeing established, one to the gateway machine and one to the network behind the gateway machine. This is particulary useful if you are operating some kind of firewall/NAT on your gateway machine. The configuration is such that anybody with a valid certificate will be able to connect to the gateway machine. FreeS/WAN client machine

The procedure is similar, you need to generate a certificate for the client machine with the CN being the fully qualified domain name of the client machine, for instance This certificate must be signed by the same signing authorithy as the gateway certificate. This is how the link will be authorised.

As with the gateway copy the following files securely to the configuration directories:

mv newreq.pem /etc/freeswan/ipsec.d/private/
mv newcert.pem /etc/freeswan/ipsec.d/

Copy also your root certificate to the FreeS/WAN configuration directory. Copy only the certificate, not the key.

mv cacert.pem /etc/freeswan/ipsec.d/cacerts

Generate a certificate revocation list or copy yours to the right location.

openssl ca -genrcl -out /etc/freeswan/ipsec.d/crls/crl.pem

Finally you need to copy also the certificate (not the private key) of your gateway machine

mv /etc/fresswan/ipsec.d/

Similarly edit your ipsec.secrets file to load the client private key

: RSA “password”

and edit the ipsec.conf as follows to enable the connection:

config setup
conn %default
conn roadwarrior-net
left=(ip of host)
conn roadwarrior
left=(ip of host)

Now you can start the VPN link

ipsec auto --up roadwarrior
ipsec auto --up roadwarrior-net

To start the link automatically, replace in the configuration file 'auto=add' by 'auto=start' MS Windows 2000/XP client machine

The procedure is the same as for the FreeS/WAN client. Generate a certificate with a CN of, but you will have to convert this certificate into a .p12 file. Follow the procedure in the chapter “Using this certificate with MS-Outlook” but ensure that the .p12 file is bundled with the root CA certificate:

Additionally note the output of:

openssl x509 -in cacert.pem -noout -subject

Copy this file securely to the MS-Windows machine.

You know need to install Marcus Muller's ipsec.exe utility in for instance c:\ipsec directory.

Open Microsoft Management Console (MMC), in 'Add/Remove Snap-in' click on 'Add' then click on 'Certificates', then 'Add' Select 'Computer Account', and 'Next'. Select 'Local computer', and 'Finish'. Click on 'IP Security Policy Management', and 'Add'. Select 'Local Computer', and 'Finish' click 'Close' then 'OK'

Now you can add the .p12 certificate

Click the plus arrow by 'Certificates (Local Computer)' then right-click 'Personal', and click 'All Tasks' then 'Import' click 'Next'. Type the path to the .p12 file (or browse and select the file), and click 'Next'. Type the export password, and click 'Next'. Select 'Automatically select the certificate store based on the type of certificate', and click 'Next'. Click 'Finish', and say yes to any prompts that pop up. Exit the MMC, and save it as a file so you don't have to re-add the Snap In each time.

Install ipsecpol.exe (Windows 2000) or ipseccmd.exe (Windows XP) as described in the documentation for the ipsec utility. Edit your ipsec.conf (on the windows machine), replacing the "RightCA" with the output of the 'openssl x509 -in cacert.pem -noout -subject'; reformatted as below (you need to change the /'s to commas, and change the name of some of the fields -- just follow the example below):

conn roadwarrior 
rightca="C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root"
conn roadwarrior-net 
rightca="C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root" 

Start the link

Run the command 'ipsec.exe'. Here's example output:

IPSec Version 2.1.4 (c) 2001,2002 Marcus Mueller 
Getting running Config ... 
Microsoft's Windows XP identified 
Host name is: (local_hostname) 
No RAS connections found. 
LAN IP address: (local_ip_address) 
Setting up IPSec ...
Deactivating old policy... 
Removing old policy...
Connection roadwarrior: 
MyTunnel : (local_ip_address)
MyNet : (local_ip_address)/ 
PartnerTunnel: (ip_of_remote_system) 
PartnerNet : (ip_of_remote_system)/ 
CA (ID) : C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root... 
PFS : y 
Auto : start 
Auth.Mode : MD5 
Rekeying : 3600S/50000K 
Activating policy...
Connection roadwarrior-net: 
MyTunnel : (local_ip_address) 
MyNet : (local_ip_address)/ 
PartnerTunnel: (ip_of_remote_system) 
PartnerNet : (remote_subnet)/(remote_netmask) 
CA (ID) : C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root... 
PFS : y 
Auto : start 
Auth.Mode : MD5 
Rekeying : 3600S/50000K 
Activating policy...

Now, ping your gateway host. It should say 'Negotiating IP Security' a few times, and then give you ping responses. Note that this may take a few tries; from a T1 hitting a VPN server on a cable modem, it usually takes 3-4 pings. Do the same for the internal network on the remote end, and you should be up!

Chapter 4. Global PKI

4.2. The need for a Global PKI

In these days and age security on personnal computers has become important, such importance that Bill Gates stated that when Microsoft will have to choose between features and security, they will now choose security.

This reflections came from the increasing numbers of rogue people on the Internet. Anybody can send you anything, or trick you in installing anything on your computer. The solution is to identify everybody so when you have a problem you can at least blame someone. This is particulary true in the case of SPAM. It is often difficult to find the originator of an unsolicited e-mail and worse to be able to do something to stop this person. What many people have called for is tracability. If you receive some information which is not traceable through a certificate, you may decide to treat this information differently. This is the same concept as caller ID on telephone network. Certifcates offer this capaility for all applicationson the Internet, e-mails (S/MIME), Commerce transactions (HTTPS), Software install (Code Signing),... Unfortunately certificates are not widely used because they cost a lot if they have to be fully deployed. How many users on Yahoo mail, Hotmail, CA Online, can afford an e-mail certificate? There are some scheme to offer free e-mails certificates, but they can only certify that an e-mail address exists, they can trace back to a human or a body in the real world.

A global PKI is needed. All the protocols and standards exist, not need to reinvent the wheel. The IETF has all the mechanice worked out. An LDAP server can store the certificates, a DNS server can reference entry back to certificate stores, HTTP can deliver certificate to applications, S/MIME can secure e-mails,... The problem is now a policy problem or rather a profile problem: select which pieces of this standard should be used to cooperate into a global PKI. Which organisation should provide such service? What level of security/tracability will be achieved?... If one can answer these questions, it will be a step in the right direction and if users buy in, then problem solved...

I will keep updated this chapter as the work of the working group on PKI of the Internet Society progress. The Internet Society is also managing the .org Top Level Domain name, so they have a lot of capabilities at hand to solve this e-mail spamming problem.