|

LINUX – Certificats

ParErwan Guillemard

C’est une évidence, mais pourtant je me suis souvent à mes début (ou par flemme) passé de certificats pour la publication de mes services. Et puis honnêtement « Qu’est ce que j’en avais à f****e ? Je ne faisais pas de publication sur le www« . Oui mais ce comportement désinvolte doublé d’une flemme masquait deux choses :

  • Le manque de budget pour acheter un NDD1 et un certificat TLS/SSL2
  • Un manque de compétence pour générer un certificat auto-signé

Le bât blesse hein ? Et pourtant même si un moment de honte est si vite passé, l’orgueil en prend toujours un coup. Je me suis dit que cela serait une bonne chose de rappeler le fonctionnement théorique d’un certificat. Puis le côté pratique pour générer un certificat autosigné, voir même pourquoi pas un certificat Lets Encrypt ?

Prérequis

  • SE : GNU LINUX
  • Apps : openssl, certbot
  • Autres :

Théorie – Certificats

Déjà la première question légitime serait « Qu’est ce qu’un certificat ? » . L’une des définition pourrait être « Un fichier qui permet de garantir l’identité d’une ressource de manière singulière et permettre l’établissement d’échange d’informations de manière sécurisée. »

Il existe trois grands types de certificats SSL :

  • DV (Domain Validated)
  • OV (Organization Validated)
  • EV (Extended Validation)

Les certificats (les vrais authentiques) sont délivrés par des AC3 qui vont vérifier la véracité des informations d’une personne ou d’une entreprise dans l’optique d’établir précisément son identité. L’AC va émettre le certificat à l’administrateur du site qui en à fait la demande. Dans le certificat, nous allons retrouver les informations suivantes :

  • L’url du site, de l’ensemble des SANs4 ou wildcard certifiés
  • Les informations de l’entreprise tel que son nom, adresse
  • La clé publique
  • Le nom de l’AC qui a fournit le certificat ainsi que ça signature
  • La date de début et de fin de validité du certificat

Personnellement je n’ai utilisé à ce jour que des certificats DV. Bien que tous ces certificats garantissent la sécurité d’échanges d’information ils n’ont pas le même niveau d’exigence, le même cout et le même temps de création et de livraison.

DV < OV < EV

Le certificat DV fournit le niveau le plus faible niveau d’authentification. Il est facile d’obtenir un certificat dans l’heure. Lors de la demande de création du certificat, l’AC va s’assurer que le nom de domaine est bien la propriété de la personne ou de l’entreprise.

Le certificat OV va fournir un niveau de sécurité un niveau au dessus en garantissant plus précisément l’identité du certificat délivré auprès de la personne ou de l’entreprise. L’AC va reprendre les mêmes vérifications que pour le certificat DV tout en ajoutant d’autres contrôles afin de garantir de l’identité du demandeur et donc d’une confiance supplémentaire auprès des utilisateurs. Cette vérification peut être visible dans le certificat dans les attributs lié à l’entreprise.

Le certificat EV fournira le niveau de confiance le plus élevé quant à l’authentification. Lors de la demande de ce type de certificat, l’AC va reprendre les mêmes points de contrôle que pour la construction des certificats OV et DV en poussant le contrôle bien plus loin. Tel que le contrôle du numéro d’entreprise (SIRET, SIREN ect), le numéro de téléphone ect. Une fois le certificat délivré ce dernier est vu par les navigateurs comme une source de confiance maximum et gage de sécurité quant à l’organisation qui le présente.

Ok pour les types de certificat. Mais qu’en est il de la navigation entre un poste client et un site web ?

Avant d’attaquer la navigation et l’affichage d’un site web sécurisé par un certificat, le poste client va établir auprès du site web un ensemble d’opération (négociation TLS) afin d’établir une clé de session entre les deux parties pour réaliser les échanges d’informations chiffrés.

  • Le poste client requête le serveur WEB
  • Le serveur WEB présente son certificat au poste client ainsi que la clé publique afin d’établir une connexion sécurisée, chiffrée. C’est l’établissement de la clé de session
  • Le poste client valide qu’il a confiance à l’AC dans les informations présentées par le certificat à condition que la date de validité du certificat est conforme
  • La navigation peut alors débutée

Pour le reste, si ça vous intéresse, je vous laisse approfondir le sujet. Comme pour le stockage et format de disque, il serait facile de débattre et d’échanger sur le sujet durant des heures.

Intéressons nous plutôt en détails au contenu de notre certificat. Toc Toc Toc qu’est ce qu’il y a dans notre certificat (certificat.csr ou certificat.crt) ? Comme vu plus haut il contient les informations propres à notre identité physique pour garantir le niveau de confiance de notre ressource.

