1.1.1. Droits d'utilisation et limitation de responsabilit�

Ce document est distribu� dans l'espoir qu'il se r�v�lera utile, mais SANS AUCUNE GARANTIE� sans m�me la garantie implicite qu'il soit PROPRE � LA VENTE ou ADAPT� � UN BESOIN PARTICULIER.

En r�sum�, si les conseils qui vous sont prodigu�s ici annihilent la s�curit� de votre application de commerce �lectronique, eh bien, tant pis pour vous�— ce n'est jamais de notre faute. D�sol�.

Copyright � 2001 Franck Martin et divers membres de la liste de diffusion openssl-users. Ce document est diffus� selon les termes de la licence de documentation libre GNU (GFDL). Une version fran�aise officieuse de la version 1.1 de cette licence est disponible sur http://www.linux-france.org/prj/jargonf/general/gfdl.html.

Vous pouvez librement copier et distribuer (commercialement ou gratuitement) ce document dans n'importe quel format. Il vous est demand� de faire parvenir vos corrections et commentaires au responsable actuel de ce document. Vous pouvez cr�er des travaux d�riv�s de celui-ci et les distribuer si vous respectez les conditions suivantes�:

1. Faire parvenir vos travaux d�riv�s (dans le format le plus appropri� tel que SGML) au Projet de documentation Linux (LDP), ou � un projet du m�me type pour qu'il soit diffus� sur internet. Si vous n'envoyez pas votre document au LDP, informez le LDP de l'endroit o� votre document est disponible.

2. Diffuser vos travaux d�riv�s sous la m�me licence, ou sous la licence publique GNU (GPL). Inclure la notice pr�cisant les droits d'utilisation, et au moins un pointeur sur la licence utilis�e.

3. Reconna�tre la contribution des pr�c�dents auteurs et contributeurs principaux. Si vous envisagez de r�aliser un travail d�riv� autre qu'une traduction, il vous est demand� d'en discuter au pr�alable avec le responsable actuel de ce document.

Il vous est �galement demand� que si vous publiez ce guide pratique dans un format papier, vous envoyiez � ses auteurs quelques exemplaires � des fins d'�valuation�:-). Vous voudrez peut-�tre �galement m'envoyer quelque chose pour assaisonner mes �pinards�;-)

1.1.2. Disclaimer and Licence

La licence de ce document nous oblige � inclure une copie en anglais de ce texte. La version fran�aise de ce texte se trouve � la section pr�c�dente.

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 � 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.1.3. Pr�-requis

Comme indiqu� dans l'introduction, ce document est un aide-m�moire et vous devez donc consulter les pages de manuel du paquet OpenSSL. La lecture de documents relatifs � la s�curit� est vivement conseill�e afin de comprendre comment votre s�curit� peut �tre compromise. Les certificats sont destin�s � am�liorer la s�curit� des transactions et il donc important que vous compreniez les implications de vos actes en terme de s�curit� ainsi que les limitations d'OpenSSL.

1.2.1. Clef publique�/ clef priv�e

Le chiffrement � base de clef publique garantit qu'une donn�e chiffr�e par une clef, publique ou priv�e, ne peut �tre d�chiffr�e que par la clef associ�e. Cela peut para�tre surprenant mais croyez moi, �a fonctionne. Les clefs sont de m�me nature et leurs r�les peuvent �tre invers�s�: ce que l'une chiffre est d�chiffrable par l'autre. La paire de clef repose sur des nombres premiers et leur longueur, exprim�e en digits binaires, traduit la difficult� qu'il y a � d�chiffrer un message sans connaissance � priori de la clef n�cessaire. L'astuce consiste � conserver une clef secr�te (la clef priv�e) et � distribuer l'autre clef (la clef publique) � tout le monde. N'importe qui peut vous envoyer un message chiffr� mais personne d'autre que vous ne peut le d�chiffrer tant que vous �tes le seul � conserver un des deux membres de la paire de clefs. On peut �galement prouver qu'un message provient de vous en le chiffrant avec votre clef priv�e�: seule la clef publique correspondante le d�chiffrera. Notez que le message n'est pas prot�g� parce que vous le signez. Tout le monde a acc�s � la clef de d�chiffrement, ne l'oubliez pas.

Le probl�me consiste � obtenir la clef publique du correspondant. En g�n�ral, vous lui demanderez de la transmettre via un message sign� qui la contiendra accompagn�e d'un certificat.

Message-->[Clef publique]-->Message chiffr�-->[Clef priv�e]-->Message

1.2.2. Le certificat

Qu'est-ce qui vous garantit que vous dialoguez bien avec la bonne personne ou le bon site web�? En principe, quelqu'un aura fait l'effort (s'il est s�rieux) de v�rifier que les propri�taires du site sont bien ceux qu'ils affirment �tre. On fait naturellement confiance � ce quelqu'un�: son certificat, un certificat racine, est incorpor� � votre navigateur. Un certificat contient des informations relatives � son propri�taire comme une adresse �lectronique, un nom, l'usage pr�vu du certificat, une dur�e de validit�, un identifiant de localisation ou un nom qualifi� (DN/Distinguished Name) qui comprend le nom d'usage (CN/Common Name) et l'identifiant du signataire du certificat. Le certificat comprend �galement la clef publique et un hach� pour garantir l'int�grit� du message. Comme vous avez d�cid� de faire confiance au signataire du certificat, vous accordez du cr�dit � son contenu. On parle d'arbre de confiance de certification ou de chemin de certification. En g�n�ral, le navigateur et les applications incluent d'office le certificat racine d'autorit�s de certification bien connues. L'autorit� de certification tient � jour une liste des certificats sign�s ainsi qu'une liste des certificats r�voqu�s. Un certificat n'est pas fiable tant qu'il n'est pas sign� puisque seul un certificat sign� ne peut pas �tre modifi�. Un certificat peut se signer lui-m�me. On parle alors de certificat auto-sign�. Tous les certificats de CA racines sont ce type.

