Openstuff Wiki : HowtoPKI

HomePage :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Login/Register

Revision [227]

This is an old revision of HowtoPKI made by StanKju on 2007-04-04 18:15:59.
 

Mise en oeuvre d'une PKI via des outils libres


L'objectif de cet article est de mettre en place une infrastructure de gestion de clefs à partir d'outils de base tel qu'OpenSSH ceci afin d'obtenir une architecture simple à mettre en oeuvre.

1 Etat des lieux


Commençons par un petit retour sur les notions de PKI.

1.1 Rappel sur les concepts de PKI


Une PKI (Public Key Infrastructure) ou IGC (Infrastructure de Gestion de Clefs) en français, est un système permettant la gestion de certificats numériques. Un tel certificat permet d'identifier aussi bien des machines que des personnes. Les certificats ont de nombreuses applications, ils peuvent être utilisés pour sécuriser les échanges avec un serveur Web (HTTPS), son MTA (SMTP-TLS) mais aussi de signer et chiffrer ses courriers électronique.

Le rôle d'une infrastructure de gestion de cléfs est donc de permettre la création de tel certificats mais aussi leur destruction appelé révocation. Ceux-ci sont normalisée et peuvent prendre plusieurs formes. Les plus courantes sont:

OpenPGP est une approche distribuée qui se prête bien au cadre personnel mais ne réponds pas forcément aux problématique entreprise. Les certificats X.509 s'intègrent particulièrement bien aux annuaires et permettent une gestion centralisée.

La norme X.509 définit plusieurs champs dont les principaux sont:

Afin de permettre de gérer de tels cerficats, une PKI s'organise en plusieurs entités:

1.2 La problématique de révoquation


Il est relativement simple de mettre en place des certificats X.509 pourtant la problématique de révocation est loin d'être simple. En effet, comment connaître le statut d'un certificat ? C'est la qu'interviennent les listes de révocation (CRL, RFC 3280) mais aussi le protocole OCSP (RFC 2560).

1.2.1 Liste de révocation

Une CRL est en fait une liste publique qui content l'ensemble des certificats révoqués par une autorité de certification. Cette liste, signé par le CA et mise a jour périodiquement, contient les numéros de série des certificats qui ont été révoqués. Le certificat du CA doit être habilité à signer des CRL. Pour cela, il faut penser à rajouter cRLSign dans les keyUsage du certificat du CA (cf. configuration d'OpenSSL).

Ainsi, lorsqu'un client va récupérer la CRL, il va en premier lieu vérifier la signature de cette CRL, les dates de signature et de renouvellement de la CRL, puis importer les numéros de série des certificats révoqués. Ainsi, lors de l'utilisation d'un certificat, si celui-ci est présent dans cette liste, il sera considéré comme révoqué.

Mais comment savoir ou se trouve les CRL ? Et quand les mettre à jours ?
C'est pour cela que les dates de publication courante et future font partie de la CRL (Last Update, Next Update). Ce paramètre est utilisé par les clients (Firefox pour n'en citer qu'un) pour sa mise à jour automatique. De plus les certificats intègrent généralement une URI permettant de connaître l'emplacement pour récupérer une CRL récente (crlDistributionPoints). Le client doit donc télécharger régulièrement la CRL qui peux facilement peser plusieurs dixaines de mega octets au bout de quelques années. Ceci implique bien évidement de configurer votre client pour qu'il récupère ces mise a jour, or l'auto update est bien souvent désactivé par défaut. De plus le temps entre deux mise à jours n'est pas forcément acceptable (un mois par défaut dans OpenSSL).

1.2.2 Le protocole OCSP

Heureusement pour palier tous ces problèmes nous avons un protocole: OCSP (RFC 2560), malheureusement pas encore supporté pas tous. OCSP, késako ?
Comme indiqué sur le site d'OpenCA:
The OCSP Responder is an rfc2560 compliant OCSPD responder.
The purpose of such a server is to provide an on-line tool to verify the status of a certificate (such as Mozilla/Firefox/Netscape7).