$ sudo cat /etc/pki/tls/certs/portail.erwanguillemard.com.crt

Bon on va pas se mentir, comment doit on lire ça ? Ma méthode Champollion date des mes derniers cours de math lorsque je déchiffrais tant bien que mal les vagues d’écritures rouges de mes professeurs « Oh le cours et le chapitre ne sont pas maitrisés, ressaisissez vous !!!! » (il y a du vrai et en toute honnêteté, j’étais malheureusement bon client de ce genre d’encouragement ?!) 🙂 Mis à part ça, sauf si vous savez décoder de tête le standard x509, vous pouvez passer par ce petit site que j’aime bien Lien et copier le contenu de notre certificat.

Ouwa la classe, il est même certifié 10 ans ! Sauf que c’est pas un « vrai » certificat. C’est un « faux » ou du moins un toléré. Au tout début de cet article j’ai parlé de certificat autosigné. Si nous reprenons les trois types de certificats disponible, il en existe un quatrième, j’ai nommé l’autosigné ou AS.

AS < DV < OV < EV

Le certificat AS est considéré comme le certificat avec le niveau de sécurité le plus faible de tous pour ne pas dire inexistant (car il chiffre les données tout de même). L’AS est considéré comme tel car comme son nom l’indique, nous n’allons pas passer par une AC tierce. L’AC c’est moi ! Et donc vous conviendrez que nous ne pouvons pas être juge et partie. Niveau confiance c’est pas top. Toutefois (car il y a un toutefois), cela est plutôt pratique pour garantir sur notre LAN le chiffrement des données entre des applications (attention, pas de publication vers l’extérieur. Sauf si vous êtes joueurs et voulez à tous prix benchmarker les performances de Pôle Emploie vs France Travail). Un exemple, un accès à une solution de ticketing, CMDB :3

Notre navigateur « n’est pas content » et il nous le fait savoir « ERR_CERT_AUTHORITY_INVALID » car il ne peut pas vérifier l’AC et donc ne fait pas confiance au certificat qui est présenté. Cela pourrait être un individu malveillant ? Bien que si nous poursuivons le navigateur nous informe que notre navigation n’est pas sécurisée, nos échanges sont bien chiffrés à travers la clé publique présente dans notre certificat.

Et si maintenant nous passions à quelques choses de plus concret ?

Pratique – Certificats

Autosigné

Comme présenté précédemment, le certificat autosigné a son avantage si l’on souhaite garantir un minimum de sécurité sur notre LAN à moindre cout.

Pour se faire nous allons dans un premier temps générer les informations de l’entité de certification « AC », certificat et clé privée. Puis nous générerons notre certificats que nous adouberons dans par NOTRE entité de confiance.

Autorité de Confiance

La commande qui suit va nous permettre de générer la clé privé de notre autorité de confiance. Passons à la loupe l’ensemble des commandes que nous allons exécuter. OpenSSL peut vite se montrer complexe et il est facile de se perdre dans les commandes quand nous ne les utilisons pas quotidiennement.

  • ecparam : indique que nous allons générer à partir d’une fonction mathématique EC5 une série d’octet en tant que strings qui débutera par ——-BEGIN EC PARAMETERS—– et se terminera par ——-END EC PARAMETERS—–.
  • out : indique la sortie dans notre fichier *.key
  • name : spécifie le type de courbe elliptique que nous souhaitons pour générer notre clé. il est possible d’afficher les ECs disponible openssl ecparam -list_curves. Attention le choix de l’algorithme et important car ils n’ont pas tous le même usage et ne sont pas supportés par tous les navigateurs ou autres. Dans notre usage, il est préférable d’utiliser prime256v1 ou secp384r1 (aussi connu sous P384)
  • genkey : précisons la génération d’une clé
$ sudo openssl ecparam -out erwanguillemard_racine.key -name prime256v1 -genkey

Notre clé *.key racine créée, nous allons pouvoir générer notre demande de signature de certificat CSR6 .

  • req : instruction de de demande de requête
  • new : nouvelle requête
  • sha256 : algorithme de salage, hashage qui sera utilisé
  • key : spécifions notre clé privé soit la clé généré précédemment
  • out : indique la sortie dans notre fichier *.csr
$ sudo openssl req -new -sha256 -key erwanguillemard_racine.key -out erwanguillemard_racine.csr

