Est-ce qu'un certificat ssl auto-signé (avec openssl) et crée pour nos applications serveurs est fiable?

Pause Café
#1

Bonjour,

Je sais qu’on peut utiliser let’s encrypt pour créer des certificats ssl pour nos applications serveur (tel que apache, postfix, dovecot, vsftpd, etc).

Mais comme on peut aussi créer un certificat ssl auto-signé avec openssl pour nos applications serveur, et que c’est plus rapide et plus facile à créer, alors je me dis que utiliser un certificat ssl auto-signé d’openssl pourrait faire l’affaire pour postfix, dovecot, vsftpd, phpmyadmin, roundcubemail, sauf pour les sites webs en production (car un navigateur qui affiche un avertissement de type « Attention, risque de sécurité, certificat ssl est auto-signé » ne met pas en confiance les utilisateurs).

Donc ma question est de savoir si un certificat ssl auto-signé avec openssl pour nos applications serveurs (comme postfix, dovecot, vsftpd, phpmyadmin, roundcubemail) est fiable pour la sécurisation des échanges de données à travers le réseau ?

Merci d’avance

1 J'aime
#2

Oui, mais n’importe qui peux en générer donc il est dit pas de confiance si le but est de fournir un service à un quidam utilise let’s encrypt il y a un organisme dit de confiance derrière qui garantit que le certificat est sûr.

Si le but est de chiffrer les communications entre deux services tel que mysql et et un site l’autosigné est suffisant, mais dès qu’un être humain rentre ne ligne de compte favorise un vrai certificat signé par un organisme ou un société :confused:

2 J'aime
#3

La problématique d’une chaine de confiance est la définition de la confiance.
Si ton certificat racine n’est aps protégé alors la confiance est faible.
Par exemple, mon certificat racine (CA) ne sert uniquement qu’à créer des certificat racine intermédiaires (CA SUB).
Et ensuite ce sont les CA SUB qui me servent à créer les certificats serveurs.
Il faut donc protéger au maximum les certificats racines.
Il ne doievent pas etre en ligne par exemple.
En ce qui me concerne ils sont sur une VM qui est elle-meme chiffré, et dont le répertoire pour virtualbox est lui-meme chiffré (avec zulucrypt).
En cas de risque j’efface. Les certificats sont sinon sur une clef spéciale de sécurité et sur une clef de base elle-meme chiffrée aussi.

Coté internet je suis le seul à m’en servir donc je sais identifier si le certificat est conforme.
Et pour les très rare personnes qui peuvent s’en servir je leur ai expliqué comment vérifier si le serveur est valide (l’utilisation du fingerprint du certificat notamment).

1 J'aime
#4

Merci pour vos réponses.

Pour créer mon certificat ssl auto-signé pour les applications serveurs où il n’y a que moi qui les utilisent en tant que client, j’ai utilisé le tuto Chiffrement SSL/TLS fort: foire aux questions - Serveur HTTP Apache Version 2.4, qui consiste à créer un certificat ssl auto-signé sans passer par des CA intermédiaires, du coup j’ai pas de fichiers CA stockés sur le serveur, voici la procédure :

Comment créer et utiliser sa propre Autorité de certification (CA) ?

La solution la plus simple consiste à utiliser les scripts CA.sh ou CA.pl fournis avec OpenSSL. De préférence, utilisez cette solution, à moins que vous ayez de bonnes raisons de ne pas le faire. Dans ce dernier cas, vous pouvez créer un certificat auto-signé comme suit :

  1. Créez une clé privée RSA pour votre serveur (elle sera au format PEM et chiffrée en Triple-DES) :

$ openssl genrsa -des3 -out server.key 2048

Sauvegardez le fichier server.key et le mot de passe éventuellement défini en lieu sûr. Vous pouvez afficher les détails de cette clé privée RSA à l’aide de la commande :

$ openssl rsa -noout -text -in server.key

Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée (non recommandé) de cette clé privée RSA avec :

$ openssl rsa -in server.key -out server.key.unsecure

  1. Créez un certificat auto-signé (structure X509) à l’aide de la clé RSA que vous venez de générer (la sortie sera au format PEM) :

$ openssl req -new -x509 -nodes -sha1 -days 365 -key server.key -out server.crt -extensions usr_cert

Cette commande signe le certificat du serveur et produit un fichier server.crt . Vous pouvez afficher les détails de ce certificat avec :

$ openssl x509 -noout -text -in server.crt

Et donc une fois le certificat ssl généré, je l’utilise pour tous les applications serveurs (dovecot, postfix, vsftpd, phmyadmin, roundcubemail), sauf pour les applications publiques (comme les sites webs).

Du coup, tu me conseilles de créer des certificats racines « intermédiaires » pour renforcer la sécurité ?

1 J'aime
#5

