HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > Utilisation d'OpenSSL pour les applications SSL/TLS
Go to: HSC Trainings
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Utilisation d'OpenSSL pour les applications SSL/TLS  

by Franck Davy (21/12/2001)



--[  Utilisation d'Openssl pour les applications SSL/TLS ]--


Cette brève aborde quelques aspects de la configuration d'applications
supportant les protocoles SSL/TLS et se fondant sur la bibliothèque
openssl, de la génération des certificats aux options les plus souvent
rencontrées. 3 applications sont citées en exemple : le serveur de test
fourni avec openssl, Apache+mod_ssl et enfin Postfix-TLS.


1. Format du fichier openssl.cnf

Il faut se référer au fichier openssl.cnf par défaut pour avoir le 
format général. La documentation se trouve principalement dans le 
fichier doc/openssl.txt. 

Seules les extensions v3 seront manipulées, respectant la syntaxe :
extension_name=[critical,] extension_options

Ces extensions sont introduites car les bi-clés générés peuvent être de
divers usages (bi-clé de chiffrement, bi-clé de signature et bi-clé
d'échange de clés) et les exigences en terme de sécurité différentes
(recouvrement pour un bi-clé de chiffrement, auquel un service de non
répudiation ne peut donc être associé).

Outre des informations sur le bi-clé, ces extensions permettent
d'imposer des contraintes sur l'itinéraire de certification à parcourir
(autrement dit la chaîne à parcourir pour valider un certificat),
renseigner sur la politique de certification concernant le certificat
présenté, ou encore sur la façon d'accèder aux listes de révocation.

Les plus courantes sont brièvement abordées :

 * basicConstraints
- pathlen : nombre de CA pouvant apparaître sous (autrement signés par)
le certificat
- CA : TRUE pour une autorité, inutile pour une entité terminale (mais
à FALSE pour compatibilité)

 * keyUsage
- digitalSignature (RSA/DSA) : pour la signature (en tant que mécanisme,
  autrement dit le chiffrement d'une empreinte avec une clé privée)
- nonRepudiation (RSA/DSA) : idem, mais en tant que service (autrement
  dit la volonté d'ajouter un service de non répudiation à une
  signature). Pour du S/MIME, bit positionné avec digitalSignature
  typiquement
- keyEncipherment (RSA) : chiffrement de clé (clé secrète d'algorithme
  symétrique généralement, ou premaster secret ou encore clé RSA
  éphémère en SSL/TLS)
- dataEncipherment (RSA) : chiffrement de données (hors clé de session,
  crl, certificat)
- keyCertSign (RSA/DSA) : signature de certificats (pour les CA donc)
- cRLSign (RSA/DSA) : signature de listes de révocation
- keyAgreement (DH) : pour la négociation d'une clé de session
- encipherOnly et decipherOnly (DH) : positionnés conjointement à
  keyAgreement

 * nsCertType
- client ou server : pour une authentification client ou serveur en
  SSL/TLS
- email : pour du S/MIME
- objsign : pour la signature de code (applet java typiquement)
- sslCA, emailCA, objCA : pour délivrer des certificats ayant les
  propriétés précédentes

 * extendedKeyUsage
serverAuth, clientAuth, codeSigning, emailProtection, pour les plus
courantes. 
Les noms sont suffisamment explicites.

 * subjectAltName
Utiles pour les hôtes virtuels par nom, ou encore les adresses emails
multiples associées à un même certificat. Malheureusement, c'est le
commonName qui est généralement utilisé.

 * crlDistributionPoints
Indique le(s) façon(s) de télécharger les listes de révocation, via LDAP
ou HTTP.


2. Génération des certificats

Le fichier de configuration openssl.cnf, donné en annexe, est supposé 
situé dans le répertoire courant.

On crée les fichiers et répertoires nécessaires :
$ mkdir -p ca/newcerts		# Répertoire recueillant les certificats
				# émis par CA ROOT
$ touch ca/index.txt		# Base de données des certificats émis
$ echo '01' > ca/serial 	# Numéro de série, initialisé à 1. 
				# Incrémenté par la suite

$ mkdir -p cassl/newcerts	#idem, pour CA SSL
$ touch cassl/index.txt
$ echo '01' > cassl/serial


2.1. Génération du certificat de l'autorité racine

Il s'agit du CA racine, par conséquent autosigné.

* Génération du bi-clé RSA, protégé par une passphrase
$ openssl genrsa -out ca/ca.key -des3 2048

* Génération du certificat auto-signé
$ openssl req	-new \
		-x509 \			# Génération d'un certificat autosigné, 
					# et non d'une simple requête 
		-key ca/ca.key \	# La clé publique est extraite du bi-clé précédente
		-out ca/ca.pem \	# Le certificat est copié
		-config ./openssl.cnf \ # Le fichier de configuration n'est pas celui 
                                        # par défaut
		-extensions CA_ROOT	# La section CA_ROOT est utilisée (cf Annexe)

 Pour vérifier le bon usage du certificat :
$ openssl x509 -in ca/ca.pem -text -noout
$ openssl x509 -purpose -in ca/ca.pem -noout

2.2. Génération du certificat de l'autorité intermédiaire SSL

Il s'agit d'un CA intermédiaire, dont le certificat est signé par le 
CA ROOT.

$ openssl genrsa -out cassl/cassl.key -des3 2048

 Génération de la demande de certificat :
$ openssl req	-new \			# Génération d'une demande de certificat
		-key cassl/cassl.key \
		-out cassl/cassl.crs \
                -config ./openssl.cnf

 Signature de la demande de certificat par le ca root (CA par défaut dans openssl.cnf) :
$ openssl ca	-out cassl/cassl.pem \
		-config ./openssl.cnf \
		-extensions CA_SSL \
		-infiles cassl/cassl.crs # Demande de certificat à signer
Ainsi :
 * Le certificat signé est crée dans cassl/cassl.pem
 * Une copie est réalisée dans ca/newcerts/01.pem
 * Les fichiers ca/serial et ca/index.txt sont mis à jour

2.3 Génération d'un certificat serveur SSL

# openssl genrsa -out cassl/serverssl.key -des3 1024
$ openssl req   -new \
                -key cassl/serverssl.key \
                -out cassl/serverssl.crs \
                -config ./openssl.cnf

$ openssl ca    -config ./openssl.cnf \
		-name CA_ssl_default \		# Le certificat utilisé pour signer 
                                                # la requête est celui de CA SSL
                -extensions SERVER_RSA_SSL \
                -infiles cassl/serverssl.crs

Dans ce cas, l'autorité signataire est ca_ssl
Si tout se déroule correctement : 
Le certificat serveur est renvoyé sur la sortie standard, et copié dans
cassl/newcerts/01.pem
Les fichiers cassl/serial et cassl/index.txt sont mis à jour.

Remarque : pour générer un certificat client, il faut reproduire la
procédure ci-dessus, avec l'extension CLIENT_RSA_SSL (voir le fichier de
configuration en annexe). Généralement, on l'exporte avec la clé privée
dans un fichier pkcs#12, suivant la syntaxe :

$ openssl pkcs12 -export \
	-inkey clientssl.key \
	-in clientssl.pem \
	-out clientssl.p12 \
	-name "Certificat client"

Enfin on importe le fichier obtenu dans son navigateur.


3. Configuration

Les paramètres généralement rencontrés sont les suivants :

 (1) Le certificat X.509 à présenter pour l'authentification :
Il doit s'agir du certificat dont on possède la clé privée.
Ce certificat doit être au format PEM (DER encodé en base64).

 (2) La clé privée correspondant à la clé publique renfermée dans le 
certificat :
Au format PEM encore une fois. Il est généralement recommandé de 
chiffrer cette clé (mais ce n'est pas le cas généralement).

 (3) La liste des certificats des autorités reconnues :

Dans ce cas, deux possibilités pour la configuration,

- Utilisation d'un répertoire (-CApath) :
L'ensemble des certificats, au format PEM, doit être placé dans le 
répertoire passé en paramètre.
Les certificats sont recherchés suivant le "subject name hash value" 
(en premier lieu). 
Celui-ci est calculé via l'option hash d'openssl.
Pour accélérer la recherche, un lien pointant vers le certificat est 
crée, dont le nom est "hash.0"
Exemple :
$ openssl x509 -hash -in certificat.pem -noout
22f2539e
$ ln -s certificat.pem 22f2539e.0

Si deux certificats ont le même 'subject name hash value', ils seront 
distingués suivant la valeur de l'extension, typiquement : 9d66eef0.0, 
9d66eef0.1

Les liens peuvent être crées automatiquement avec l'utilitaire c_rehash:
$ c_rehash .
Doing .
certificat.pem => 22f2539e.0

- Utilisation d'un fichier (-CAfile) :
Dans ce cas, les certificats des autorités de confiance doivent être 
concaténés dans un seul et même fichier, au format PEM.
Seuls les champs situés entre les balises -----BEGIN CERTIFICATE----- 
et -----END CERTIFICATE----- sont considérés. 
Le reste est du commentaire.

A partir de ce fichier est construite la chaîne de certification 
présentée au client, ainsi que les certificats proposés pour son 
authentification. 

Il est recommandé d'utiliser l'option CAfile :

- D'une part, le fichier est lu à l'initialisation du programme, et peut
par conséquent être placé hors d'une cage, dans le cas d'un chroot() 
par exemple (voir Postfix-TLS).

- D'autre part, la liste des certificats présentés au client pour 
authentification est souvent constituée des certificats de ce fichier 
uniquement (la documentation n'est pas extrêmement claire à ce sujet) : 
ces certificats sont en effet chargés par la fonction 
SSL_CTX_set_client_CA_list(), dont le prototype est :
void SSL_CTX_set_client_CA_list(SSL_CTX *ctx, STACK_OF(X509_NAME) *list);

Or, dans le patch pour Postfix :
$ grep 'SSL_CTX_set_client_CA_list' pfixtls.diff
SSL_CTX_set_client_CA_list(ctx, SSL_load_client_CA_file(CAfile));

de même dans apps/s_server.c (archive openssl) :
$ grep SSL_CTX_set_client_CA_list s_server.c
SSL_CTX_set_client_CA_list(ctx,SSL_load_client_CA_file(CAfile));

La liste des certificats présentés au client provient uniquement de la
liste pointée par l'option CAfile dans les 2 cas. Les deux options ne 
sont donc pas strictement équivalentes, dans ces cas là.

Le cas du serveur Apache est différent :
$ grep 'SSL_CTX_set_client_CA_list' pkg.sslmod/ssl_engine_init.c
        SSL_CTX_set_client_CA_list(sc->pSSLCtx, skCAList);
où skCAList est initialisé ainsi :
(skCAList = ssl_init_FindCAList(s, p, sc->szCACertificateFile,
                                            sc->szCACertificatePath)

3.2. Exemples d'utilisation

3.2.1 s_server et s_client (openssl s_server et openssl s_client)

(1) Le serveur de test aura pour certificat serverssl.pem.
Le certificat utilisé est celui généré précédemment (01.pem), soit :
$ openssl x509 -in cassl/newcerts/01.pem -subject -issuer > cassl/serverssl.pem
(les options -subject et -issuer sont utilisées pour avoir une meilleure
lisibilité, le texte produit étant considéré comme du commentaire)

(2) La clé privée du serveur est cassl/serverssl.key, préalablement générée.

(3) Le fichier en argument de CAfile référençant les autorités de confiance sera 
trustees.pem :
$ for i in cassl/cassl.pem ca/ca.pem; do openssl x509 -in $i -issuer \
  -subject  >> cassl/trustees.pem; done;

Le serveur de test peut donc typiquement être lancé ainsi :
$ openssl s_server	-accept 4443 \
			-cert cassl/serverssl.pem -key cassl/serverssl.key \
                        -CAfile cassl/trustees.pem \
			-verify 3 \	# Pour effectuer une vérification du client, 
					# et lui présenter une liste d'autorités valides 
			-www

L'intérêt de fournir au client la chaîne complète des certificats est le
suivant :
Lorsque l'on a une chaîne dont la racine est une autorité bien connue 
(intégrée à un navigateur par exemple), le client n'a pas besoin de 
posséder l'intégralité des certificats: un seul suffit, celui de 
l'autorité racine.
Et ce quelque soit la longueur de la chaîne (d'où l'intérêt d'adopter 
un modèle hierarchique pour une meilleur organisation).
(Encore faut-il que le client soit capable de gérer les itinéraires de 
certification d'une longueur supérieure à 2).

Une connexion avec s_client donne le résultat suivant (seul le 
certificat racine est pointé par CAfile, conformément au point évoqué 
ci-dessus) : 

$ openssl s_client	-connect 127.0.0.1:4443 \
			-CAfile ca/ca.pem \
			-showcerts

depth=2 /C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA ROOT
verify return:1
depth=1 /C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA SSL
verify return:1
depth=0 /C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=www.webserver.com
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=www.webserver.com
   i:/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA SSL
-----BEGIN CERTIFICATE-----
MIIEXzCCA0egAwIBAgIBATANBgkqhkiG9w0BAQUFADB1MQswCQYDVQQGEwJGUjEW
[...]
49boA4pEtOu7z2IdJALfpuxpMg==
-----END CERTIFICATE-----
 1 s:/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA SSL
   i:/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA ROOT
-----BEGIN CERTIFICATE-----
MIIEhDCCA2ygAwIBAgIBATANBgkqhkiG9w0BAQUFADB2MQswCQYDVQQGEwJGUjEW
[...]
6iOIIXTd/gs=
-----END CERTIFICATE-----
 2 s:/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA ROOT
   i:/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA ROOT
-----BEGIN CERTIFICATE-----
MIIEaTCCA1GgAwIBAgIBADANBgkqhkiG9w0BAQQFADB2MQswCQYDVQQGEwJGUjEW
[...]
cedCvIobO5JjiKxi7HhXxoN9unWd3m4M7V/GZ0E=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=www.webserver.com
issuer=/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA SSL
---
Acceptable client certificate CA names
/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA SSL
/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herve Schauer Consultants/CN=CA ROOT
---
SSL handshake has read 4104 bytes and written 268 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
    Protocol  : TLSv1
    Cipher    : EDH-RSA-DES-CBC3-SHA
    Session-ID: 269BC84135E313F12A9E624065FAC6FA9452D2F728AE518FEB17E009B8E3FF8B
    Session-ID-ctx: 
    Master-Key: 95F39BE9741D3B55B418A3B6BC8B0F9B3649CFF629B2259DEA36C4EAF16D4AB011FE6F62D914A679F7E915344AE8938E
    Key-Arg   : None
    Start Time: 1008002520
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
GET /
HTTP/1.0 200 ok
Content-type: text/html
[...]


Aucun message d'erreur n'est généré (return code: 0) : les certificats 
présentés au client ont été successivement vérifiés avec succès.

Seule la connaissance du certificat de l'autorité racine était 
effectivement requise.

Une nuance fondamentale cependant, ne pas confondre authentification 
avec autorisation.
Dans cet exemple, un certificat client signé par CA SSL ou CA ROOT est 
automatiquement considéré comme valide (digne de confiance) :
ceci est justifié, dans la mesure où le certificat même du serveur est 
signé par ces autorités.

En revanche, les applications (Apache, Postfix-TLS etc.) utilisant les 
certificats X.509 devront de surcroît introduire la notion 
d'autorisation, non seulement sur la base des autorités ayant émis le 
certificat présenté, mais également suivant le contenu de ce certificat 
(DN, email etc.).
Autrement dit : la notion de CAfile apparaîtra systématiquement (sous 
une forme plus ou moins similaire), mais un certificat valide ne 
garantira naturellement pas, par exemple, l'accès à un répertoire 
protégé ou encore le droit de relayer du courrier.

On peut donc naturellement ajouter les principales autorités de 
certification au fichier pointé par CAfile, les autorisations quant 
à elles étant dépendantes des programmes utilisés (dans l'exemple 
précédent, la notion d'autorisation n'intervenait absolument pas). 

La liste des certificats de ces autorités est située en annexe.


3.2.2 Serveur Apache + mod_ssl

Les certificats sont utilisés d'une part pour authentifier le serveur,
mais ils peuvent également être utilisés pour authentifier les clients
et les autoriser suivant le contenu du certificat (valide) présenté à 
accéder à des espaces restreints.

Un résultat similaire au précédent est obtenu en adoptant une telle 
configuration, par exemple :

[...]
SSLEngine on

SSLCertificateFile /etc/ssl/cassl/serverssl.pem
SSLCertificateKeyFile /etc/ssl/cassl/serverssl.key
SSLCACertificateFile /etc/ssl/cassl/trustees.pem		
# L'option SSLCACertificatePath aurait pu être utilisée dans ce cas

SSLVerifyClient optional
SSLVerifyDepth  3
[...]

Les traces obtenues sont les mêmes que précédemment.
L'utilisation des variables d'environnement introduites par mod_ssl 
permettent d'introduire la notion d'autorisation, via la directive 
SSLRequire typiquement.


3.2.3 MTA Postfix

Dans ce cas, les certificats sont utilisés pour une authentification
entre MTA, mais également afin d'autoriser un MTA tiers à relayer son
courrier sur la base du certificat présenté (la granularité étant 
cependant beaucoup moins fine que pour le serveur Apache : c'est le
certificat complet qui est pris en compte, suivant son empreinte, 
aucune distinction sur le CN n'est possible par exemple)

Extrait du fichier /etc/postfix/main.cf :

smtpd_tls_cert_file = /etc/postfix/cert.pem
smtpd_tls_key_file = /etc/postfix/key.pem
smtpd_tls_CAfile = /etc/postfix/trustees.pem

Cette configuration sert à l'authentification. 

Concernant l'autorisation de relayer du courrier, via la directive 
smtpd_recipient_restrictions :

smtpd_recipient_restrictions = permit_mynetworks,
                               check_recipient_access hash:/etc/postfix/recpt,
                               check_relay_domains

Deux possibilités alors :

- (a) Ajouter la ligne "permit_tls_clientcerts"
  Dans ce cas, le client a présenté un certificat valide, *et* ce 
certificat est référencé dans la liste des certificats clients
autorisés (via la directive relay_clientcerts, référençant les empreintes
md5 de ces certificats).

- (b) Ajouter la ligne "permit_tls_all_clientcerts"
  Dans ce cas, tout certificat valide (autrement dit, signé par une 
autorité de confiance référencée dand smtpd_tls_CAfile) est accepté : 
ainsi, le relayage de toute personne authentifiée est autorisé, même si
elle n'est pas connue (typiquement, cela signifierait que le serveur 
de mail accepterait de relayer des courriers provenant d'un utilisateur 
certifié par Certplus, Certiposte etc.)

Dans le cas (a), il faut donc explicitement référencer les certificats 
des utilisateurs autorisés à relayer. Ceci est réalisé de la façon 
suivante :
relay_clientcerts = hash:/etc/postfix/relay_clientcerts

où relay_clientcerts contient une suite d'entrées de la forme :
5D:51:13:BB:D1:93:D9:7A:B3:00:B7:BC:80:B7:BA:CD www.webserver.com

Seul le premier champ (fingerprint) importe.  Il est calculé avec
openssl de la façon suivante (MD5 du certificat en DER) :
$  openssl x509 -md5 -fingerprint -noout -in cassl/serverssl.pem
MD5 Fingerprint=5D:51:13:BB:D1:93:D9:7A:B3:00:B7:BC:80:B7:BA:CD

L'option '-md5' doit être précisée, dans la mesure où postfix ne
gère que les empreintes MD5, et que la bibliothèque openssl est
susceptible de calculer une empreinte SHA1 par défaut.
Ces certificats de MTA autorisés à relayer ne sont naturellement pas 
présents sur le serveur : le fingerprint est simplement recalculé et 
vérifié lorsque le certificat est présenté.

Ainsi, le processus de relayage sur la base de certificat est réalisé
en 2 étapes :

- Validation du certificat présenté, sur la base des autorités de 
confiance pointées par smtpd_tls_CAfile
- Consultation du fichier référencé par l'option relay_clientcerts, afin
de vérifier que le fingerprint est correctement renseigné afin 
d'accorder l'autorisation (quelque soit l'adresse IP).
Dans tous les autres cas, il faut être dans un réseau référencé par 
"permit_mynetworks" (directement, ou via ppp).



--[ ANNEXES ]--

ANNEXE 1 : Fichier openssl.cnf

[ ca ]
default_ca      = CA_default

[ CA_default ]
dir             = .
certs           = $dir/ca/certs
new_certs_dir   = $dir/ca/newcerts
database        = $dir/ca/index.txt
certificate     = $dir/ca/ca.pem
serial          = $dir/ca/serial
private_key     = $dir/ca/ca.key
default_days    = 365
default_md      = sha1
preserve        = no
policy          = policy_match

[ CA_ssl_default ]
dir             = .
certs           = $dir/cassl/certs
new_certs_dir   = $dir/cassl/newcerts
database        = $dir/cassl/index.txt
certificate     = $dir/cassl/cassl.pem
serial          = $dir/cassl/serial
private_key     = $dir/cassl/cassl.key
default_days    = 365
default_md      = sha1
preserve        = no
policy          = policy_match

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

[ req ]
distinguished_name      = req_distinguished_name

[ req_distinguished_name ]
countryName                     = Pays
countryName_default             = FR
stateOrProvinceName             = Departement
stateOrProvinceName_default     = Ile-de-France
localityName                    = Ville
localityName_default            = Levallois-Perret
organizationName        	= Organisation
organizationName_default        = Herve Schauer Consultants
commonName                      = Nom ou URL
commonName_max                  = 64
emailAddress                    = Adresse Email
emailAddress_max                = 40

[CA_ROOT]
nsComment                       = "CA Racine"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
basicConstraints                = critical,CA:TRUE,pathlen:1
keyUsage                        = keyCertSign, cRLSign

[CA_SSL]
nsComment                       = "CA SSL"
basicConstraints                = critical,CA:TRUE,pathlen:0
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
keyUsage                        = keyCertSign, cRLSign
nsCertType                      = sslCA

[SERVER_RSA_SSL]
nsComment                       = "Certificat Serveur SSL"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
subjectAltName                  = DNS:www.webserver.com, DNS:www.webserver-bis.com
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation, keyEncipherment
nsCertType                      = server
extendedKeyUsage                = serverAuth

[CLIENT_RSA_SSL]
nsComment                       = "Certificat Client SSL"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
subjectAltName                  = critical,email:copy,email:user-bis@domain.com,email:user-ter@domain.com
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation
nsCertType                      = client
extendedKeyUsage                = clientAuth


ANNEXE 2 : Certificats racines.

                         ### Attention ###

(1) Les certificats qui suivent sont intégrés à IE 5.0 : cela ne 
signifie pas qu'ils sont dignes de confiance
Les certificats à conserver sont donc à choisir avec le plus grand 
soin.

(2) Télécharger ainsi de tels certificats est contraire au fondement 
même des PKI...

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


Ces certificats sont les certificats root exportés de Windows 2000.
L'utilitaire utilisé est certmgr.exe, fourni avec la suite d'outils 
"Authenticode for IE 5.0" (archive codesign.exe)

L'exportation se fait ainsi :
certmgr -add -all -c -s root -7 win2k_rootcerts.der

Ainsi, l'ensemble des certificats situés dans la base système "root" 
est copié au format PKCS7 dans le fichier win2k_rootcerts.der. La 
conversion dans un format plus lisible et exploitable peut se faire avec
openssl :

$ openssl pkcs7 -in win2k_rootcerts.der -inform DER -print_certs

Le résultat est ici : http://www.hsc.fr/~davy/certs/trustees.pem

$Id: ssl_configuration.tip,v 1.3 2002/01/21 19:49:45 jombart Exp $



Last modified on 8 August 2007 at 14:55:02 CET - webmaster@hsc.fr
Mentions légales - Information on this server - © 1989-2013 Hervé Schauer Consultants