Certificate:
    Data: 
        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/Email=administrator@sopac.org
        Validity
            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, CN=www.sopac.org/Email=administrator@sopac.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption 
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a:
                    9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36:
                    b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4:
                    7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86:
                    08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd:
                    94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25:
                    da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9e:
                    42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a:
                    6c:14:e2:ae:62:e7:6b:30:e9
                Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             Netscape Comment:
                 OpenSSL Generated Certificate
             X509v3 Subject Key Identifier:
                 FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F
             X509v3 Authority Key Identifier:
                 keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6 

                 DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/Email=administrator@sopac.org
                 serial:00

    Signature Algorithm: md5WithRSAEncryption
        34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd:
        aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57:
        2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96:
        34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62:
        e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5:
        0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06:
        ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af:
        bc:5a
-----BEGIN CERTIFICATE-----
MIIDoTCCAwqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox
DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww
CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B
CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy
MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD
VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD
Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv
cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1panB
0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI
2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2
JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ
YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud
DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl
uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp
amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx
FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0
cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw
VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb
xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b
Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa
-----END CERTIFICATE-----

Comme vous avez pu le remarquer, le certificat mentionne son �metteur, contient la clef publique de son propri�taire, la p�riode de validit� du certificat et une signature pour v�rifier qu'il n'a pas �t� modifi�. Le certificat ne contient PAS la clef priv�e qui ne doit jamais �tre r�v�l�e. Ce certificat contient tous les �l�ments n�cessaires pour envoyer un message chiffr� � son propri�taire ou pour v�rifier un message dont la signature lui est attribu�e.

1.2.3. La clef sym�trique

Les algorithmes de chiffrement � paire de clefs publique/priv�e sont int�ressants mais pas toujours pratiques. Ils sont asym�triques parce que des clefs diff�rentes sont requises au chiffrement et au d�chiffrement. La m�me clef ne peut remplir les deux r�les. Les algorithmes sym�triques actuels sont nettement plus rapides que les algorithmes asym�triques. Une clef sym�trique est toutefois potentiellement peu s�re. Il suffit qu'un individu nuisible se la procure et il n'y a plus d'information prot�g�e. La clef sym�trique doit donc �tre transmise au correspondant sans �tre intercept�e. Rien n'est s�r dans l'Internet. La solution consiste � envelopper la clef sym�trique dans un message chiffr� au moyen d'un algorithme asym�trique. Comme personne d'autre que vous ne conna�t la clef priv�e, le message chiffr� avec la clef priv�e est s�r (enfin, relativement, rien n'est garanti en ce bas monde sinon la mort et les imp�ts). La clef de chiffrement sym�trique est choisie al�atoirement de telle sorte qu'une compromission accidentelle n'ait pas d'impact sur les transactions futures.

Clef sym�trique-->[Clef publique]-->Clef de session chiffr�e-->[Clef priv�e]-->Clef sym�trique

1.2.4. Les algorithmes de chiffrement

Diff�rents algorithmes existent, sym�triques ou non, avec diverses longueurs de clef. En principe les algorithmes ne peuvent pas �tre brevet�s. Si Henri Poincar� l'avait fait, il aurait pu poursuivre Albert Einstein�… Les algorithmes ne peuvent donc pas �tre brevet�s, � l'exception toutefois des �tats-Unis. OpenSSL est mis au point dans des pays o� les algorithmes ne sont pas brevet�s et o� l'usage de la cryptographie n'est pas r�serv� � des agences d'�tat pour des fins militaires ou d'espionnage. Lors de la n�gociation entre le navigateur et le serveur web, les applications fournissent l'une � l'autre une liste d'algorithmes qu'elles peuvent traiter, class�s par ordre de pr�f�rence. L'algorithme pr�f�r� en commun est choisi. OpenSSL peut �tre compil� sans inclure la gestion de certains algorithmes de fa�on � rester utilisable dans des pays o� l'usage de la cryptographie est r�glement�.

1.2.5. Le hachage

Un hachage s'obtient par application d'une fonction, dite � sens unique, � un message. La fonction pr�sente cette propri�t� qu'il n'est pas possible de former un message initial � partir du hach�. En outre, le hach� est compl�tement modifi� en cas de changement, m�me mineur, du message d'origine. Il est donc pratiquement impossible de modifier un message � hach� constant. Les fonctions de hachage s'emploient dans des m�canismes � base de mot de passe, des v�rifications d'int�grit� (MD5) et en g�n�ral pour v�rifier que des donn�es n'ont pas �t� alt�r�es. L'IETF (Internet Engineering Task Force) pr�f�re apparemment SHA1 � MD5 pour diverses raisons techniques (cf RFC2459 7.1.2 and 7.1.3).