Voici ce que j’ai fait chez moi:
image

Si les SUB CA sont compromis je peux les révoquer à par du CA, individuellement. Et quand un Sub CA est révoqué, alors tous les certificats qui en dépendent sont révoqués aussi. Ça évite de faire du un par un à la main.
Chaque Sub CA a une fonction:

  • SUB CA 1: les utilisateurs (y compris leurs VPN)
  • SUB CA 2: Les serveurs et les applications
  • SUB CA 3: les VPN hors utilisateurs (tunnels entre machine, entre sites, etc…)

Pour gérer tout ça j’utilise XCA qui est très bien fait, ce qui m’évite toutes les manipulations manuelles qui sont un peu lourfde et pour lesquelles il est facile de se tromper.
En plus XCA permet l’utilisation facile de modèles de certificats mais aussi de clefs.
Avec on peut gérer les certificats, les Requests, les clefs, les listes de révocation, les renouvellements, les revocations.

3 J'aime
#6

Bonjour,

Juste une réflexion : je suis surpris de l’exemple utilisant ce chiffrement Triple DES, reconnu pour être obsolète et faillible ; le maillon faible ici me questionne.

Ensuite, la commande genrsa, dixit le manpage, est remplacée par la commande genpkey (pour générer une clée privée, qui peut soit être appelé en argument de l’outil openssl soit par la biais de l’outil openssl-genpkey).
Tel que :

$ openssl-genpkey -algorithm RSA -aes-128-cbc  -pkeyopt rsa_keygen_bits:2048 -outform PEM -out server_key.pem

ou :

$ openssl genpkey -algorithm RSA -aes-128-cbc  -pkeyopt rsa_keygen_bits:2048 -outform PEM -out server_key.pem

En terme d’algorithme, privilégiez ceux qui sont plus « secures », telles que ceux à base de courbe elliptiques, est pertinent ; le calcul mathématique derrière est plus rapide, mais nécessite des machines capables (ce qui est actuellement souvent le cas), tels que :

$ openssl genpkey -algorithm X25519 -out server_key.pem

Les algorithmes à courbes elliptiques sont EC, X25519, ED448 (par exemple).

Bref, lire le manpage openssl voire même mieux celui d’openssl-genpkeyest une nécessité dans ces contextes.

PS : Bien comprendre et analyser que ce sont des exemples, ni plus ni moins, de la faisabilité, sans parler d’une erreur possible dans l’interprétation. Ils ne sont pas forcément à reprendre tels quels, même si cela devrait fonctionner.

2 J'aime
#7

La force de l’habitude et des tutoriels existant pas forcément mis à jour.
Sans compter les certificats actuellement existant utilisant RSA.

1 J'aime
#8

Les applications clientes (de TLS et autre) n’aiment généralement pas les certificats auto-signés ce qui créer un petit soucis d’UX (obligé de valider le message d’avertissement, etc.).

Faire signer ses certificats par une CA permet d’éviter ce problème (de certificat auto-signé) mais en cas de CA tierce, la signature d’un certificat peut coûter de l’argent et rends dépendant de la CA pour la révocation (qu’elle peut d’ailleurs faire sans ton accord).

Il est donc possible de passer par sa propre CA et donc d’être autonome. Mais dans ce cas les applications clientes n’aime pas la CA qui a signé le certificat et on a de nouveau une mauvaise UX.

Une solution est d’ajouter le certificat de la CA en tant que certificat de confiance dans le/les systèmes qui font tourner les applications clientes (Linux, macOS, Windows, OPNsense, etc.).

2 J'aime
#9

Tu auras toujours le message sous firefox par exemple; car mozilla a considéré que seuls les CA qui sont liés à des certifications « institutionnelles » sont valides.
Comme ton CA autosigné, n’a pas été signé par une autre autorité de confiance, il n’est pas considéré comme de confiance.
Ca coute cher à faire, mais en plus il faut remplir un certain nombre de critères (qui empêche toute forme d’accès individuel à ce type de certification).

