Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Archives pour avril, 2009

C'est le week-end, je fatigue un peu. Parlons donc de sujets réjouissants : les trolls.

Sur internet on trouve de nombreux forums, des salons de discussions, des sites ou tout le monde peut participer ... Autant d'endroits ayant potentiellement un public nombreux et varié. C'est le terreau idéal pour faire pousser un troll.

Petite recette pour un troll réussi :

  • choisissez un site participatif ayant une forte audience pour maximiser la portée et les réactions potentielles (forum ubuntu)
  • choisissez un sujet n'ayant pas été universellement détecté comme nid à troll pour lui donner de bonnes racines (faut-il parler de culture pub sur linuxfr)
  • mettez bien en évidence qu'il n'y a pas de contradiction possible à vos affirmations (tout le monde est d'accord pour dire que...)
  • ne lancez pas votre troll dans le vide, répondez à quelqu'un de façon à ce qu'au moins une personne se sente visée et cherche à y répondre (votre commentaire n'a aucun intérêt)
  • utilisez quelques mots agressifs ou dénigrant envers une personne ou une communauté pour augmenter le potentiel de réaction (le niveau des auteurs laisse à désirer)
  • posez une question aussi sérieuse que possible pour augmenter encore plus les chances d'obtenir une réponse qui sera nécessairement agrémentée de nourriture pour troll (sait-on à quel point la technique du double nat est utilisée)

Techniques pour agrémenter un troll et allonger sa durée de vie :

  • utilisez des questions non techniques sous couvert technique (emacs vs vi Combien de doigts ?)
  • une petite dose de mauvaise foi peut être appréciable, mais n'en abusez pas, cela peut arrêter les réponses (vous voulez vraiment tuer tous les bébés phoques ?)
  • au delà d'une taille critique, un troll peut être détecté mais continuer à grossir, n'hésitez plus à utiliser de grosses ficelles (... de la part d'un pédo pornographe comme vous ...)

Niveau : Star Star Empty Empty Empty
Résumé : moreutils ; ts ; vidir ; mispipe ; isutf8 ; lckdo ; vipe ; ifdata ; pee

Ces commandes sont dans le paquet moreutils sur debian.

Ajouter un timestamp sur chaque ligne pour lire une commande un peu lente :

$ ./commande | ts | tail

Éditer en masse les entrées d'un répertoire (pour renommer des images par exemple) :

# Tout le répertoire
$ vidir repertoire
# Seulement les images 
$ vidir *.jpg

Retourner le code d'erreur du premier élément d'un pipe et non du dernier (très utile en scripting) :

# Retourne une erreur si $dir n'existe pas
$ mispipe "ls $dir" "tail"

Vérifier qu'un fichier utf8 est valide :

$ isutf8 fichier && echo OK || echo "Not OK" 

Ne pas écraser un fichier de destination avant la fin de la commande :

# Version fonctionnelle de cat a b > a
$ cat a b | sponge a

Créer un script de type cron avec un lock sans effort :

$ lckdo -W 10 /var/lock/mylock /usr/local/bin/myscript

Éditer le contenu d'un pipe (très pratique pour le debug de script) :

$ commande1 | vipe | commande2

Éviter les envois de mail de rapport lorsqu'il n'y a rien à rapporter :

$ /usr/local/bin/rapport.pl | ifne mail -s "Synchro en retard" sysadmins@mynnet.net

Permettre (optionnelle ment) de passer des fichiers compressés en argument à un script (comme pour zless) :

# Recoder zless
$ zrun less $1

Éviter de parser le résultat de ifconfig ou de ip dans un script (nombreuses options, de sortie, lire le man) :

# Afficher le nombre d'octets reçus
$ ifdata -sib eth0

Passer le résultat d'une commande à plusieurs autres

# Attention si commande1 et commande2 produit du texte, rien ne garantit leur ordre
$ commande | pee "commande1" "commande2"

Comparer ligne par ligne deux fichiers avec des opérateurs plus évolués que comm :

$ combine fichier1 xor fichier2

Niveau : Star Star Empty Empty Empty
Résumé : cd && git init ; cd /etc && git init

Maintenant que vous avez étudié git, voyons à quoi il peut servir.

Configuration

Git peut, entre autre, fonctionner en local, comme RCS. Git est plus intéressant que d'autres outils comme svn pour plusieurs raison :

  • Il stocke tout en local à la racine du répertoire de travail
  • Il n'éparpille pas de fichiers un peu partout
  • Il prend 2 à 3 fois moins de place que svn pour des petits fichiers comme les fichiers de configuration
  • Il est un ordre de grandeur plus rapide que svn (ce qui importe peu pour /etc)

Notez que mercurial répond aussi à ces besoins.

Git est donc parfaitement adapté à votre configuration qui se trouve dans /etc :

# En root
$ cd /etc
$ git init

J'ai commencé par faire un "git add *" mais en pratique ce n'est pas une très bonne idée car on récupère tout et n'importe quoi et à moins de ne pas avoir de backup, ce n'est pas très utile. En effet cela entre en conflit avec les gestionnaires de paquet et gestionnaire s de configuration et c'est assez gênant lors des migrations. Une bonne utilisation est plutôt de faire un "git add" uniquement pour les logiciels dont on modifie la configuration. Ainsi, vous avez dans votre dépôt toutes vos modifications et uniquement vos modifications. Cela nécessite de s'imposer de faire les "git add" mais c'est plus simple.

D'autre part, rien ne vous empêche d'avoir un cron de commit automatique pour rattraper les cas où vous oubliez de le faire.

# Autocommit une fois par semaine, s'il n'y a rien à commiter, il ne fera rien
0 0 * * 1 cd /etc && git commit -a -m "Autocommit by cron"

Le jour où vous avez un problème de configuration :

# On cherche ce qui a changé depuis le dernier commit (fonctionnel ?)
$ git diff
# On cherche quand ça a changé avant
$ git log
# On cherche ce qui a changé avant
$ git diff ee9eac2a4deb43e7c73b50444fcb7269f172fb69

Ma configuration

Mieux, j'utilise maintenant git pour mon home :

$ cd 
$ git init

Pour le coup, on ne met vraiment que ce qu'on modifie, au coup par coup. Pour savoir quoi y mettre, commencez par lister tout ce qui commence par un point :

$ ls -ad .*

A vous de savoir ce que vous voulez y mettre sachant que ça sera transféré sur toutes vos machines. Exemples :

  • .bashrc et les .bash_*
  • .irssi
  • .vimrc
  • .ssh
  • .gnupg

Et du coup, il devient facile de se "téléporter". Dès que j'obtiens un compte sur une nouvelle machine, j'y emporte toute ma configuration. C'est assez simple (avec toutes les options) :

# Avec un git récent et une connexion bidirectionnelle
$ ssh peck@machine2.net
$ git clone ssh://peck@machine1.net/~peck/.git .

# Si la communication retour ne fonctionne pas directement
$ ssh -R 1022:localhost:22 peck@machine2.net
$ git clone ssh://peck@machine1.net:1022/~peck/.git .

# Si git se plaint de ne pouvoir créer le répertoire de destination
$ ssh peck@machine2.net
$ git clone ssh://peck@machine1.net/~peck/.git temporary
$ mv temporary/* .
$ rmdir temporary

De par le côté décentralisé de git, vous pouvez faire les modification où bon vous semble et les propager au fur et à mesure de votre usage. Voyons cela !

Ne pas oublier de de commiter

Pour les gérer les oublis, Vous avez le choix entre un autocommit régulier (voir plus haut) et un warning automatique à chaque connexion

# dans mon .bashrc
$ git status | grep modified
Vérifier les mises à jour à chaque connexion

A chaque nouvelle connexion faites un git pull, cela vous mettra à jour les données en provenance de la machine parente. Vous avez ainsi une synchronisation quasi automatique de vos répertoires personnels entre vos comptes.

# je le mets dans mon .bashrc mais c'est assez lourd si vous n'avez pas de clé ssh
$ git pull
Pousser une mise à jour vers le parent

Lorsque vous faites une modification sur un machine qui n'est pas la source (celle pour laquelle vous n'avez pas fait de git clone), il est appréciable de faire un git push pour propager les choses dans l'autre sens. Un inconvénient toutefois, c'est un lourd difficile à faire. Le plus simple est de récupérer les données depuis la source, mais ce n'est pas toujours facile à faire, cela peut nécessiter plusieurs tunnels.

# Sur la machine du changement 
$ git commit -a
# Sur la source
$ git pull ssh://peck@machine1.net/home/peck/.git

Niveau : Star Star Star Empty Empty
Résumé : git

Git est un système de suivi de version. Git est beau, git est simple, git a été fait par Linus Torvalds.

Tout seul

Dans une utilisation de premier niveau, git peut fonctionner comme RCS, c'est-à-dire en local.

Créons un dépôt local dans le répertoire que nous voulons versioniser :

$ git init

Fini !

Ajoutons un fichier au suivi des versions :

# add est récursif par défaut
$ git add monfichier
$ git commit -a

Bon je pense que vous avez compris, donc je vous la fais courte. Pour avoir la documentation d'une commande il suffit d'ajouter un tiret après git. Exemple le manuel de "git add" est dans "man git-add" ou dans "git add --help". Voyons les commandes de base utilisées le plus fréquemment, vous y reconnaîtrez celles qu'on trouve dans la plupart des systèmes de suivi de version (CVS, RCS, SVN ...) :

  • git add : Ajouter un fichier au suivi de version
  • git commit : Valider les modifications
  • git log : Pour voir les modification récentes
  • git diff : Voir ce qui a changé pour un fichier depuis une certaine version
  • git revert : Annule une unique modification (il est possible d'annuler une modification passée sans annuler tout depuis ce moment)
  • git status : Savoir tout ce qui n'a pas encore été validé

Vous remarquerez que git utilise des sommes sha1 pour identifier les différentes versions. Cela permet d'être universel et de ne pas avoir de problème de collision. Il vous faudra juste un peu de temps pour vous adapter à lire les logs avec des numéros aussi longs et non incrémentaux.

A plusieurs

Ensuite, un autre intérêt du suivi de version est aussi de travailler à plusieurs. Git est un système de version distribué, ce qui veut dire qu'il n'y a pas de dépôt centralisé qui fait autorité. Il y a autant de dépôt que de personne créant un dépôt et chacun peut aller piocher dans un ou plusieurs dépôts de ses voisins. C'est un peu anarchique, mais ça correspond bien au développement opensource. Et si vous voulez un dépôt d'autorité, vous pouvez toujours créer un dépôt que déclarez comme l'unique dépôt officiel et tout le monde doit se synchroniser dessus.

Un autre avantage de ce système est que chacun peut avoir ses propres commit fréquents pour suivre ce qu'il fait, et aggréger tous ces commits en une seule fois lorsque ce qu'il a fait fonctionne vraiment pour le valider sur un dépôt commun.

Voyons les commandes utiles :

  • git clone : Créer un nouveau dépôt de travail basé sur un autre dépôt (public pour le partage)
  • git pull : Récupère les nouveautés sur un dépôt parent
  • git push : Déposer ses modifications sur un autre dépôt (public pour le partage)

Tags et branches

Bien sûr, comme dans tout bon système de suivi de version, git gère les tags et les branches.

  • git branch : Pour gérer les branches
  • git checkout : Change la branche de travail
  • git show-branch : Affiche la branche en cours
  • git merge : Pour merger des branches
  • git tag : Gère les tags

Fin

Bien sûr je n'ai pas tout dit. Il existe plus de 100 commandes git, à vous de les découvrir si vous en avez besoin. Pensez à des choses bien sympathiques comme :

  • git bisect : Parcourir tous les changements (avec recompilation et exécution si besoin) à la recherche de la source d'un problème (par recherche binaire)
  • git rebase : Change le dépôt parent permettant de calculer les patchs
  • git format-patch : Formate un mail pour envoyer un patch
  • git am : Applique des patch directement en lisant une boîte mail

Et que dire des extensions comme git-svn qui permettent de s'interfacer avec la plupart des projets existant développés avec d'autres systèmes de suivi de version (ou ceux qui veulent utiliser git dans une entrprise qui ne jure que par svn).

Vous trouverez un peu plus de documentation sur l'usage courant de git sur http://www.kernel.org/pub/software/.... Une fiche de travail sur http://jonas.nitro.dk/git/quick-ref... et une fiche bien plus détaillée sur http://cheat.errtheblog.com/s/git

Commencez à vous y mettre, vous verrez que c'est rapidement pratique. D'ailleurs dès le prochain article je vais commencer des choses intéressantes avec git.

Niveau : Star Star Star Empty Empty
Résumé : ps ; top ; htop ; atop ;

Suite à un article sur les processus, j'ai trouvé une excellente série d'article vous permettant de découvrir le fonctionnement interne du noyau sur les processus et la mémoire :

Maintenant, essayons de résumer la gestion des processus d'un point de vue utilisateur et développeur.

Naissance, vie et mort d'un processus

Un processus est créé lorsque l'appel système fork est appelé et seulement dans ce cas. Les autres méthodes possibles se basent toutes sur fork (et clone, mais il ne faut pas le dire). Fork ne fait qu'une chose (et il le fait bien), il duplique un processus existant, entièrement, à l'identique, y compris ses droits.

Ensuite, durant sa vie un processus peut être modifié de nombreuses façons :

  • Changement d'utilisateur
  • Changement de code
  • Changement de père
  • Changement de priorité
  • etc.

Enfin un processus meurt dans 2 cas :

  • Il se termine tout seul comme un grand (appel système exit)
  • Il reçoit un signal qui lui est fatal

Informations sur un processus

Informations générales

Pour récupérer des informations sur un processus vous disposez de plusieurs commandes. Ces commandes ou toutes pour source /proc/<pid> qui est un répertoire virtuel peuplé directement par le noyau.

Les commandes les plus courantes sont :

  • ps : liste des processus et de leurs caractéristiques
  • htop : liste dynamique des processus et de ce qu'ils consomment
  • pgrep : récupération d'une liste de processus par expression régulière
  • pidof : récupération du pid d'un processus recherché
  • fuser : informations sur les file descriptor d'un processus
  • lsof : idem
  • pmap : afficher le mapping mémoire d'un processus
Données sur l'activité

Un processus a une activité somme toute limitée, c'est pourquoi il est parfaitement faisable de tout tracer. Le plus évident est de tracer les appels système, mais cela ne révèle que ses interactions avec le reste du monde. Il est aussi possible de tracer les appels de fonctions voire chacune des instructions.

  • strace : liste les appels système du processus
  • ltrace : liste les appels de fonction de bibliothèques dynamiques (.so) du processus
  • pstack : affiche la pile d'appel du processus
  • gdb : avec gdb on peut tout savoir et même modifier l'action d'un processus. gdb utilise l'appel système ptrace pour cela.

Agir sur un processus

Les actions sur un processus peuvent être effectuées par plusieurs entités :

  • Le processus lui -même
  • Le processus père du processus
  • Un autre processus ayant les droits pour effectuer une action (c'est-à-dire même propriétaire ou root ... en l'absence de patch sur le noyau)

Les actions qu'on peut effectuer sur un processus sont toutes liées à un appel système. En général il existe une commande shell fournissant une fonctionnalité équivalente.

Envoi d'un signal

Les signaux permettent de communiquer de façon basique avec un processus. Il peuvent être envoyé par un autre processus ou par le noyau. man 1 kill vous indique la liste des signaux et l'action par défaut associée pour les processus qui ne les surchargent pas.

Pour envoyer un signal à un processus il existe plusieurs commandes (qui utilisent toutes l'appel système kill) :

  • kill : envoyer un signal à un processus connaissant son pid
  • killall : envoie un signal à tous les processus portant un certain nom
  • pkill : envoie un signal aux processus matchant une expression régulière
  • ctrl-z : envoie le signal STOP au processus en avant plan du shell en cours
  • fg, bg : envoie le signal CONT à un processus stoppé du shell en cours
Répartir les tâches

Les processus peuvent être plus ou moins consommateurs de ressource processeur. La partie du noyau nommée ordonnanceur (scheduler) s'occupe d'allouer ces ressources aux différents processus.

Pour influencer l'activité de l'ordonnanceur, il existe plusieurs méthodes. Tout d'abord chaque processus dispose d'une priorité, le niveau de nice. Pour altérer son propre niveau, il y a l'appel système nice qui a donné la commande nice. Pour altérer celui d'un autre processus il y a l'appel système setpriority qui a donné la commande renice.

L'ordonnanceur a la charge de répartir l'activité de plusieurs processus, de plus en plus souvent entre plusieurs processeurs. Il est possible d'influencer la répartition des processus entre processeurs avec la commande taskset (utilisant l'appel système sched_setaffinity). Cette commande permet de limiter un processus à un ou plusieurs processeurs donnés.

Il existe aussi avec CFS, un moyen de contrôler finement le temps alloué à chaque processus à travers /sys/kernel/uids ou à travers les cgroups (voir Documentation/scheduler/sched-design-CFS.txt).

De plus il existe dans le noyau un deuxième ordonnanceur qui, cette fois, organise les tâches d'accès au disque. Si c'est le CFQ qui a été choisi (car il est modifiable), il est possible de l'influencer. Le grand intérêt de ceci est de limiter les processus qui pourraient phagocyter les autres en faisant énormément d'accès disque (pensez aux backups). L'appel système ioprio_set est implémenté dans la commande ionice pour gérer cette fonctionnalité. Lisez Documentation/block/ioprio.txt pour plus de détails.

Gestion des droits

Il n'est pas possible de changer les droits d'un processus de l'extérieur. Seul lui-même en est capable. Mais le mécanisme standard d'héritage lors du fork et de changement de droits lors de l'exec permet de faire tout ce qu'on veut.

Il n'existe qu'un seul cas où les droits peuvent être augmentés (en supposant l'absence de patch de sécurité spécifique) : lancer la commande exec sur un fichier disposant du bit suid (et éventuellement de capabilities).

Ensuite pour réduire ses droits, le processus peut utiliser :

  • L'appel système chroot qui a donné la commande chroot
  • L'appel système setXXuid qui est utilisé dans pam (commande login par exemple)
  • Les capabilities à travers l'appel système setcap qui permet de limiter la liste des appels systèmes disponibles pour un processus (ceci est une option du noyau)
Devenir indépendant

Un processus reçoit des signaux mortels lorsque son tty est coupé. C'est pourquoi un processus peut vouloir obtenir son indépendance.

Il appelle alors l'appel système setsid qui le détache de son terminal. De plus il crée un nouveau groupe de processus pour lui et ses fils, ce qui en pratique le détache de son père (lequel ne pourra donc plus le tuer lorsqu'il mourra).

La commande setsid fait la même chose en ligne de commande.

Limitations

Il est possible d'imposer des limitations à un processus ainsi qu'à ses fils, il existe un appel système pour cela nommée setrlimit. Bash propose une implémentation en ligne de commande pour cet appel nommée ulimit.

Les limitations incluent des limitations en nombre de fichiers ouverts, en consommation CPU, en occupation mémoire ... vous trouverez les détails dans le manuel de bash à la commande ulimit.

IPC et mémoire partagée

Une ancienne méthode chamanique utilisée pour communiquer entre processus est constituée des IPC (inter process communication). Les ipc permettent à des processus de :

  • s'envoyer des messages (appels système msgXXX)
  • poser des sémaphores, une technique de lock pour l'accès à des données (appels systèmes semXXX)
  • partager de la mémoire (appels système shmXXX)

Ces 3 catégories de méthodes génèrent des données qui sont indépendantes des processus de par le fait qu'elle sont destinées à d'autres processus. C'est pourquoi lorsqu'un processus utilisant des ipc plante, il laisse des traces dans le système. Ces traces consomment de la mémoire inutilement et parfois bloquent d'autres processus.

C'est pourquoi les commandes ipcs et ipcrm permettent de manipuler ces données de façon extérieures. Pensez à lire le manuel, c'est très court et vous pourrez en profiter pour monitorer les données en question.

Communication avec le processus

Enfin, un processus est isolé et communique avec le reste du monde de très peu de façons différentes :

  • avec des file descriptor (réseau, fichier, pipe, tty, device ...)
  • à travers la mémoire partagée et les IPC
  • avec des signaux
  • par la ligne de commande (en lecture seule)
  • et avec quelques appels système ayant une action sur le système lui-même

Niveau : Star Star Star Star Empty
Résumé : openssl

Vérification

Maintenant que nous avons des certificats propres et bien signés il va falloir les vérifier. Mais il ne s'agit pas simplement de vérifier que le certificat est valide et signé par une autorité de confiance. Tout d'abord, il fautde vérifier toute sa chaine de confiance. Ensuite il faut vérifier ses extensions, par exemple s'il va être utilisé pour les usages auxquels on l'a prévu.

Openssl permet de faire la vérification de la chaine de certification ainsi que la vérification de l'usage. Pour cela il faut installer l'autorité de confiance :

# On trouve le hash du certificat de l'AC
$ hash=$(openssl x509 -hash -noout -in cacert.pem)
# On installe l'AC en utilisant ce hash (il faut être root ici)
$ cp cacert.pem /etc/ssl/certs/$hash.0

Du coup la vérification d'un certificat se fait simplement :

$ openssl verify -purpose sslclient certificat.crt

Pour la vérification des extensions, il faut voir au cas par cas.

Mais contrairement à ce qu'on pense souvent, ce n'est pas tout. Il faut aussi vérifier que le certificat n'est pas révoqué, c'est-à-dire invalidé avant la date limite.

Révocation

La révocation d'un certificat se fait dans plusieurs cas :

  • perte de la clé
  • départ du propriétaire de la clé
  • renouvellement de la clé
  • ...

En gros à chaque fois qu'on veut garantir que la clé ne sera plus utilisée.

Pour révoquer un certificat alors qu'on a installé une AC openssl comme dans l'article précédent :

# On en profite pour indiquer pourquoi on le révoque
# les raisons possibles sont : unspecified, keyCompromise, CACompromise,
#   affiliationChanged, superseded, cessationOfOperation, certificateHold or removeFromCRL
$ openssl ca -config openssl.cnf -revoke client.cert -crl_reason keyCompromise

Il existe 2 mécanismes pour faire savoir au monde qu'on a révoqué un certificat : les CRL et le protocole OCSP.

Certificate Revocation List

Une liste de révocation est une liste complète de certificats révoqués qu'on télécharge. On compare ensuite le certificat à vérifier à cette liste pour savoir si le certificat n'a pas été révoqué.

Cette liste est signée par l'autorité de certification pour garantir qu'elle est valide. Au passage elle est aussi datée. Avec openssl elle se gère de la même façon que l'autorité de certification, avec le même fichier de configuration. Reprenons le fichier de configuration de l'AC et ajoutons-y les spécificités des CRL.

[ Peck_authority ]
# Numéro de série pour les CRL
crlnumber       = $dir/crlnumber

# Durée au dela de laquelle la CRL doit être mise à jour
default_crl_days= 30

# Ajouter des extensions à la CRL
crl_extensions        = crl_ext

[ crl_ext ]

# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always

On stocke les identifiants de crl :

$ echo "00" > ./peckCA/crlnumber

Après avoir révoqué un certificat (voir plus haut) générons la CRL :

$ openssl ca -config openssl.cnf -gencrl -out crl.list

Lisons le contenu de cette liste pour vérifier :

$ openssl crl -in crl.list -text

On peut ensuite vérifier que le certificat est révoqué ou non avec openssl en disposant de la CRL :

# Option non documentée
$ openssl verify -CAfile crl.list -crl_check client.cert

Pour le faire automatiquement, il faut installer la CRL de la même façon qu'on a installé le certificat de l'AC :

# Notez l'usage de r0 à la place de 0
$ hash=$(openssl x509 -hash -noout -in crl.list)
$ cp crl.list /etc/ssl/certs/$hash.r0
# Et on vérifie la révocation en même temps que la validité
$ openssl verify -crl_check client.cert

Pour ne pas devoir mettre à jour les CRL à la main chez tous les clients, il faut la publier. Pour cela, il faut d'abord la convertir, en effet, les clients traditionnels comme firefox lisent la version DER (binaire) et non PEM (ascii).

$ openssl crl -inform PEM -in crl.list -outform DER -out crl.der
# puis placez-la sur votre serveur

Et pour que le client sache où aller chercher cette CRL, il faut l'indiquer dans le certificat lorsqu'on le signe :

# Dans la openssl.cnf, utilisé lors de la signature de demandes
[ usr_cert ]

# Les url en http et en ldap sont autorisées
crlDistributionPoints           = URI:http://localhost/ca-crl.pem

Malheureusement, openssl ne sait pas aller chercher tout seul la crl pour faire cette vérification.

Enfin notez qu'il existe aussi des extensions deltaCRLindicator et FreshestCRL qui permettent de ne pas télécharger toute la CRL à chaque fois. Mais elles ne sont pas supportées par openssl.

Online Certificate Status Protocol

Le problème des CRL est qu'il nécessite un téléchargement plus ou moins lourd pour faire une seule vérification. C'est tout aussi pénalisant pour l'AC que pour le client. C'est pourquoi un protocole a été inventé pour permettre de faire une vérification au cas par cas.

Il permet de vérifier si un unique certificat est révoqué. Il a aussi l'avantage de ne pas dépendre de la date de validité des CRL qui sont générées et rechargées sur des périodes plus ou moins longues. Ici on a directement la bonne information.

Lançon un serveur OCSP sur notre AC fraîchement créée. Pour faire rapide nous utilisons le certificat de l'AC pour lancer le service, mais pour faire propre, nous aurions du lui créer un certificat spécifique signé par l'AC et ayant l'extension "extendedKeyUsage=OCSPSigning" :

# Il n'y a pas de port par défaut pour OCSP
$ openssl ocsp -index /srv/Authority/index.txt -CA /srv/Authority/cacert.pem -rsigner /srv/Authority/cacert.pem -rkey /srv/Authority/private/cakey.pem -port 1234

Vérifions ensuite si un certificat est révoqué. Notez qu'il est nécessaire de préciser le certificat ayant signé celui qu'on veut vérifier :

# Attention, précisez -issuer avant -cert
# Il est possible de vérifier plusieurs certificats d'un coup avec plusieurs -cert
$ openssl ocsp -host localhost:1234 -issuer /srv/Authority/cacert.pem -cert certificat.crt

Tout comme pour les CRL, il est possible d'indiquer dans le certificat l'endroit où se trouve le serveur OCSP permettant de vérifier la révocation. Les application qui supportent (pas openssl verifiy) l'extension vont alors automatiquement la vérifier :

# Dans la openssl.cnf, utilisé lors de la signature de demandes
[ usr_cert ]

authorityInfoAccess = OCSP;URI:http://ocsp.my.host/