1.2.6. La signature

La signature d'un message consiste � associer une identit� � son contenu. Le plus souvent il s'agit de prouver qui en est l'auteur mais ce n'est pas toujours le cas. Le message peut �tre textuel ou �tre le certificat de quelqu'un d'autre. Pour signer un message, son hach� est d'abord cr�� puis ce dernier est chiffr� avec la clef priv�e. Le r�sultat et votre certificat accompagnent ensuite le message d'origine. Le destinataire de l'ensemble recalcule le hach� et le compare au r�sultat du d�chiffrement de la signature avec votre clef publique suppos�e. Il v�rifie ensuite la validit� de votre certificat.

Ce type de signature permet de transmettre la clef publique et le certificat � chaque correspondant.

Il y a deux fa�ons de signer, soit en incluant le message � la signature, soit en chiffrant le message et sa signature. Cette derni�re forme n'est qu'un chiffrement tr�s pauvre car n'importe quelle application qui dispose de la clef publique peut l'inverser. La premi�re forme permet de passer un contenu textuel � l'utilisateur en toute circonstance tandis que la deuxi�me l'interdit d�s que le message a �t� alt�r�.

1.2.7. Le mot de passe

Le mot de passe correspond � un mot de passe originel Unix � ceci pr�s qu'il est normalement plus long que 8 caract�res et ne se limite pas forc�ment � un seul mot. De nos jours les syst�mes Unix utilisent des hach�s MD5 ou autres qui n'imposent plus de limitation de longueur de mot de passe.

1.2.8. L'infrastructure de clefs publiques

L'infrastructure de clefs publiques (PKI/Public Key Infrastructure) d�signe le syst�me de gestion et la base de donn�es qui permettent de signer les certificats, de tenir � jour une liste de certificats r�voquer, de distribuer les clefs publiques, etc. Il est le plus souvent accessible via un site web ou un serveur LDAP. Certaines entit�s sont �galement charg�es de v�rifier que vous �tes bien qui vous pr�tendez �tre. On peut avoir recours � une PKI commerciale connue dont le certificat racine se trouve d�j� dans votre application. Un probl�me appara�t au niveau du courrier �lectronique pour lequel vous avez le choix entre l'emploi d'un certificat g�n�rique ou une facturation d'environ 100E par an pour chaque adresse �lectronique. De plus, il n'y a aucun moyen d'obtenir la clef publique de quelqu'un sans avoir re�u auparavant de ce correspondant son certificat (accompagn� de sa clef publique).

2.1.1. L'utilitaire CA.pl

V�rifiez que CA.pl se trouve dans un r�pertoire qui figure dans le chemin d'acc�s par d�faut aux programmes. Il peut se trouver dans le r�pertoire /usr/lib/ssl. CA.pl permet de masquer la complexit� des commandes openssl. Je l'utilise dans tous les exemples en indiquant entre crochets l'�quivalent openssl.

Modifiez CA.pl de fa�on � ce que les appels � openssl ca et openssl req incluent l'option -config /etc/openssl.cnf.

#$SSLEAY_CONFIG=$ENV{"SSLEAY_CONFIG"};
$SSLEAY_CONFIG="-config /etc/openssl.cnf";
#$CATOP="./demoCA";
$CATOP="/var/ssl";

2.1.2. Le fichier openssl.cnf

/etc/openssl.cnf doit �tre configur� de fa�on � minimiser les donn�es � renseigner � chaque invocation des utilitaires.

#---Begin---
#
# Fichier de configuration pour OpenSSL.
# S'emploie surtout pour les demandes de certificats.
#
# NdT: autre chose que de l'ASCII dans les fichiers de
# configuration me rend nerveux. Il y a donc un zest de triche
# dans ce qui suit. Vous ne voudriez pas me rendre nerveux, non ? :o)
#

RANDFILE  = $ENV::HOME/.rnd
oid_file  = $ENV::HOME/.oid
oid_section  = new_oids

# Section des extension X.509v3 pour se servir du
# fichier avec l'option -extfile de la commande
# "openssl x509"
# extensions  =
# (Variante: employer un fichier de configuration qui
# n'a que des extensions X.509v3 dans sa section
# principale [= default])

[ new_oids ]

# On ajoute des OID pour les commandes 'ca' et 'req'.
# Par exemple:
# testoid1=1.2.3.4
# L'emploi de substitutions est possible:
# testoid2=${testoid1}.5.6

####################################################################
[ ca ]
default_ca = CA_default  # Section de la CA standard

####################################################################

[ CA_default ]
dir             = /var/ssl                # Emplacement de base
certs           = $dir/certs              # Emplacement de stockage des nouveaux certificats
crl_dir         = $dir/crl                # Emplacement des nouvelles CRL
database        = $dir/index.txt          # Fichier d'index
new_certs_dir   = $dir/newcerts           # Emplacement des nouveaux certificats

certificate     = $dir/cacert.pem         # Certificat de la CA
serial          = $dir/serial             # Numero de serie en cours
crl             = $dir/crl.pem            # CRL en cours
private_key     = $dir/private/cakey.pem  # Clef privee
RANDFILE        = $dir/private/.rand      # Fichier d'alea
x509_extensions = usr_cert                # Extensions pour les certificats

