échanges, les antivirus, etc. Par ailleurs, les équipes d’intégration générant les
certificats pour les serveurs web ne sont pas les mêmes que celles pour l’antivirus, etc.
On voit clairement que les certificats sont générés par des équipes très variées : ceux
des systèmes d’intermédiation par les équipes d’architectes, ceux des antivirus par la
production, ceux du VPN par l’équipe du RSSI… Nous sommes donc en présence
d’une gestion extrêmement décentralisée, sans aucune coordination ni vue
d’ensemble, ce qui ne contribue nullement à l’efficacité. En somme, personne ne sait
précisément dire combien d’environnements utilisent des certificats, ni pour quel
usage ni à quelle période de renouvellement.
Facteurs aggravants
Au vu de ce qui vient d’être exposé, on pourrait légitimement conclure que lorsqu’un
certificat expire, il suffit de le régénérer. En principe, cela ne prend techniquement que
quelques minutes. Malheureusement, l’expérience montre que le renouvellement d’un
certificat peut s’avérer un véritable cauchemar.
Il faut distinguer ici deux cas : d’une part, celui des équipes qui génèrent leurs certificats
elles-mêmes en interne et, d’autre part, celui des organismes qui préfèrent sous-traiter
cette activité à des organismes spécialisés.
Quels sont les problèmes qui se posent à ceux qui génèrent eux-mêmes leurs certificats ?
Le premier grand problème est que la génération d’un certificat n’est pas triviale. Trop
souvent, la personne (ou l’équipe) ayant initialement installé les certificats a été mutée ou
a quitté son poste depuis longtemps le jour du renouvellement. De plus, les certificats
sont générés de façon artisanale, si bien qu’il est extrêmement rare de trouver un mode
opératoire décrivant précisément comment procéder. Pire, quand la documentation existe,
tout le monde en ignore la localisation, voire l’existence. Ainsi, une opération qui en
principe ne devrait prendre que quelques minutes peut s’étendre sur une durée de
plusieurs jours, le temps de trouver une personne compétente et sachant quels paramètres
positionner dans le certificat.
Un second problème réside dans la complexité technique. En effet, même une personne
sachant utiliser les outils de PKI aura le plus grand mal à choisir les bons paramètres. Les
paramètres très souvent problématiques sont les champs Key Usage et Extended Key
Usage. Ces champs précisent quel usage sera fait du certificat. Par exemple, on peut
vouloir un certificat pour authentifier un serveur ou un client, ou pour faire de la
signature, etc. Les usages sont très variés. Aussi, si les champs Key Usage ou Extended
Key Usage d’un certificat indiquent que ce dernier a pour vocation d’authentifier un
serveur, alors que le but est d’authentifier un client, le certificat sera rejeté par le serveur.
En principe, il suffit de connaître la finalité du certificat pour renseigner correctement ces
champs. Pourtant, la réalité est tout autre, car l’interprétation des bits des champs Key
Usage et Extended Key Usage dépendent beaucoup des logiciels qui vont s’en servir.
Aussi, la seule logique ne suffit pas, les implémentations ont leur propre interprétation.
En somme, il ne s’agit pas seulement de positionner le champ Key Usage à Server
Authentication pour que le certificat permette d’authentifier un serveur. Il faut aussi
vérifier que les logiciels implémentés côté client et côté serveur s’entendent sur le sens à
certificats pour les serveurs web ne sont pas les mêmes que celles pour l’antivirus, etc.
On voit clairement que les certificats sont générés par des équipes très variées : ceux
des systèmes d’intermédiation par les équipes d’architectes, ceux des antivirus par la
production, ceux du VPN par l’équipe du RSSI… Nous sommes donc en présence
d’une gestion extrêmement décentralisée, sans aucune coordination ni vue
d’ensemble, ce qui ne contribue nullement à l’efficacité. En somme, personne ne sait
précisément dire combien d’environnements utilisent des certificats, ni pour quel
usage ni à quelle période de renouvellement.
Facteurs aggravants
Au vu de ce qui vient d’être exposé, on pourrait légitimement conclure que lorsqu’un
certificat expire, il suffit de le régénérer. En principe, cela ne prend techniquement que
quelques minutes. Malheureusement, l’expérience montre que le renouvellement d’un
certificat peut s’avérer un véritable cauchemar.
Il faut distinguer ici deux cas : d’une part, celui des équipes qui génèrent leurs certificats
elles-mêmes en interne et, d’autre part, celui des organismes qui préfèrent sous-traiter
cette activité à des organismes spécialisés.
Quels sont les problèmes qui se posent à ceux qui génèrent eux-mêmes leurs certificats ?
Le premier grand problème est que la génération d’un certificat n’est pas triviale. Trop
souvent, la personne (ou l’équipe) ayant initialement installé les certificats a été mutée ou
a quitté son poste depuis longtemps le jour du renouvellement. De plus, les certificats
sont générés de façon artisanale, si bien qu’il est extrêmement rare de trouver un mode
opératoire décrivant précisément comment procéder. Pire, quand la documentation existe,
tout le monde en ignore la localisation, voire l’existence. Ainsi, une opération qui en
principe ne devrait prendre que quelques minutes peut s’étendre sur une durée de
plusieurs jours, le temps de trouver une personne compétente et sachant quels paramètres
positionner dans le certificat.
Un second problème réside dans la complexité technique. En effet, même une personne
sachant utiliser les outils de PKI aura le plus grand mal à choisir les bons paramètres. Les
paramètres très souvent problématiques sont les champs Key Usage et Extended Key
Usage. Ces champs précisent quel usage sera fait du certificat. Par exemple, on peut
vouloir un certificat pour authentifier un serveur ou un client, ou pour faire de la
signature, etc. Les usages sont très variés. Aussi, si les champs Key Usage ou Extended
Key Usage d’un certificat indiquent que ce dernier a pour vocation d’authentifier un
serveur, alors que le but est d’authentifier un client, le certificat sera rejeté par le serveur.
En principe, il suffit de connaître la finalité du certificat pour renseigner correctement ces
champs. Pourtant, la réalité est tout autre, car l’interprétation des bits des champs Key
Usage et Extended Key Usage dépendent beaucoup des logiciels qui vont s’en servir.
Aussi, la seule logique ne suffit pas, les implémentations ont leur propre interprétation.
En somme, il ne s’agit pas seulement de positionner le champ Key Usage à Server
Authentication pour que le certificat permette d’authentifier un serveur. Il faut aussi
vérifier que les logiciels implémentés côté client et côté serveur s’entendent sur le sens à