Bonjour
Ubuntu 18.04 LTS avec Apache2 2.4.29 et OpenSSL 1.1.0g
**Je veux désactiver TLSv1 et TLSv1.1** pour ne plus avoir que TLSv1.2
(et le prochain TLSv1.3)
ça semble simple, mais ça ne fonctionne pas.
Je change dans /etc/apache2/mods-enabled/ssl.conf :
J'ajoute "-TLSv1" et "-TLSv1.1"
# The protocols to enable.
# Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
# SSL v2 is no longer supported
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
Je sauve, redémarre Apache2.
Mais les sites de test comme https://www.ssllabs.com/ssltest
me donne toujours TLSv1, TLSV1.1 et TLSv1.2
Idem quand je teste en CLI avec
`openssl s_client -connect monsite.misson.ovh:443 -tls1`
Je devrais avoir un message d'erreur, mais la session se fait en TLSv1...
Même avec
SSLEngine on
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
dans le VirtualHost Apache, impossible de supprimer le TLSv1 et v1.1 ...
une idée ?
Merci et bon dimanche. Didier
Serveurs dédiés - Apache disable TLSv1
Related questions
- Proxmox VM accès internet impossible
53503
19.11.2016 12:11
- Spam et IP bloquée
51032
12.12.2016 11:53
- il y a quelqu'un ?
49898
15.12.2025 17:01
- Mise en place de VM avec IP publique sur Proxmox 6 [RESOLU]
49071
30.04.2020 17:12
- SSD NVMe Soft Raid ou SSD SATA Hard Raid
48543
29.06.2021 23:29
- Port 25 bloqué pour spam à répétition
45840
28.02.2018 13:39
- Mise à jour PHP sur Release 3 ovh
45090
11.03.2017 17:43
- Identification carte réseau
43613
05.12.2025 10:09
- Connection smtp qui ne marche plus : connect error 10060
43546
12.04.2019 10:10
- Partition sur le disque de l'OS ESXI
43195
09.05.2017 14:33
Bonjour,
il y a la même question ici, la réponse devrait convenir ;)
https://serverfault.com/questions/848177/how-can-i-disable-tls-1-0-and-1-1-in-apache
Pour faire ma configuration TLS sur mes serveurs Apache, j'utilise cet outil :
https://mozilla.github.io/server-side-tls/ssl-config-generator/
Désactiver les protocoles ne suffit pas, il faut aussi modifier la liste des Ciphers.
oui, je connais **Mozilla SSL Configuration Generator**.
Ils font un superbe boulot !
Mais pour certains sites, je ne pense pas pouvoir mettre complètement le mode "Modern", càd le plus stricte. Faudra que je teste, que je ne bloque pas les Android trop anciens (disons, quand même laisser les 4.4.x... peut-être les 4.3.x...) et peut-être les XP, on verra.
Pour la majorité de mes autres sites, je prendrai la config la plus stricte car en Europe je pense qu'on DOIT avoir largué XP et MS IE ! ... ou au moins XP avec un Firefox pas trop ancien.
Donc, pour le moment je teste, et ça ne se passe pas comme prévu avec la config SSLProtocol.
Pourtant ça semble hyper simple et clair...
Merci. Didier
Bonsoir Buddy
Oui, la réponse me conviendrait... si elle fonctionnait !
J'ai mis explicitement le seul protocole que je veux dans
* /mods-available/ssl.conf
et aussi dans
* /sites-enabled/monsite.be (le seul que j'ai pour le moment sur ce serveur)
`SSLProtocol TLSv1.2`
Restart Apache2 ...
et non... je peux toujours établir une session TLSv1 et TLSv1.1
Bon, je vais prendre simplement la config "Modern" donner par le Mozilla SSL Config Generator !
https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-2.4.28&openssl=1.1.0e&hsts=yes&profile=modern
mods-avalable/ssl.conf :
# modern configuration, tweak to your needs
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)
---------------
ça ne change absolument RIEN !
https://www.ssllabs.com/ssltest/analyze.html?d=ct1800-temp.misson.ovh&hideResults=on
J'ai toujours TLSv1 et TLSv1.1 actif.
Et pas une seule suite de chiffrement "Weak" n'a été supprimée !
Je ne vois qu'une explication : Apache2 ne prend pas sa config de chiffrement dans ssl.conf ???
j'aurais une autre ligne SSLProtocol ?
Mais où ?
Merci. Didier
Apache est bien redémarrer à chaque fois ?
C'est quelle distribution ?
Un
Updatedb && locate ssl.conf renvoie plusieurs fichiers ?
grep -ri SSLProtocol /etc/apache2/*Tu dois avoir défini les protocoles SSL dans un autre fichier de configuration.
oui, c'est ce que je dois faire !
Mais hier soir (tard...) j'avoue que je n'avais plus en tête la syntaxe du Grep pour une recherche sur un dossier complet...
Merci.
il y avait de l'idée...
mais rien trouvé :
grep -ri SSLProtocol /etc/apache2/*
/etc/apache2/mods-available/ssl.conf:SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1**
/etc/apache2/mods-available/ssl.conf: # SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
/etc/apache2/mods-available/ssl.conf:# SSLProtocol TLSv1.2
/etc/apache2/sites-available/ct1800-temp.misson.ovh.bak20180514:SSLProtocol TLSv1.2
/etc/apache2/sites-available/ct1800-temp.misson.ovh.bak20180514:# SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
/etc/apache2/sites-available/ct1800-temp.misson.ovh.conf:# SSLProtocol TLSv1.2
/etc/apache2/sites-available/ct1800-temp.misson.ovh.conf:# SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
à part dans un fichier backup (qui n'est pas actif, pas dans sites-enabled), la seule ligne SSLProtocol est dans ssl.conf.
Dans **ssl.conf**, j'ai donc repris le code général par le Mozilla SSL Configuration Generator, en mode "**Modern**" càd stricte.
Bonne soirée. Didier
Est-ce que tu aurais modifié ton Apache pour gérer de multiples environnements de configuration ? (ie: par modification de /etc/apache2/envvars) qui pourrait expliquer qu'une partie des fichiers n'est pas prise en compte.
Si la machine n'est pas "propre", ça peut s'expliquer de la sorte. (à force de faire des tests, on en oublie qu'on a touché des fichiers)
... pour gérer de multiples environnements de configuration ?
Pas à ma connaissance. Je n'ai jamais cherché dans cette direction...
Mais je vais vérifier, car j'ai Webmin / Virtualmin, et parfois ce genre de soft modifie certaines configs.
Sinon, c'est une nouvelle installation Ubuntu 18.04.
J'ai fait très peu de tests, presque exclusivement les installations.
Il y a une raison logique à avoir ** en bout de ligne ?
C'est peut être le bug..
le "**" en fin de ligne ?
Je suis presque sûr que c'est en voulant mettre en gras dans l'éditeur du forum !
Mais je vais vérifier à la maison.
Oui je parlais de ça.
Sinon pour virtualmin, ils disent que c'est dans le fichier
virtualservers.conf (source qui date un peu.. )
Virtualmin a mis des options TLSProtocol directement dans le VirtualHost Apache
mais c'était les options classiques -SSLv2 -SSLv3
même en les modifiant, je n'ai jamais réussi à supprimer le TLSv1 et TLSv1.1.
Je pense que Virtualmin ne fait que ça (sauf si je bricole les options Apache dans Webmin),
et de toute façon quand Virtualmin a créé le site, je peux modifier manuellement le VirtualHost.
J'ai mis ça en commentaire dans le VirtualHost (1 seul site pour le moment), mais les options dans ssl.conf n'ont malgré tout pas été prises en compte.
Ce n'est PAS urgent, ni critique... mais ça m'intrigue que des options "aussi simples" ne soient pas prises...
Une idée..
Si tu actives le mod "info" (a2enmod info) et que tu autorises ton IP à aller voir server-info (dans mods-available/info.conf), tu devrais pouvoir voir toutes les directives qu'Apache prend en compte.
Ca pourrait peut-être te permettre d'identifier la ligne qui te fout le bordel.
la ligne dans mods-available/ssl.conf est correct :
# modern configuration, tweak to your needs
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM
-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SH
A384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
Pas d'étoiles à la fin.. C'était une erreur en éditant le texte.
Virtualmin : je n'ai pas trouvé de fichier "virtualservers.conf" ... ni "virtualservers"
**j'ai cherché plus large !**
grep -ri SSLProtocol /etc/*
/etc/apache2/sites-available/ct1800-temp.misson.ovh.bak20180514:SSLProtocol TLSv1.2
/etc/apache2/sites-available/ct1800-temp.misson.ovh.bak20180514:# SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
/etc/apache2/sites-available/ct1800-temp.misson.ovh.conf:# SSLProtocol TLSv1.2
/etc/apache2/sites-available/ct1800-temp.misson.ovh.conf:# SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
/etc/apache2/mods-available/ssl.conf:SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
/etc/apache2/mods-available/ssl.conf: # SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
/etc/apache2/mods-available/ssl.conf:# SSLProtocol TLSv1.2
/etc/letsencrypt/options-ssl-apache.conf:SSLProtocol all -SSLv2 -SSLv3
La dernière ligne est intéressante !
**Let's Encrypt ?**
Où est-ce que ça intervient ?
En théorie ça ne peut venir que lorsque je crée le VirtualHost, et que j'ajoute pour la 1ère fois le certificat LE ?
Bingo !
Quand tu utilises le client cerbot, celui-ci modifie la configuration de tes vhosts pour intégrer ça :
Include /etc/letsencrypt/options-ssl-apache.confIl faut commenter les lignes dans le fichier qui ne te plaisent pas.
J'étais en train de regarder, et YES !
**Tu as tout à fait raison !**
Let'sEncrypt, c'est la dernière ligne du VirtualHost !
Je vais tester, mais ça va fonctionner, c'est certain ;-)
ok !
C'est bien Let's Ecnrypt qui impose sa propre configuration.
La dernière ligne du VirtualHost, ajoutée par CERTBOT lorsque je génère le certificat Let's Encrypt :
SSLCertificateFile /etc/letsencrypt/live/ct1800-temp.misson.ovh/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/ct1800-temp.misson.ovh/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
Donc, Cerbot ajoute SES propres configs SSL / TLS et SES propres choix de suites de chiffrement.
Comme ce sont les dernières commandes SSL rencontrées, ce sont elles qui sont utilisées.
Donc, si je veux modifier SSLProtocol pour supprimer TLSv1 et TLSv1.1,
ou pour retirer les suites de chiffrement "faibles", le plus simple est de modifier dans
**/etc/letsencrypt/options-ssl-apache.conf**
Je teste une session avec TLSv1 :
openssl s_client -connect monsite.misson.ovh:443 -tls1
CONNECTED(00000003)
139826088404632:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:s3_pkt.c:1487:SSL alert number 70
139826088404632:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1526424977
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
OpenSSL n'arrive pas à obtenir un certificat en TLSv1.
**Le test avec SSLLabs confirme que seul TLSv1.2 est actif.**
https://www.ssllabs.com/ssltest/analyze.html?d=ct1800-temp.misson.ovh&hideResults=on
Je n'ai pas encore vérifié les suites de chiffrement faibles.
Pour XP et Vista ?
Quelles sont les versions les plus récentes de Firefox et Chrome qui tournent en XP et Vista ?
Je ne voudrais pas bloquer entièrement XP ni Vista.
Et Android ?
Si je bloque entièrement tous les Android 4.x.x ... c'est un peu limite ?
Quel est votre avis sur cela ?
J'ai mis en place deux types de configurations :
* une "modern" pour les sites pour lesquels je me fous de rejeter les vieux clients (parce que je sais que je n'en aurai pas sur ces sites)
* une "intermediate" qui autorise le TLS 1 avec quelques protocoles plus faibles. La configuration proposée par le configurateur Mozilla, malgré les algos "faibles" permet d'obtenir une note A sur SSLLabs.
Dans tous les cas, j'ai du TLS1.2, au moins une note A (en rajoutant le HSTS, j'arrive en A+) tout en permettant d'accepter de "vieux" navigateurs sur les sites pour lesquels je ne peux m'en passer.
Dans mon cas, ça me suffit.
Par contre, un détail, pourquoi ne pas avoir utilisé le client Let's Encrypt intégré à Virtualmin ?
J'ai la réponse dans le test de ssllabs !
Dans "Handshake Simulation" je vois
**Android 4.4.2 : OK**
**Android 5.0.0 : OK**
et il y a bien des versions Firefox et Chrome compatible avec mon site en TLSv1.2, aussi bien en **XP SP3** que **Win7** ...
ok, ça devrait aller.
Les utilisateurs XP et Windows 7, s'ils ont mis leur Windows à jour jusqu'à la fin du support, ça ira.
Ok, tant pis pour les XP qui sont restés uniquement avec MS IE8 sans jamais installer Firefox ou Chrome.
Pour Windows 7, même MS IE11 est compatible TLSv1.2.
**Par contre, on largue VISTA !**
Les utilisateurs VISTA ne pourront plus se connecter probablement.
Pas grave. Des utilisateurs sont restés en XP... mais pour VISTA, ils se sont tous dépêché de passer à un Windows plus récent.
Bonne question !
J'ai testé, et ça ne m'emballait pas trop.
Il me semble que je n'avais pas la main sur la fréquence de renouvellement.
Moi je teste 2x par semaine.
Je devrais vérifier Virtualmin avec LE.
Quand je l'ai testé, c'était vraiment le début du support Let's Encrypt dans Virtualmin.
Mais, autre raison, une commande d'ajout du genre :
cerbot --apache -d monsite.be -d www.monsite.be -d dev.monsite.misson.ovh
... ça me semble SIMPLE.
Le renew, c'est juste un petit script dans la contrab 2x par semaine.
Tu trouves ça réellement mieux que certbot ?
(pour celui qui aime le ligne de commande évidemment)
En fait, par principe, je souhaite éviter les va-et-vient entre plusieurs interfaces de configuration.
Le client intégré à Virtualmin gère automatiquement les alias des virtual server au lieu de devoir le faire à la main dans la ligne de commande. Du coup, on peut déléguer la gestion des certificats SSL à des utilisateurs rodés à l'utilisation d'un clicodrome.
oui, bonne solution !
Mais ici, c'est moi qui fait toute cette config Proxmox ou VPS, Ubuntu, LE, Virtualmin ...
Mais je devrais réessayer de gérer Let's Encrypt via Virtualmin.
Pas exactement !
Si je bloque TLSv1 et TLSv1.1, les Android 4.4.x ne sont pas compatibles par défaut avec TLSv1.2
https://qsportal.atlassian.net/wiki/spaces/DOC/pages/3571715/TLSv1.2+Browser+Compatibility
**Android 4.4 (KitKat) to 4.4.4 : Capable, but not by default.**
ça va probablement bloquer des anciennes tablettes.
On vend encore des tablettes en 4.4.x ... c'est délirant.
à réfléchir.
**Voici ce qui me bloquait dans la gestion de certificats Let's Encrypt dans Virtualmin :**
Months between automatic renewal Only renew manually 2
Je n'ai le choix que de vérifier 1x par mois ?
Puisque le minimum est 1 mois entre les renouvellements automatiques ?
(ou je n'ai rien compris...)
Autre point, de toute façon je modifie mes VirtualHost pour rediriger :
http --> https
www.monsite.be --> monsite.be
et ça, je n'ai pas trouvé de moyen simple dans la config LE dans Virtualmin !
alors ? ... de toute façon je dois aller modifier mes VirtualHost Apache...
Si tu réclames trop souvent de nouveaux certificats à Let's Encrypt dans un court laps de temps, tu peux te faire blacklister. Bon, à un certificat par semaine, t'es tranquille ;-)
Les certificats sont valables trois mois. Tu peux les renouveler à partir du dernier mois.
Si le renouvèlement échoue, Virtualmin retentera le jour suivant (vu que le certificat est à renouveler)
Virtualmin va demander un certificat pour l'ensemble des alias et prendre en compte notamment site.fr ;-) Donc, en fait, au moment où tes visiteurs voudront aller sur ton site, ils auront de toute façon un certificat SSL valide en face. Ensuite, tu n'as que des règles de réécriture à gérer au niveau de ton site, les erreurs de certificat SSL en moins à gérer.
Un seul point pour configurer les certificats SSL, une seule source de défaillance.
mon script de renouvellement des certificats Let's Encrypt tourne 2x par semaine... ça ne pose pas de problème.
Mais ok, je vais réessayer de les générer avec Virtualmin.
ça limitera fortement le nombre d'essais, et donc la charge occasionnée chez LE.
Je suppose donc que Let's Encrypt à aussi un script en crontab qui tourne tous les jours, mais qui ne fait les demandes QUE des certificats à renouveler à moins de 30 jours de la date d'expiration ?
Let's Encrypt ne renouvèle que les certificats qu'on lui demande de renouveler, au moment de la demande de renouvèlement.
ce qui est mieux : pas de demandes de renouvellement de certificats inutiles à Let's Encrypt.
Merci du conseil.
Je vais retester la génération des certificats L.E. avec Virtualmin.