Nous avons tous les éléments nécessaires pour générer notre certificat racine d’autorité de certification soit notre *.csr et *.key.

  • x509 : spécifie la norme de certificat qui sera utilisé. Généralisé depuis les années 80, cette norme est toujours en vigueur pour les certificats à clé publique. Il est l’un des standards des certificats de nos jours.
  • req : nouvelle requête
  • sha256 : algorithme de salage, hashage qui sera utilisé
  • days : le nombre de jour de validité
  • in : le fichier *.csr généré précédemment
  • signkey : le fichier *.key qui va signer notre certificat
  • out : indique la sortie de notre certificat dans notre fichier *.crt
$ sudo openssl x509 -req -sha256 -days 3650 -in erwanguillemard_racine.csr -signkey erwanguillemard_racine.key -out erwanguillemard_racineCA.crt

Certificat – portail.erwanguillemard.com

Et voilà notre AC terminée. Il ne nous reste plus qu’à recommencer les étapes pour notre certificat que nous déploieront pour notre application ITOP sous l’url portail.erwanguillemard.com. L’exception se verra lors de la génération du certificat puisque nous utiliserons notre certificat racine ainsi que notre clé racine de notre autorité de certification « homemade ».

(On admire un mangnifique Ctrl+C enchainé d’un Ctrl+V)

  • ecparam : indique que nous allons générer à partir d’une fonction mathématique EC5 une série d’octet en tant que strings qui débutera par ——-BEGIN EC PARAMETERS—– et se terminera par ——-END EC PARAMETERS—–.
  • out : indique la sortie dans notre fichier *.key
  • name : spécifie le type de courbe elliptique que nous souhaitons pour générer notre clé. il est possible d’afficher les ECs disponible openssl ecparam -list_curves. Attention le choix de l’algorithme et important car ils n’ont pas tous le même usage et ne sont pas supportés par tous les navigateurs ou autres. Dans notre usage, il est préférable d’utiliser prime256v1 ou secp384r1 (aussi connu sous P384)
  • genkey : précise la génération d’une clé
$ sudo openssl ecparam -out portail.erwanguillemard.com.key -name prime256v1 -genkey

Notre clé *.key créée, nous allons pouvoir générer notre demande de signature de certificat CSR6 .

  • req : instruction de de demande de requete
  • new : nouvelle requete
  • sha256 : algorithme de salage, hashage qui sera utilisé
  • key : spécifions notre clé privé soit la clé généré précédemment
  • out : indique la sortie dans notre fichier *.csr
$ sudo openssl req -new -sha256 -key portail.erwanguillemard.com.key -out portail.erwanguillemard.com.csr

Nous avons tous les éléments nécessaires pour générer notre certificat soit notre *.csr ainsi que notre certificat racine et clé racine de notre AC.

La commande diffère de celle qui a été exécuté lors de la génération de notre certificat racine AC.

  • x509 : spécifie la norme de certificat qui sera utilisé. Généralisé depuis les années 80, cette norme est toujours en vigueur pour les certificats à clé publique. Il est l’un des standards des certificats de nos jours.
  • req : nouvelle requête
  • in : le fichier *.csr de notre certificat portail.erwanguillemard.com
  • CA : le certificat racine de notre AC *.crt généré plus tôt
  • CAkey : la clé privée racine correspondant à notre AC *.key
  • CAcreateserial : génère un numéro de série unique à notre certificat par le biais de notre AC
  • days : le nombre de jour de validité de notre certificat
  • out : Indique la sortie de notre certificat dans notre fichier *.crt
  • sha256 : Algorithme de salage, hashage qui sera utilisé
$ sudo openssl x509 -req -in portail.erwanguillemard.com.csr -CA  erwanguillemard_racineCA.crt -CAkey erwanguillemard_racine.key -CAcreateserial -out portail.erwanguillemard.com.crt -days 3650 -sha256

Nous avons donc notre certificat valide est disponible. Toutefois pour utiliser celui ci et ne pas le laisser trainer n’importe où (au vu de la criticité des informations qu’il contient), nous allons les déplacer dans les répertoires adéquates. Nous verrons ça plus bas.

Let’s Encrypt

Les certificats Let’s Encrypt sont apparu bien après mon cursus universitaire et donc je ne connaissais pas le principe. Aujourd’hui je dirais que c’est l’un des plus utilisés pour les sites vitrines. Pour rappel, le remplacement d’un certificat au delà du cout financier (variable) nécessite des actions humaines qui peuvent être conséquentes dans des infrastructures complexes. C’est pourquoi Let’s Encrypt propose de fournir gratuitement des certificats et de permettre de piloter et d’industrialiser le renouvellement de ces derniers directement sur les environnements. Cela permet également de générer facilement un certificat.

