| |
Utilisation d'OpenSSL pour les applications SSL/TLS
par Franck Davy (21/12/2001)
URL Originale : http://www.hsc.fr/ressources/breves/ssl_configuration.html.fr
--[ 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 -fingerprint -noout -in cassl/serverssl.pem
MD5 Fingerprint=5D:51:13:BB:D1:93:D9:7A:B3:00:B7:BC:80:B7:BA:CD
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 $
Utilisation d'OpenSSL pour les applications SSL/TLS
par Franck Davy (21/12/2001)
URL Originale : http://www.hsc.fr/ressources/breves/ssl_configuration.html.fr
|