Cependant si ton utilisation 'est aps publique tu t’en moque complètement.
Les applications web, messageries, et applicatives (Tomcat(, IBM Webserver, etc…) n’en ont eux rien à faire. Dans le pire des cas c’est un warning.

Mais à n’utiliser que pour du privé (même sur internet), en s’assurant le cas échéant que les client aient un certificat signé par le dit CA et que toute autre type de connexion soient bloquée faute de certificat valide au sens mozilla du terme.

#10

Ça m’étonne car je peux toujours importer des certificats d’Autorité sur Firefox.

En milieu pro, pour de l’interne, je faisais ainsi et/ou je demandais à Firefox de faire confiance à la « banque » de certificats du système (eg. Windows).

#11

oui bien sur. mais quand tu vas s ur le site il te faut accepter le warning de première connexion et créer une exception. Le tout avec une i ndication de site non sécurisé dans la barre d’URL.

On parle ici de Certificats d’Autorité Auto-signé.

#12

Un certificat de CA est toujours auto-signé.

Il suffit effectivement de l’importer dans la base de certificats du système et il n’y a plus de problème avec les certificats signés par la CA en question.

https://grumpytechie.net/2020/02/25/adding-custom-root-ca-certificates-to-debian/

–
AnonymousCoward

#13

Justement non. Déjà un certificat serveur HTTP est signé par une CA.
IL n’est donc pas autosigné.
C’est le CA qui peut être autosigné, mais pas toujours. Les CA qu’on trouve par défaut dans le système et dans Firefox par exemple ne sont pas autosignés.

Et tu seras obligé de mettre de toute façon une exception dans Firefox car il ne le reconnaîtra pas comme valide. C’est implémenté par défaut dans Firefox depuis plusieurs années maintenant.
les exceptions c’est ça:
image

Ces exceptions sont considéré comme des exceptions aux erreur, ça se voit sur la barre d’URL par le point d’exclamation en triangle. :

image

et quand on clique dessus, il affiche l’indication: connexion non sécurisée

#14

Alors c’est marrant parce-que sur une Debian 13 je viens de vérifier et la totalité des 146 certificats CA du package ca-certificates sont auto-signés.

Et c’est ce package qui fournit les CA par défaut du système et de Firefox, comme la description du package l’indique.

–
AnonymousCoward

#15

Il doit de toute façon y avoir une différence entre ces certificats et ceux que tu fais toi.
Car si tu essaye de le faire, Firefox te mettre systématiquement une erreur et tu devras faire une exception.

Mais pour avoir essayé de rendre valide un certificat racine auto-signé personnel, ça n’a jamais marché. J’ai mis les CA de la chaîne de confiance, puis en allant sur le site il me met une erreur sur l’ISSUER du certificat.

1 J'aime
#16

Merci Zargos et les autres pour cet échange intéressant concernant les autorités de certification (CA) et les quelques hyperliens mentionnés pour en apprendre plus sur le sujet. Avec Libre Office Writer on peut signer un texte en format ODT avec GPG ce qu’on ne peut faire pour signer un document PDF toutefois. Il nous faut avoir un certificat valide pour signature et dans mon expérience, assez courte je dois dire, les certificats auto-signés obtenus par les façons décrites ci-haut ne remplissent pas cette condition. Avec le lecteur de documents Okular par contre le certificat auto-signé est reconnu et il est donc possible de signer des PDF avec cette application ce qui peut être intéressant à savoir pour quiconque veut apposer une signature numérique au document PDF qu’il a créé.
En effet payer une firme délivrant des CA pour signer numériquement des documents est contre-intuitif du point de vue utilisateur mais peut se révéler lucratif pour ces firmes (OPENSSL, etc.).

1 J'aime
#17

Pour signer un PDF, c’est assez simple? En fait on peut signer n’importe quoi.

[/tmp]$ gpg --sign E.pdf 
Le fichier « E.pdf.gpg » existe. Faut-il réécrire par-dessus ? (o/N) o
[/tmp]$ qpdfview E.pdf.gpg
[/tmp]$ gpg --verify E.pdf.gpg 
gpg: Signature faite le dim. 09 mars 2025 16:37:14 CET
gpg:                avec la clef DSA 8....1B1C...................59D....86E
gpg: Bonne signature de « François xxxxxxxxxxxxxxxxxxxxxxxxxxx » [inconnu]
gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
gpg:             Rien n'indique que la signature appartient à son propriétaire.
Empreinte de clef principale : 82..............................................6E
[/tmp]$ hexedit E.pdf.gpg # Là je change un octet
[/tmp]$ qpdfview E.pdf.gpg # le truc est encore visible
[/tmp]$ gpg --verify E.pdf.gpg 
gpg: Signature faite le dim. 09 mars 2025 16:37:14 CET
gpg:                avec la clef DSA 823Exxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx086E
gpg: MAUVAISE signature de « François xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx » [inconnu]
[/tmp]$

Tu peux aussi détacher la signature.
Après il faut une autorité pour certifier ta signature, j’ai toujours pensé que cela relevait du service public, mais pour le moment ça n’est pas le cas. À noter que j’ai fait ça pour tous les dossiers et attestations de mes élèves lorsqu’ils posaient leurs candidatures où que ce soit particulièrement à l’étranger, ça m’a évité des envois postaux incertains et ça crédibilisait le dossier

1 J'aime
#18

Si tu rajoute le certificat de la CA dans l’onglet Autorités (parmi les autres qui sont pré-autorisées par Firefox) tu n’auras plus l’avertissement pour tout certificat signé par cette CA : c’est le but même de cette liste/onglet.

1 J'aime