# Extensions pour la CRL. Remarque: Netscape communicator n'aime pas les CRL de version 2,
# on commente donc pour avoir une CRL version 1
# crl_extensions = crl_ext

default_days    = 365                     # Duree de vie d'un certificat
default_crl_days= 7                       # Intervalle entre CRLs
default_md      = sha1                    # Algorithme de hachage
preserve        = no                      # Conserve-t-on l'ordre du DN ?

# Diverses facons de specifier l'allure des requetes
# Pour une requete de type CA, les attributs doivent etre les memes
# Les champs 'optional' et 'supplied' correspondent respectivement
# a des champs optionnels et fournis :o)
policy  = policy_match

# Typage CA
[ policy_match ]
countryName            = match
stateOrProvinceName    = optional
localityName           = match
organizationName       = match
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

# Typage tout-venant
# Tous les types d'objets acceptables doivent etre enumeres
[ 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 # Extensions pour un certificat auto-signant

# Mot de passe pour les clefs privees (l'application le demande s'il est vide).
# input_password = secret
# output_password = secret

# Masque pour les types de chaines valides. Plusieurs choix sont possibles.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (pas de BMPStrings ni de UTF8Strings).
# MASK:XXXX valeur litterale.
# Attention: certaines versions de Netscape plantent sur les BMPStrings ou les UTF8Strings.
# A utiliser avec prudence!
string_mask = nombstr

# req_extensions = v3_req # Extensions pour une demande de certificat

[ req_distinguished_name ]
countryName         = Nom du pays (code sur 2 lettres)
countryName_default = FJ
countryName_min     = 2
countryName_max     = 2

stateOrProvinceName         = Etat ou province (nom complet)
stateOrProvinceName_default = Fiji

localityName          = Ville
localityName_default  = Suva

0.organizationName         = Organisation (nom de l'entreprise par exemple)
0.organizationName_default = SOPAC

# Possible mais pas normalement pas necessaire :-)
#1.organizationName         = Second nom de l'organization
#1.organizationName_default = World Wide Web SARL

organizationalUnitName         = Nom du departement dans l'organisation
organizationalUnitName_default = ITU

commonName       = Nom d'usage
commonName_max   = 64
emailAddress     = Addresse e-mail
emailAddress_max = 40

# SET-ex3   = SET extension number 3

[ req_attributes ]
challengePassword     = Un mot de passe de challenge
challengePassword_min = 4
challengePassword_max = 20

unstructuredName      = Nom optionnel

[ usr_cert ]

# Extensions ajoutees quand 'ca' signe une requete.
# Contraire aux suggestions PKIX mais des CA le font et certains
# logiciels le demandent pour ne pas confondre un certificat
# utilisateur avec un certificat de CA

basicConstraints=CA:FALSE

# Examples d'utilisation de nsCertType. En cas d'omission,
# le certificat peut servir a tout sauf a signer des objets

# Serveur SSL
# nsCertType   = server

# Certificat promis a signer des objets.
# nsCertType = objsign

# Client normal.
# nsCertType = client, email

# Tout.
# nsCertType = client, email, objsign

# Classique pour un certificat client.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# Pour la boiboite de commentaire de Netscape.
nsComment  = "Certificate issued by https://www.sopac.org/ssl/"

# Recommandations PKIX sans effets secondaires facheux.
subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid,issuer:always

# On importe l'adresse e-mail
# pour les attributs subjectAltName et issuerAltname.
# subjectAltName=email:copy

# Informations relatives au sujet.
# issuerAltName=issuer:copy

# Adresse de base des autres URL si on n'en donne pas
# au cas par cas.
nsBaseUrl  = https://www.sopac.org/ssl/

# Adresse de la CRL du moment.
nsCaRevocationUrl = https://www.sopac.org/ssl/sopac-ca.crl

# Adresse pour revoquer un certificat.
nsRevocationUrl  = https://www.sopac.org/ssl/revocation.html?

# Adresse pour renouveller un certificat.
nsRenewalUrl  = https://www.sopac.org/ssl/renewal.html?

# Adresse des pratiques de la CA.
nsCaPolicyUrl  = https://www.sopac.org/ssl/policy.html.

# Adresse du certificat du signataire.
issuerAltName = URI:https://www.sopac.org/ssl/sopac.crt.

# Adresse de la CRL du moment.
crlDistributionPoints = URI:https://www.sopac.org/ssl/sopac-ca.crl

[ v3_ca ]

# Extensions d'une CA standard

# Recommandation PKIX

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer:always

# Recommandation PKIX que certains bugware n'aiment pas
# basicConstraints = critical,CA:true
# On utilise donc plutot ceci
basicConstraints = CA:true

# Emploi de la clef: typique d'un certificat de CA.
# On le laisse inactif pour prevenir l'emploi d'un
# certificat auto-signant de test.
# keyUsage = cRLSign, keyCertSign

# En fonction des besoins.
# nsCertType = sslCA, emailCA

# On inclut l'adresse e-mail dans le nom alternatif du sujet (recommendation PKIX)
# subjectAltName=email:copy
# On copie les informations du signataire
# issuerAltName=issuer:copy

# Encodage DER en base 16 d'une extension: licence de pilotage requise!
# 1.2.3.5=RAW:02:03
# On peut surcharger une extension standard:
# basicConstraints= critical, RAW:30:03:01:01:FF

# Message pour la boite d'affichage de Netscape.
nsComment  = "Certificat en provenance de https://www.sopac.org/ssl/"

# Adresse de base des autres URL si on n'en donne pas
# au cas par cas.
nsBaseUrl  = https://www.sopac.org/ssl/

# Adresse de la CRL du moment.
nsCaRevocationUrl = https://www.sopac.org/ssl/sopac-ca.crl

# Adresse pour revoquer un certificat.
nsRevocationUrl  = https://www.sopac.org/ssl/revocation.html?

# Adresse pour renouveller un certificat.
nsRenewalUrl  = https://www.sopac.org/ssl/renewal.html?

# Adresse des pratiques de la CA.
nsCaPolicyUrl  = https://www.sopac.org/ssl/policy.html

# Adresse du certificat du signataire.
issuerAltName = URI:https://www.sopac.org/ssl/sopac.crt

# Adresse de la CRL du moment.
crlDistributionPoints = URI:https://www.sopac.org/ssl/sopac-ca.crl

[ crl_ext ]
# Extensions de CRL
# Seuls issuerAltName et authorityKeyIdentifier se justifient dans une CRL.
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always


#----End----

Quelques remarques au sujet du fichier openssl.cnf

• Plusieurs variables se pr�sentent avec les suffixes _default, _min et _max pour leurs valeurs minimales ou leurs nombres minimaux et maximaux de caract�res respectivement.

• Le fichier est bas� sur des [Sections] de variables.

2.1.3. Cr�ation de l'autorit� de certification

Utilisez la commande suivante apr�s avoir modifi� de fa�on ad�quate le fichier openssl.cnf�:

CA.pl -newca

L'utilitaire demande de choisir un fichier contenant le certificat de l'AC ou bien il propose d'en cr�er un. A titre d'exercice, laissez vous guider dans la cr�ation d'une AC. La partie suivante remplace cette AC par une AC de dur�e de vie plus importante. CA.pl ne g�n�re que des certificats valables 365 jours.

2.4.1. Netscape/Mozilla

On r�cup�re le certificat depuis le web ou le syst�me de fichiers avec Netscape. Ce dernier identifie automatiquement le fichier comme un certificat racine et propose de l'int�grer. Un assistant guide dans l'installation. A la fin du processus, on pr�cise le domaine d'application du certificat�: s�curisation web, signature de courrier �lectronique ou signature de code.

2.4.2. Galeon

Galeon fonctionne comme Mozilla en ce qu'il repose sur le m�me moteur de rendu HTML. Il n'inclut toutefois pas d'outil de gestion des certificats.

2.4.3. Opera

COMPL�TEZ-MOI

2.4.4. Internet Explorer

On commence par aller � l'adresse de t�l�chargement du certificat avant de le sauvegarder en local. L'assistant d'installation de certificat est invoqu� par double-clic sur le fichier de certificat. Internet Explorer installe spontan�ment les certificats auto-sign�s dans la liste des autorit�s de certification. A partir de ce point, Internet Explorer cesse d'�mettre des avertissements et consid�re comme fiables les certificats sign�s avec ce certificat de CA racine.

Il est �galement possible d'ouvrir le certificat depuis Internet Explorer qui en affiche alors le contenu. L'assistant d�marre ensuite en appuyant sur le bouton d'installation du certificat.

2.5.1. Cr�ation et signature de demandes de certificats

CA.pl -newreq
(openssl req -config /etc/openssl.cnf -new -keyout newreq.pem \
         -out newreq.pem -days 365)

La commande pr�c�dente cr�e une nouvelle clef priv�e et une demande de certificat qu'elle place dans newreq.pem. Pour s�curiser un site web, par exemple www.sopac.org, on utilise le nom d'usage (CN) www.sopac.org. Pour le courrier �lectronique de franck@sopac.org, on utiliserait franck@sopac.org.

CA.pl -sign
(openssl ca -config /etc/openssl.cnf -policy policy_anything \
         -out newcert.pem -infiles newreq.pem)

Cette commande signe la demande avec cacert.pem et sauve le certificat dans newcert.pem. Le mot de passe de cacert.pem (le certificat de CA) est n�cessaire. Un fichier newcerts/xx.pem est cr�� et les fichiers index.txt, serial sont mis � jour.

La clef priv�e se trouve donc dans la section -PRIVATE KEY- de newreq.pem et le certificat dans la section -CERTIFICATE- de newcert.pem.

Une copie de newcert.pem est �mise dans le r�pertoire newcerts/ et l'enregistrement correspondant ajout� � index.txt de telle sorte qu'un client puisse acc�der � l'information via un serveur web et v�rifier l'authenticit� du certificat.

On note que le fichier newreq.pem contient aussi bien la demande de certificat que la clef priv�e. La section -PRIVATE KEY- n'est pas n�cessaire � la signature et il faut absolument la retirer avant de transmettre la demande � quelqu'un d'autre pour qu'il la signe. De m�me, pour signer une demande de certificat, il suffit d'obtenir la section -CERTIFICATE REQUEST-. Il n'y a aucune raison de demander la clef priv�e.

2.5.2. R�vocation de certificat

La commande suivante r�voque un certificat�:

openssl -revoke newcert.pem

La base de donn�es index.txt est modifi�e en cons�quence et le certificat est annot� comme r�voqu�. Il reste � r�g�n�rer la liste de r�vocation des certificats�:

openssl ca -gencrl -config /etc/openssl.cnf -out crl/sopac-ca.crl

La liste de r�vocation (CRL/Certificate Revokation List) doit �tre rendue publique, par exemple sur un site web.

Les param�tres crldays, crlhours permettent de pr�ciser la prochaine date de mise � jour de la CRL. crlexts sp�cifie la section du fichier openssl.cnf � employer pour cr�er une CRL de version 2 en place d'une CRL de version 1.

openssl ca -gencrl -config /etc/openssl.cnf -crldays 7 \
           -crlexts crl_ext -out crl/sopac-ca.crl

2.5.3. Renouvellement d'un certificat

L'utilisateur transmet son ancienne demande de certificat ou en r�g�n�re une nouvelle bas�e sur sa clef priv�e.

Il faut alors r�voquer l'ancien certificat et signer la nouvelle demande de certificat.

L'ancien certificat se retrouve en cherchant dans le fichier index.txt le nom qualifi� (DN) qui correspond � la requ�te. La proc�dure de r�vocation s'effectue ensuite avec le num�ro de s�rie <xx> et le fichier de certificat cert/<xx>.pem.

La signature de la nouvelle requ�te peut �tre manuelle pour s'assurer que les dates de validit� du certificat seront correctes.

openssl ca -config /etc/openssl.cnf -policy policy_anything -out newcert.pem \
-infiles newreq.pem -startdate [now] -enddate [previous enddate+365days]

[now] et [previous enddate+365days] sont � remplacer par des valeurs ad�quates.

2.5.4. Affichage d'un certificat

L'affichage sous forme textuelle du contenu d'un certificat sous forme cod�e s'effectue avec la commande suivante�:

openssl x509 -in newcert.pem -noout -text

2.5.5. Le fichier index.txt

Le fichier index.txt contient les r�f�rences des certificats cr��s par OpenSSL. Les enregistrements sont annot�s avec un R pour indiquer que le certificat est r�voqu�, V qu'il est valide et E qu'il a expir�.

2.5.6. �laborer son service web d'autorit� de certification

�tre une autorit� de certification implique certaines t�ches�:

1. publier le certificat de CA racine pour qu'il puisse �tre d�ploy� dans les applications�;

2. publier la liste de r�vocation�;

3. afficher le contenu d�taill� des certificats, notamment leur num�ro de s�rie�;

4. fournir un formulaire de demande de certificats.

Un serveur web et quelques scripts permettent de r�aliser toutes ces fonctions.

COMPL�TEZ-MOI�: code de l'interface web.

3.1.1. mod_ssl (Apache) et les certificats

Il ne faut jamais se servir du certificat auto-sign� de la CA racine avec quelque application que ce soit, notamment avec Apache qui oblige � supprimer le mot de passe de protection de la clef priv�e.

On commence par cr�er et signer une demande de certificat dont le nom d'usage (CN) est du type www.mysite.com. On ne conserve que la section ---CERTIFICATE --- du certificat.

La clef doit �tre d�verrouill�e en en autorisant l'usage sans devoir rentrer le mot de passe. On supprime donc le mot de passe du fichier newreq.pem�:

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

Comme la clef priv�e n'est plus prot�g�e, on a int�r�t � savoir ce qu'on fait et notamment � v�rifier les droits d'acc�s aux fichiers. Si quelqu'un arrive � s'en emparer, le site est compromis. On peut � pr�sent utiliser newcert et wwwkeyunsecure.pem avec Apache.

On copie wwwkeyunsecure.pem et newcert.pem dans le r�pertoire /etc/httpd/conf/ssl/ dans les fichiers wwwkeyunsecure.pem et wwwcert.crt respectivement.

On �dite ensuite /etc/httpd/conf/ssl/ssl.default-vhost.conf�:

----
# Server Certificate:
# SSLCertificateFile doit pointer vers un certificat en PEM.
# Si on verrouille le certificat, un mot de passe est requis.
# kill -HUP demande de nouveau le certificat. On cree un
# certificat de test via `make certificate' lors de la
# compilation. 
#SSLCertificateFile conf/ssl/ca.crt
SSLCertificateFile wwwcert.crt
# Clef secrete du serveur:
# A employer lorsque la clef est separee du certificat.
#SSLCertificateKeyFile conf/ssl/ca.key.unsecure
SSLCertificateKeyFile wwwkeyunsecure.pem
----

On arr�te httpd (/etc/rc.d/init.d/httpd stop) puis on v�rifie que tous les processus ont disparu (killall httpd) avant de relancer le d�mon (/etc/rc.d/init.d/httpd start).

3.1.2. IMAPS et les certificats

Se reporter au paragraphe ��POPS et les certificats�� pour davantage de d�tails.

3.1.3. POPS et les certificats

Un fichier pem pour ipop3sd se cr�e en g�n�rant un certificat, en d�verrouillant la clef priv�e et et combinant les deux dans le fichier /etc/ssl/imap/ipop3sd.pem. Ce dernier fichier correspond � l'emplacement attendu par le rpm de la Mandrake�9.0. La m�me proc�dure s'applique � imap avec le fichier /etc/ssl/imap/imapsd.pem.

Le CN doit correspondre au nom auquel le client de messagerie se connecte (par exemple mail.xyz.org). Avec MS-Outlook, le nom du serveur pop se rentre dans l'onglet � cet effet et on active l'option ��This server requires a secure connection (SSL)�� dans les propri�t�s avanc�es. Les connexions s'effectuent alors sur le port 995 (imaps). Le certificat de la CA doit �tre install� dans MS Internet Explorer pour que le certificat de mail.xyz.org soit valid�.

3.1.4. Postfix et les certificats

COMPL�TEZ-MOI

3.1.5. Stunnel et les certificats

COMPL�TEZ-MOI

3.1.6. Cr�ation et signature de clef avec Microsoft Key Manager

Dans Microsoft Key Manager, on choisit le service pour lequel on souhaite cr�er un certificat, par exemple IMAP (ou WWW). L'assistant permet de g�n�rer une nouvelle clef. Il faut s'assurer de ce que le nom qualifi� n'est pas identique � celui d'une clef existante. Un nom d'usage (CN) tel imap.mycompany.com fait l'affaire. L'assistant sauve la demande dans le fichier C:\NewKeyRq.txt. Key Manager indique la clef avec un signe qui signale qu'elle n'est pas sign�e.

On copie ce fichier dans le r�pertoire /var/ssl d'OpenSSL sous le nom newreq.pem et on signe la requ�te comme � l'accoutum�.

CA.pl -sign

newcert.pem n'est pas intelligible par Key Manager car il contient du texte et une section -CERTIFICATE-. Il faut supprimer le texte�:

openssl x509 -in newcert.pem -out newcertx509.pem

Un �diteur remplit �galement cette t�che.

newcertx509.pem ne contient plus qu'une section -CERTIFICATE-.

On recopie newcertx509.pem sur la machine o� s'ex�cute Key Manager. Il suffit alors de cliquer du bouton droit dessus dans l'application Key Manager et de renseigner le mot de passe. La clef est alors fonctionnelle.

3.2.1. Cr�ation et emploi d'un certificat S/MIME

Il faut simplement g�n�rer et signer une demande de certificat avec l'adresse �lectronique en guise de nom d'usage (CN).

On peut alors signer un message de test test.txt avec le nouveau certificat newcert.pem et la clef newreq.pem�:

openssl smime -sign -in test.txt -text -out test.msg -signer newcert.pem -inkey newreq.pem

test.msg peut �tre transmis � n'importe qui et cette proc�dure s'applique pour �mettre des notes sign�es ou tout autre document sign� destin� � �tre publi� �lectroniquement.

3.2.2. Emploi du certificat S/MIME avec MS Outlook

Il faut l'importer dans Outlook sous forme de fichier pkcs12. La cr�ation du fichier pkcs12 s'effectue comme suit�:

CA.pl -pkcs12 "Franck Martin"
(openssl pkcs12 -export -in newcert.pem -inkey newreq.pem \
         -out newcert.p12 -name "Franck Martin")

Il est possible de lier le certificat de signature au fichier pkcs12�:

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

Ce certificat contient les clefs priv�es et publique. Seul le mot de passe prot�ge cette derni�re. Le fichier ne doit donc pas tra�ner n'importe o�.

On suit les menus Tools, Options et Security de MS Outlook. Un clic sur le bouton import/export active l'import du fichier pkcs12. Il n'y a plus qu'� renseigner le mot de passe d'export et l'identit� de l'utilisateur, "Franck Martin" dans mon cas (� adapter).

On clique ensuite sur le bouton Settings puis, MS Outlook ayant normalement s�lectionn� les choix par d�faut, sur New. Il est alors possible d'envoyer des courriers �lectroniques sign�s. La clef publique est transmise en m�me temps que les messages sign�s et le destinataire est donc en mesure de renvoyer des donn�es chiffr�es.

Comme le certificat a �t� g�n�r� � partir d'un certificat auto-sign�, le chemin de validation ne sera pas valide tant que l'application ne conna�t pas le certificat de l'AC racine. On se reportera � la section d'installation du certificat de l'AC racine dans Internet Explorer pour la d�tail de la marche � suivre.

Le message est envoy� sign�/chiffr� ou simplement sign� en clair. Le chiffrement n'en est pas vraiment un dans la mesure o� le message contient tout le n�cessaire pour effectuer le d�chiffrement.

Certaines anciennes versions de MS Outlook pour XP parcourent Internet pour v�rifier la validit� du certificat. Plusieurs secondes peuvent alors s'�couler avant que le courrier ne soit affich�, voire plusieurs minutes pour que le hors-temps de MS Outlook ne se d�clenche si on n'est pas connect� en permanence. Ce processus bloque toute la machine jusqu'� ce que MS Outlook l'ait achev� d'une fa�on ou d'une autre.

3.2.3. Emploi du certificat S/MIME avec MS Outlook Express

COMPL�TEZ-MOI

3.2.4. Emploi du certificat S/MIME avec Netscape Messenger

COMPL�TEZ-MOI

3.2.5. Emploi du certificat S/MIME avec Evolution

Evolution 1.0 ne g�re pas S/MIME mais seulement PGP. La prise en charge S/MIME est pr�vue pour une version ult�rieure (d'apr�s la base de donn�es de suivi des bogues d'Evolution). Evolution remarque quand m�me parfois que le document est sign� en clair et l'affiche correctement bien qu'il ne puisse en v�rifier la validit�. Des versions ant�rieures d'Evolution n'assimilaient pas un des trois types MIME de signature que MS Outlook emploie h�las assez souvent.

3.2.6. Emploi du certificat S/MIME avec Balsa

COMPL�TEZ-MOI

3.2.7. Emploi du certificat S/MIME avec KMail

COMPL�TEZ-MOI

3.3.1. WinCrypt

WinCrypt s'appuie sur l'API de chiffrage de Microsoft pour chiffrer et signer les fichiers. Il cr�e en outre de fa�on optionnelle une archive zip avant la signature. Il dispose d'un frontal pour g�rer la liste des certificats, les parcourir, en installer, en supprimer et choisir celui � employer avec WinCrypt.

La proc�dure de cr�ation d'un certificat est identique � celle de Microsoft Outlook. La m�me liste de certificats est utilis�e par les deux applications.

Un fichier filename.sgn sign� avec WinCrypt se v�rifie avec la commande�:

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

La commande suivante permet de signer un fichier avec OpenSSL de fa�on compatible�:

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

Pour visualiser l'organisation d'un fichier sign�:

openssl asn1parse -inform der -in filename.sgn

3.4.1. Micosoft Code

Il est possible de signer ses programmes et ses applets pour prouver qu'on en est l'auteur. Il est important pour les clients de savoir que personne n'a modifi� le code en y ins�rant un virus ou un cheval de Troie. L'�tape de signature n�cessite le SDK Microsoft Authenticode. Ce dernier est disponible dans la section MSDN du site web de Microsoft.

On g�n�re un certificat comme � l'accoutum� mais avec un nom d'usage de la forme ��ACME Software Cert��. Le certificat doit ensuite �tre sign� par l'autorit� de certification et converti au format pkcs12.

CA.pl -newreq
CA.pl -sign
CA.pl -pkcs12 "ACME Software Cert"

On obtient un fichier newcert.p12 qu'on importe dans la liste des certificats en cliquant dessus une fois sous MS Windows.

Le certificat peut alors servir � signer du code�:

signcode -cn "ACME Software cert" -tr 5 -tw 2 -n "My Application" \
-i http://www.acme.com/myapp/ \
-t http://timestamp.verisign.com/scripts/timstamp.dll myapp.exe

A l'installation et � l'ex�cution de l'application, une boite de dialogue appara�t sous le nom ��My Application�� avec le lien point� par l'argument -i.

3.5.1. FreeS/WAN

FreeS/WAN est une souche IPSec renomm�e pour GNU/Linux. La version actuelle (1.9.7) doit �tre patch�e pour g�rer les certificats X.509v3. Une telle version modifi�e est disponible sur ce site. Certaines distributions l'incluent en standard, il est donc conseill� de commencer par v�rifier si c'est le cas pour celle qu'on utilise. Cette version pr�sente l'int�r�t de permettre l'usage d'OpenSSL pour la cr�ation des certificats de FreeS/WAN et des enregistrements CERT du DNS. En outre, l'interaction avec la souche IPSec de Microsoft est r�alisable. On se reportera � la page de Nate's pour davantage d'informations.

mv newreq.pem /etc/freeswan/ipsec.d/private/host.example.com.key
mv newcert.pem /etc/freeswan/ipsec.d/host.example.com.pem

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

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

: RSA host.example.com.key 
          "password"

config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes
  
conn %default
keyingtries=1
compress=yes
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
 
conn roadwarrior-net
leftsubnet=<sous_reseau>/<masque_de_sous_reseau>
also=roadwarrior

conn roadwarrior
right=%any
left%defaultroute
leftcert=host.example.com.pem
auto=add
pfs=yes

mv newreq.pem /etc/freeswan/ipsec.d/private/clienthost.example.com.key
mv newcert.pem /etc/freeswan/ipsec.d/clienthost.example.com.pem

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

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

mv host.example.com.pem /etc/fresswan/ipsec.d/host.example.com.pem

: RSA clienthost.example.com.key
        "password"

config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes
  
conn %default
keyingtries=0
compress=yes
disablearrivalcheck=no
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert
  
conn roadwarrior-net
left=(ip of host)
leftsubnet=(gateway_host_subnet)/(gateway_host_netmask)
also=roadwarrior
  
conn roadwarrior
left=(ip of host)
leftcert=host.example.com.pem
right=%defaultroute
rightcert=clienthost.example.com.pem
auto=add
pfs=yes

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

openssl x509 -in cacert.pem -noout -subject

conn roadwarrior 
left=%any 
right=(ip_du_systeme_distant) 
rightca="C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root"
network=auto 
auto=start 
pfs=yes
 
conn roadwarrior-net 
left=%any 
right=(ip_du_systeme_distant) 
rightsubnet=(sous_reseau)/(masque_de_sous_reseau)
rightca="C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root" 
network=auto 
auto=start 
pfs=yes

C:\ipsec>ipsec
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)/255.255.255.255 
PartnerTunnel: (ip_of_remote_system) 
PartnerNet : (ip_of_remote_system)/255.255.255.255 
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)/255.255.255.255 
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...
C:\ipsec>