Il s'agit en fait d'un protocole de vérification de certificats en ligne qui est une alternative aux listes de révocations. Celui-ci permet de vérifier si un certificat est révoqué, mais contrairement aux CRLs, le traitement s'effectue côté serveur. Il suffit donc que votre client contacte ce tiers et de lui fournisse le numéro de série du certificat à vérifier, le hash du nom de l'autorité signataire et le hash de la clé. Le serveur OCSP renverra une réponse signée qui contiendra le statut du certificat : good, revoked ou unknown.

Il est bien sur possible d'indiquer dans le certificat le serveur OCSP (OCSP Responder) à interroger pour valider celui-ci. Ceci ce fait dans la configuration d'OpenSSL:
authorityInfoAccess = OCSP;URI:http://ocsp.toto/

Cette extension est typiquement utilisée par Firefox pour vérifier de manière automatique la validité d'un certificat HTTPS.

Le serveur OCSP doit quant à lui présenter un certificat comportant l'extension OCSPSigning:
extendedKeyUsage = OCSPSigning


1.3. Solutions techniques existantes


Le monde du libre propose depuis quelques temps déja toutes les briques essentielles permettant la mise en place d'une PKI. On pourra citer: OpenSSL pour la génération de certificat, OpenLDAP pour le stockage des CRT et autres CRL mais également Apache et mod_ssl pour contrôler les accès à un serveur web. Il existe également des solutions intégrées permettant la mise en place de l'ensemble des éléments constituant une PKI. C'est le cas de la solution IDX-PKI maintenant appellé OpenTrust-PKI proposé par la SSLL française IDEALX. Malheureusement, l'accès au source n'est plus gratuit (réservé au C3I, club des clients contributeurs). Il y à bien sur d'autres solution tel que OpenCA qui est assez prometteur.

Le but ici n'est pas de faire une liste exhaustive ni d'utiliser ce genre de solution. Nous allons voir qu'il est possible d'obtenir une solution efficace à partir des briques de base que le libre met à notre disposition, moyennant quelques script maison :)
Pour cela nous allons utiliser les outils suivants:

2. Proposition d'architecture


L'architecture se décompose en éléments opérationnels. Ces éléments sont indépendants et ne nécessitent pas forcément une machine physique propre. Attention toutefois au risque de sécurité que cela peut entraîner.

Architecture de la PKI

Toutes ces entités permettent de prendre en charge le cycle de vie d'un certificat. A noter qu'ici l'autorité d'enregistrement (RA) est délégué sur le serveur ou l'interface web (génération du CSR) et sur le CA (Validation).

2.1 package pki-client


Ce package inclus la mise en place d'OpenSSL, d'Easy-RCA ainsi que la paire de clé permettant de se connecter en SSH sur le CA.
La copie du CSR se fait via SSH avec un compte particulier, ici pkicsr. Ceci permet de profiter des mécanisme de sécurité offert par SSH: authentification, chiffrement. N'ayant besoin que de copier des fichier, nous allons mettre en place SCPOnly sur le CA. SCPOnly permet d'avoir un shell modifié autorisant uniquement l'accès aux fichiers et d'interdire tous privilèges d'exécution.

Le mot package n'est pas annodin, nous vous conseillons fortement de packager toutes ces choses pour pouvoir envisager un déploiement sur plusieurs serveurs.

2.2 Interface Web


L'interface Web permet la création de certificats pour les utilisateurs. Cette interface aura exactement les mêmes taches que pki-client: générer une demande de certificat et la copier en SSH sur le CA.

2.1 package pki-server


La partie serveur contient également OpenSSL et Easy-RCA mais aussi "SCPOnly".

3. Mise en place


3.1 pki-server


OpenSSL

Pour installer OpenSSL (Debian) il suffit de faire:
# apt-get install openssl


Easy-RCA

