Niveau : 
Résumé :
Après avoir vu il y a longtemps comment créer le certificat d'une autorité de certification personnelle et comment l'installer là où c'est nécessaire, nous allons voir les méthodes pour gérer une autorité de certification.
Une fois l'autorité créée, l'activité principale d'une autorité est de signer des certificats. Et plutôt que de taper tous les paramètres à la main, il est plus simple de disposer d'une configuration, ce qu'openssl nous propose. De plus, openssl dispose d'une commande permettant une gestion simplifiée d'une autorité.
Passons en revue la configuration (reprise du fichier par défaut /etc/ssl/openssl.cnf). Parlons directement de la section gérant l'autorité elle-même :
# Section pour la commande ca
[ ca ]
# Autorité par défaut (pour en gérer plusieurs)
default_ca = Peck_authority
# Section spécifique à mon autorité
[ Peck_authority ]
# Tous les répertoires de base
dir = /srv/Authority # Where everything is kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file
Ensuite les options spécifiques :
# Mettre à no pour permettre à une entité de disposer de plusieurs certificats #unique_subject = no # Section contenant les extensions à utiliser x509_extensions = usr_cert # The extentions to add to the cert # Format d'affichage des données en ligne de commande name_opt = ca_default # Subject Name options cert_opt = ca_default # Certificate field options # Ne pas utiliser sauf à faire infiniment confiance aux demandeurs (ou tout vérifier à la main) # copy_extensions = copy # Durée de validité des certificats émis default_days = 365 # Fonction de hashage à utiliser (ne pas utiliser md5 :-) default_md = sha1 # Réécrire le DN passé par le demandeur preserve = no # Politique à utiliser pour la vérification de la demande policy = policy_match
Et maintenant les sous-sections.
La politique de vérification des demandes est simpliste, elle ne sert qu'à vérifier que la demande est valide, rien de plus. C'est à l'humain / le script / la PKI de vérifier que la demande est la bonne et que le demandeur est bien celui qu'il prétend.
# Liste des champs présents dans la demande et inclus dans le certificats (les autres seront supprimés). # match = doit être la même que cette de l'AC # supplied = obligatoire # optional = optionnel [ policy_match ] countryName = match stateOrProvinceName = match organizationName = supplied organizationalUnitName = optional commonName = supplied emailAddress = optional
Une sous-section pour définir les extensions des certificats générés :
[ usr_cert ] # Le certificat ne peut pas servir d'autorité basicConstraints=CA:FALSE # Usage autorisé du certificat (selon Netscape) # client, server, email, objsign, reserved, sslCA, emailCA, objCA nsCertType = client, email # Usage autorisé du certificat (selon PKIX) # digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly keyUsage = digitalSignature # Commentaire inclu dans le certificat nsComment = "Certificate from Peck" # Génération automatique de l'identifiant du certificat subjectKeyIdentifier=hash # Génération de l'identifiant de la clé de signature authorityKeyIdentifier=keyid,issuer # ...
Il existe une foultitude d'autres extensions, principalement les extensions définies par Netscape et celles définies par PKIX (groupe de travail sur le x509) dans le RFC 5280 (§4.2). PKIX dispose d'une liste d'extensions (id-pe) mais leur documentation doit être recherchée dans les divers documents du groupe de travail.
Ces extensions sont à utiliser lorsque vous avez des besoins spécifiques à une application. Notez qu'une extension peut toujours être préfixée de "critical" qui indique à l'utilisateur du certificat qu'il doit le refuser s'il ne comprend pas le sens de l'extension en question (sinon elle est ignorée). Faites attention, l'usage de critical peut se retourner contre vous.
Une fois la configuration prête, créez votre autorité :
$ mkdir /srv/Authority $ cd /srv/Authority $ mkdir newcerts private $ echo "00" > serial $ touch index.txt
Placez-y votre certificat d'autorité et sa clé :
$ cp ca.crt /srv/Authority/cacert.pem $ cp ca.key /srv/Authority/private/cakey.pem
Et voila, votre autorité est prête à être utilisée. Pour exemple, comme d'hab le client crée une demande de certificat :
# Il se débrouille pour générer une requête au bon format avec l'outil qu'il veut $ openssl req -new
Et vous le signez après en avoir vérifié le contenu et l'auteur :
# Lecture de la demande $ openssl req -in client.csr -text #Signature de la demande $ openssl ca -config openssl.cnf -in client.csr
Et le certificat signé à renvoyer au client est dans le répertoire newcerts sous le nom <serial>.pem
Vous verrez que des sauvegardes de fichier sont conservées pour permettre d'annuler la dernière opération.
Loading ...