Ci-dessous, un exemple de déploiement depuis un serveur linux. Il sera toutefois nécessaire de déployer les paquets certbot ainsi que certbot pour apache.

# dnf install certbot python3-certbot-apache

Nous souhaitons générer notre certificat. Certbot va nous permettre de générer le certificat et de l’installer directement sur notre server ou de seulement générer celui-ci pour notre daemon apache. Je suis plutôt partisan de la seconde option. Je préfère ne pas faire confiance à la machine. Surtout que nous sommes en root.

# certbot certonly --apache

Le bot est sympa, il vous demande même votre adresse mail pour vous notifier de l’expiration de votre certificat en cas d’oublie. Il sera nécessaire également d’accepter les termes d’utilisations (que je n’ai pas lu naturellement comme tout le monde… Que celui qui me contredise m’offre la première bière !)

Libre à vous de dire Y pour accepter ou N pour refuser avec vos petits doigts.

Et là, et bien ça a merdé… Je vous passe les captures d’écrans d’échec critique. En voulant générer mon certificat, je n’avais pas à se moment générer mon fichier de configuration apache (mon virtualhost) et ni installer la partie web d’ITOP. Or, le certbot se base sur la configuration apache pour générer le certificat.

Conclusion, avoir un fichier de configuration valide.

Nous allons donc faire les choses bien et réaliser un enregistrement DNS pour notre site portail.erwanguillemard.com puis nous rappelons notre dernière commande.

# certbot certonly --apache

Ca ne fonctionne pas mieux… Ce qui est normal puisque mon site n’est pas joignable depuis l’extérieur car :

  • Je n’ai pas de firewall (en dehors de ma box) pour faire un SNAT digne de ce nom
  • Je n’ai pas la possibilité de faire un réseau de couche 2 à la maison (je donne raison à ma femme, ça reviendrait à rammener du travail à la maison. Mais j’y arriverai un jour 🙂 )
  • Je n’ai pas d’ESXi (un petit vSwitch avec un groupement de port par dessus et yopi hop !)

Enfin, cela ne change rien puisqu’à la fin de cette étape, nous récupérons notre certificats ainsi que notre clé qu’il conviendra de déplacer dans les bons répertoires et de configurer notre fichier de configuration apache propre à notre site web.

Où stocker le .key et .crt

Il m’est déjà arrivé lors d’audit d’un système GNU de trouver des clés et certificats dans des répertoires qui ne devraient pas l’être. D’où la première réflexion qui me vient à ces moment là.

Qui qu’a mis ça là pis qu’a pas balayé?

Pierre BENICHOU

Effectivement, les informations sont sensibles et je crois avoir bien insisté sur ce point précédemment. En temps normal, les informations sont stockées sous /etc/pki/. Dans notre cas plus précisément dans /etc/pki/tls/.

Les certificats doivent être stockés sous /etc/pki/tls/certs/, les clés doivent être stockées quant à elles sous /etc/pki/tls/private/. Dans tous les cas les permissions doivent être 600 pour root:root.

Conclusion

Je pense que tant que faire se peut il est nécessaire de déployer des certificats. Il se pose alors la question de la criticité et de l’exposition de notre site.

Effectivement, si notre site est publié sur internet, le certificat doit être délivré par une CA afin de garantir une niveau de confiance satisfaisant. Un certificat Let’s Encrypt est également envisageable mais de mon point de vu plus à destination de site vitrine. Toutefois pour un usage interne l’utilisation d’un certificat auto-signé fait l’affaire et c’est toujours mieux que rien.

L’un des points de vigilance est de contrôler que les éléments (certificats, key etc) sont bien « rangés » dans les bons répertoires et que les droits et permissions sont bien appliqués.

Dans le cas de renouvellement de certificat, il sera nécessaire de ne pas collectionner les éléments expirés. Quand un changement est réalisé autant aller jusqu’au bout.

Le mot de la fin :

Je NAT mes congés, galoche mon CA. Ca nous ramènera pas Carlos cette histoire.

Erwan GUILLEMARD

Sources

  1. NDD : Nom De Domaine ↩︎
  2. TLS/SSL : Transport Layer Security / Secure Sockets Layer ↩︎
  3. AC : Authorization Certificate ↩︎
  4. SAN : Subject Alternative Name ↩︎
  5. EC : Elliptic curve ↩︎
  6. CSR : Certificat Signature Request ↩︎
  7. EC : Elliptic curve ↩︎
  8. CSR : Certificat Signature Request ↩︎