Pour Easy-RCA, il faut récuperer le package OpenVPN. Les scripts se trouvent tous dans le répertoire openvpn-2.0.9/easy-rsa/2.0/:
$ wget http://openvpn.net/release/openvpn-2.0.9.tar.gz
$ tar zxvf openvpn-2.0.9.tar.gz 
$ cd  openvpn-2.0.9/easy-rsa/2.0/


Pour la configuration, il faudra aller voir du coté du fichier vars. Vérifiez que les différentes variables reflète bien votre installation.
La configuration se poursuit par le fichier openssl.cnf. Voici les déclarations pour mettre en place un certificat serveur, client et pour l'OCSP:

[ crl_dp ]
URI = ldap://ldaptest.infra.b2.p.fti.net/ou=ca,ou=pki,dc=fti,dc=net?certificateRevocationList;binary
[ server ]
nsComment                       = "Server certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, keyEncipherment
extendedKeyUsage                = serverAuth
nsCertType                      = server
authorityInfoAccess             = OCSP;URI:http://ldap
crlDistributionPoints= @crl_dp
[ client ]
nsComment                       = "Client certificate"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation, keyEncipherment
extendedKeyUsage                = clientAuth, emailProtection
authorityInfoAccess             = OCSP;URI:http://ldap
crlDistributionPoints= @crl_dp
[ v3_ca ]
basicConstraints                = critical,CA:true
keyUsage                        = critical,keyCertSign,cRLSign
authorityKeyIdentifier          = keyid,issuer:always
subjectKeyIdentifier            = hash
[ crl_ext ]
issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always
[ engine_section ]
[OCSP]
nsComment                       = "OCSP Responder"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
basicConstraints                = critical,CA:FALSE
extendedKeyUsage                = OCSPSigning


Il faut maintenant créer notre certificat racine pour le CA (--pass permet de mettre une pass phrase sur la clé privé):
$ source ./vars 
$ ./clean-all
$ ./pkitool --pass --initca


Ainsi que les listes de révocation (ARL signifie Authority Revocation List, cette liste de révocation serra nécessaire pour l'annuaire):
$ export KEY_CN=""
$ export KEY_OU=""
$ cd "$KEY_DIR"
$ $OPENSSL ca -gencrl -out crl.pem -config "$KEY_CONFIG"
$ $OPENSSL ca -gencrl -out arl.pem -config "$KEY_CONFIG"


SCPOnly

L'installation sur le CA est assez simple (Debian):
# apt-get install scponly


Nous allons créer le compte pkicsr:
# useradd -s /usr/bin/scponly -m pkicsr


Puis il vous faudra générer une paire de clé et mettre la clé publique dans le authorized_keys (/home/pkicsr/.ssh/authorized_keys).
ssh-keygen -t rsa -b 2048


Nous pouvons maintenant lancer un test de connexion sur notre CA en fournissant a SSH la clé privé du compte pkicsr:
$ scp -i clé_privé file pkicsr@machineCA:
test                                     100% 1273     1.2KB/s   00:00

$ ssh -i ma_clé_privé pkicsr@machineCA:
Linux machineCA 2.6.14.6-grsec #1 PREEMPT Wed Jul 12 14:42:24 CEST 2006 i686 GNU/Linux

WinSCP: this is end-of-file:0

On voit bien que la copie ne pose pas de problème. Par contre, il n'est pas possible d'obtenir un environnement permettant l'exécution de commandes.

3.2 Mise en place de l'annuaire


Nous n'allons pas rentrer dans les details de la mise en place d'un annuraire OpenLDAP qui dépasse le cadre de cette article. Nous allons créer une branche dédié à notre PKI: ou=pki,dc=organisation,dc=com
ou=pki,dc=organisation,dc=com
objectClass: organizationalUnit
objectClass: top
ou: pki


Dans cette branche nous allons avoir:

ou=ca,dc=organisation,dc=com
cn: pki-ca
description: Certificate Authority certificate and revocation list
objectClass: certificationAuthority
objectClass: applicationProcess
ou: ca
cACertificate;binary:: [...]
authorityRevocationList;binary:: [...]
certificateRevocationList;binary:: [...]

ou=hosts,ou=pki,dc=organisation,dc=com
objectClass: organizationalUnit
objectClass: top
ou: hosts

ou=users,ou=pki,dc=organisation,dc=com
objectClass: organizationalUnit
objectClass: top
ou: users


A noter que la classe certificationAuthority nécessite d'avoir un attribut authorityRevocationList qui correspond à une liste de révocation de certificat autorité.

Voici un exemble de fichier LDIF permettant d'importer ces données dans le LDAP:
dn: ou=ca,ou=pki,dc=organisation,dc=com
ou: ca
cn: pki-ca
description: Certificate Authority certificate and revocation list
cACertificate;binary:< file:///path/easy-rsa/2.0/keys/ca.der
certificateRevocationList;binary:< file:///path/easy-rsa/2.0/keys/crl.der
authorityRevocationList;binary:< file:///path/easy-rsa/2.0/keys/crl.der
objectClass: certificationAuthority
objectCLass: applicationProcess


Assurez vous que votre annuaire stocke correctement les entrées hosts et users. Voici à quoi ressemble de telles entrées:
cn=Julien Stankiewicz,ou=users,ou=pki,dc=organisation,dc=com
cn: Julien Stankiewicz
sn: Julien Stankiewicz
objectClass: inetOrgPerson
objectClass: top
objectClass: pkiUser
userCertificate;binary:: [...]

cn=servname.organisation.com,ou=hosts,ou=pki,dc=organisation,dc=com
cn: servname.organisation.com
ipHostNumber: 127.0.0.1
objectClass: ipHost
objectClass: device
objectClass: extensibleObject
userCertificate;binary:: [...]


3.3 Package pki-client


Ici il faudra, comme pour le package pki-server, installer OpenSSL et Easy-RCA.
Generation: ...
Copie: ....
Recuperation ...

3.4 Mise en place d'OCSP


Mise en place d'Openca-ocspd:
$ tar zxvf openca-ocspd-1.5.1-rc1.tar.gz
$ cd openca-ocspd-1.5.1-rc1
# apt-get install gcc libc6-dev make patch
# apt-get install libldap2 libldap2-dev libssl0.9.7 libssl-dev
$ ./configure --prefix=/usr/local/ocspd
$ make
# make install


Puis:
# vi /etc/passwd
ocspd:x:102:1:OCSP Server Account,,,:/usr/local/ocspd:/bin/false
# vi /etc/shadow
ocspd:!:13559:0:99999:7:::


Enfin la configuration a proprement parlé:
[ ocspd ]
default_ocspd   = OCSPD_default         # The default ocspd section
[ OCSPD_default ]
dir              = /usr/local/ocspd/etc/ocspd           # Where everything is kept
db               = $dir/index.txt               # database index file.
md               = sha1
ca_certificate    = $dir/certs/cacert.pem       # The CA certificate
ocspd_certificate = $dir/certs/ocspd_cert.pem   # The OCSP server cert
ocspd_key         = $dir/private/ocspd_key.pem  # The OCSP server key
pidfile           = $dir/ocspd.pid              # Main process pid
user                    = ocspd
group                   = daemon
bind                    = *
port                    = 80
max_req_size            = 8192
threads_num             = 150
max_timeout_secs        = 5
crl_auto_reload = 3600
crl_check_validity = 600
crl_reload_expired = yes
response        = ocsp_response 
dbms            = dbms_ldap
engine = HSM
[ ocsp_response ]
dir                     = /usr/local/ocspd/etc/ocspd
ocsp_add_response_certs = $dir/certs/chain_certs.pem
ocsp_add_response_keyid = yes
next_update_days        = 0
next_update_mins        = 5
[ dbms_ldap ]
0.ca = @ldap_ca_1
[ ldap_ca_1 ]
crl_url = ldap://ldap
crl_entry_dn = "ou=ca,ou=pki,dc=organisation,dc=com"
crl_entry_attribute = "certificateRevocationList;binary"
ca_url = ldap://ldap
ca_entry_dn = "ou=ca,ou=pki,dc=organisation,dc=com"
ca_entry_attribute = "cACertificate;binary"
[ dbms_file ]
0.ca = @first_ca
[ first_ca ]
crl_url = file:////usr/local/ocspd/etc/ocspd/crls/crl.pem
ca_url  = file:////usr/local/ocspd/etc/ocspd/certs/cacert.pem
[ second_ca ]
[ HSM ]
engine_id = LunaCA3
0.engine_pre = login:1:10:11:myPassword


Une fois la configuration faite, il vous faudra générer les certificat pour OCSP: ocspd_cert.pem et ocspd_key.pem. Pensez également à copier le certificat publique du CA (cacert.pem).

Pour tester, il vous suffit de le lancer via la commande suivante:

# /usr/local/ocspd/sbin/ocspd -c /usr/local/ocspd/etc/ocspd/ocspd.conf -v


Ceci devrais vous donner les entrés suivantes dans le syslog:
Apr  4 18:07:16 ldaptest ocspd[1608]: INFO::OPENCA_SRV_INFO_TREAD::new thread created
Apr  4 18:07:56 ldaptest ocspd[1761]: OpenCA OCSPD v1.5.1 - starting.
Apr  4 18:07:56 ldaptest ocspd[1761]: reading certificate file (/usr/local/ocspd/etc/ocspd/certs/ocspd_cert.pem).
Apr  4 18:07:56 ldaptest ocspd[1761]: Reading Private Key file /usr/local/ocspd/etc/ocspd/private/ocspd_key.pem
Apr  4 18:07:56 ldaptest ocspd[1761]: reading CA certificate file.
Apr  4 18:07:56 ldaptest ocspd[1761]: OCSP Daemon setup completed
Apr  4 18:07:56 ldaptest ocspd[1761]: variable lookup failed for OCSPD_default::chroot_dir
Apr  4 18:07:56 ldaptest ocspd[1761]: Auto CRL reload every 3600 secs
Apr  4 18:07:56 ldaptest ocspd[1761]: Reload on expired CRLs enabled
Apr  4 18:07:56 ldaptest ocspd[1761]: Number of CAs in configuration is 1
Apr  4 18:07:56 ldaptest ocspd[1761]: Using LDAP protocol for CA retrivial
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Connecting to LDAP (ldap)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Connection established (ldap)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Successfully binded to LDAP (ou=ca,ou=pki,dc=organisation,dc=com)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Search Successful
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Got 1 entries
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP:CA Cert is DER formatted
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Got CA cert from LDAP
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Successfully unbinded
Apr  4 18:07:56 ldaptest ocspd[1761]: CA CERT for ldap_ca_1 loaded successfully.
Apr  4 18:07:56 ldaptest ocspd[1761]: CA List Entry added (CA list num 0)
Apr  4 18:07:56 ldaptest ocspd[1761]: Using LDAP protocol for CRL retrivial
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::CRL RELOAD::LDAP Protocol
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Connecting to LDAP (ldap)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Connection established (ldap)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Successfully binded to LDAP (ou=ca,ou=pki,dc=organisation,dc=com)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Successfully binded (ou=ca,ou=pki,dc=organisation,dc=com)
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Search Successful
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Got [1] entries
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Got CRL ok.
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::LDAP::Successfully unbinded
Apr  4 18:07:56 ldaptest ocspd[1761]: CRL loaded [ ldap_ca_1 ]
Apr  4 18:07:56 ldaptest ocspd[1761]: CRL and CA cert [0:1] check ok
Apr  4 18:07:56 ldaptest ocspd[1761]: CRL matching CA cert ok [ 1 ]
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::CRL::Verify 1 [OK=1]
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::CRL is Valid
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::CRL::-1 Entries [ ldap_ca_1 ]
Apr  4 18:07:56 ldaptest ocspd[1761]: No Entries for CRL (@ldap_ca_1)
Apr  4 18:07:56 ldaptest ocspd[1761]: CRL loaded successfully [ldap_ca_1]
Apr  4 18:07:56 ldaptest ocspd[1761]: CRL validity check every 600 sec.
Apr  4 18:07:56 ldaptest ocspd[1761]: Configuration loaded and parsed
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::Local Address 0.0.0.0 [80]
Apr  4 18:07:56 ldaptest ocspd[1761]: INFO::OPENCA_SRV_INFO_TREAD::new thread created


4. Le cycle de génération d'un certificat


4.1 Génération et copie d'un CSR


Commençons par la génération d'une clé privée et d'un CSR. Ceci ce fait de deux manières différentes qu'il s'agisse d'un certificat pour un serveur ou pour une personne. En effet, les serveurs disposent d'un package pki-client permettant la création de CSR via un script :

$ pki-client "servname"              

****************
Creating CSR ...
****************
Generating a 1024 bit RSA private key
...........++++++
...........++++++
writing new private key to 'servname.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [Departement]:
Locality Name (eg, city) [Ville]:
Organization Name (eg, company) [Organisation]:
Organizational Unit Name (eg, section) [Service]:
Common Name (eg, your name or your server's hostname) [servname]:
Email Address [julien@organisation.com]:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

****************************
Uploading CSR to CA serv ...
****************************
servname.csr                                                                      100%  749     0.7KB/s   00:00    

An email should be sent to the email specified in the CSR. You should reveive an other email once the certificate will be availaible.


Ce package inclus:

Concernant les personnes, il est possible de créer une interface en PHP permettant d'avoir un fonctionnement similaire (cf. http://fr3.php.net/manual/fr/ref.openssl.php pour la génération des CSR). Dans la suite de l'article nous détaillerons l'utilisateur de la partie serveur via le package pki-client


4.2 Validation et Signature


Nous arrivons maintenant a la phase de vérification de l'identité de l'entité demandeuse et à la signature du CSR qui permettra d'obtenir le CRT qui serra publique. Pour nous simplifier la vie nous avons une crontab qui détecte l'arrivée de nouvelle demande. Un mail est envoyé à l'initiateur du CSR (l'email est extrait du CSR) l'informant que sa requête est en cours de traitement. Un second mail est envoyé à l'opérateur chargé de la validation. Cette personne à pour rôle de vérifier que les information fournis sont correcte et respecte bien les conventions de l'entreprise (la personne travaille bien chez nous ?).

L'operateur à le choix entre plusieurs scénario:
$ ./revoke-full "servname"
$ ./publish.sh --crl 


$./pkitool --interact --sign --server "servname"
$ ./publish.sh --server "servname"


4.3 Mise a disposition des certificats


La publication des CRT et CRL se fait via le script publish.sh. Celui-ci génére les fichier ldif a la volée et les publie via un appel a ldapmodify. Il envois également un mail au demandeur pour l'informer que le certificat est disponible.

4.4 Récupération des certificats par le demandeur


La récupération des assez simple, il suffit de relancer la commande:
 $ pki-client "servname" 
 CSR already generated, retreiving CRT ...
dn: cn=servname,ou=hosts,ou=pki,dc=organisation,dc=com
cn: servname
ipHostNumber: 127.0.0.1
objectClass: ipHost
objectClass: device
objectClass: extensibleObject
userCertificate;binary:: [...]


Le script va détecter qu'un CSR est présent mais qu'il manque le CRT. Il va alors essayer de le récupérer sur l'annuaire via un ldapsearch.

4.5 Vérification des certificats


La validation de certificats permet de renseigner n'importe quelle entité sur l'état de validité d'un certificat, et ce à tout moment. La révocation de certificats consiste à publier une CRL.
Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki
Page was generated in 0.1688 seconds