(https://static.chez-oim.org/Logo/letsenrypt_logo.png)(https://static.chez-oim.org/uploads/member_1/stock1/1486050220.png)
Tuto, LetsEncrypt: Installer un certificat de sécurité SSL sous Windows ou Linux
Mise à jour du 16 mars 2023
Mise à jour des liens vers l'exécutable Windows de la bibliothèque Perl Crypt::LE (le.exe) suite à la sortie de la version 0.39
Cette version vous permet d'utiliser d'autres autorités de certification à l'aide du paramètre --ca.
Ces autorités sont buypass.com, google.com, letsencrypt.org, ssl.com, zerossl.com.
Pour Windows, rendez vous ici et téléchargez la version qui correspond à votre machine :
- Windows 32 Bits (https://github.com/do-know/Crypt-LE/releases/download/0.39/le32.zip)
- Windows 64 bits (https://github.com/do-know/Crypt-LE/releases/download/0.39/le64.zip)
Retrouvez toute la doc à ce sujet sur le site Github du projet :
https://github.com/do-know/Crypt-LE#other-certificate-providers-and-custom-acme-servers (https://github.com/do-know/Crypt-LE#other-certificate-providers-and-custom-acme-servers)
Mise à jour du 30 septembre 2021
Mise à jour des liens vers l'exécutable Windows de la bibliothèque Perl Crypt::LE (le.exe) suite à la sortie de la version 0.38
Cette version a été créée pour palier au problème de certificat racine expiré de Lets Encrypt, DST Root CA X3.
A tous, il vous faut renouveler ou recréer vos certificats avec cette nouvelle version.
Pour Windows, rendez vous ici et téléchargez la version qui correspond à votre machine :
- Windows 32 Bits (https://github.com/do-know/Crypt-LE/releases/download/0.38/le32.zip)
- Windows 64 bits (https://github.com/do-know/Crypt-LE/releases/download/0.38/le64.zip)
Pour les utilisateurs de la version Perl, mettez à jour le.pl (Crypt::LE), bien entendu, mais aussi la dépendance Mozilla::CA pour une utilisation sans problème avec les produits Mozilla (Firefox, Thunderbird, etc...) mais aussi avec Perl lui même.
Mise à jour du 10 octobre 2018
Mise à jour du tuto et de la config proposée suite au "déclassement" du protocole TLSv1 & TLSv1.1 de la liste des protocoles sûrs.
- Ce tuto est disponible au format .PDF (https://chez-oim.org/web-download/lets-encrypt.pdf) (Signature d'intégrité [PGP/GPG .sig (https://chez-oim.org/web-download/lets-encrypt.pdf.sig)])
La signature vous permet de vérifier que le fichier PDF n'a pas été modifié si vous le téléchargez sur un site autre que chez-oim.org. Elle vous permet également de contrôler que le fichier n'a pas été corrompu ou altéré lors de son téléchargement.
Les clés PGP/GnuPG et le certificat de la signature interne au fichier PDF sont disponibles ici (https://chez-oim.org/pgp/).
Introduction (#post_intro)
Risque de sécurité avec les clés RSA (#post_security)
Commençons en préparant les dossiers de validation (/.well-known/acme-challenge) (#post_commencer)
Préparation pour Windows (#post_prepa1)
Préparation pour Linux (#post_prepa2)
Créer les clés et le certificat CSR (#post_csr)
Obtenir le certificat SSL (#post_certificat)
Installer le certificat (#post_instal)
Observer le contenu du certificat SSL (#post_voircertif)
Exemple de script Bash pour renouvellement automatique du certificat Let's Encrypt sous Linux. (#post_renew)
Exemple de script Batch pour renouvellement automatique du certificat Let's Encrypt sous Windows (avec WAMP ou EasyPHP, par exemple) (#post_renew_win)
Révoquer un certificat (#post_revoke)
Obtenir un certificat de sécurité wildcard (générique) (#post_wildcard) ACME V2
(Haut de Page) (#post_haut)
CE TUTO EST CONÇU POUR LES SERVEURS APACHE !
Vous pouvez le suivre pour obtenir votre certificat, mais les paramétrages sont destinés à APACHE !
ATTENTION ! Ce tuto est de niveau "geek à l'aise avec le SSL et la configuration d'un serveur Apache !" (https://static.chez-oim.org/Themes/core/images/star.gif)(https://static.chez-oim.org/Themes/core/images/star.gif)(https://static.chez-oim.org/Themes/core/images/star.gif)
Plus vous en saurez, mieux ce sera. Si vous êtes un noob, il est possible d'y arriver, mais ce ne sera pas facile pour vous !
De toute façon, comme d'hab, pour les questions, insultes, menaces, vous pouvez répondre. C'est pas la peine d'être inscrit. :)
Salut tous,
Dans ce nouveau tuto, je vais essayer de vous aider à créer un certificat de requête (CSR) afin d'obtenir un vrai certificat de sécurité auprès de Lets Encrypt (https://letsencrypt.org/).
Ensuite, nous installerons ce certificat sur notre serveur pour pouvoir bénéficier d'une connexion sécurisée.
Lets Encrypt est aujourd'hui une autorité de certification autorisée à délivrer des certificats de sécurité gratuits reconnus par tous les navigateurs web.
Le seul vrai problème de Lets Encrypt et qu'ils délivrent des certificats valables 90 jours seulement. A la longue, quand vous serez familiarisé avec la façon de faire, ce ne sera plus gênant, d'autant plus qu'il est possible d'automatiser le renouvellement.
Il existe des outils gratuits entièrement automatisés (comme "certbot", par exemple) pour obtenir et renouveler les certificats de sécurité.
Ces outils ont un gros inconvénient. Ils fonctionnent sur des config "classiques".
Ici, vous le verrez, nous avons une configuration "exotique", avec des sous domaines, qui ne fonctionnerait pas avec certbot ou n'importe quel autre outil automatique.
Ce tuto est parfaitement valable pour Linux !
Il vous suffit d'avoir Perl sur votre serveur et d'avoir installé le module Crypt::LE qui vous donnera accès au script le.pl
C'est la version exécutable de ce script que nous utiliserons pour obtenir notre certificat de sécurité sous Windows.
Sous Linux, la démarche restera la même et la syntaxe sera rigoureusement identique. Il suffira juste de convertir le.exe en le.pl, c'est tout.
(Haut de Page) (#post_haut)
(https://static.chez-oim.org/img/warning.gif) ATTENTION ! RISQUE DE SÉCURITÉ MAXIMAL ! (https://static.chez-oim.org/img/warning.gif)
Dans ce tuto, nous allons manipuler ce qu'on appelle des clés RSA.
Il existe deux types de clés RSA qui sont indissociables. La clé privée et la clé publique. Ces 2 clés sont liées, elles sont inséparables.
Sur votre certificat de sécurité, la clé publique apparaitra et c'est entièrement normal. La clé publique, comme son nom l'indique, est destinée à être rendue publique.
La clé privée est secrète et elle doit le rester ! Elle ne doit être divulguée sous aucun prétexte ! Seul votre site a besoin de la clé privée. Tous les autres sites de la planète ne doivent pas connaitre cette clé ! Même si c'est demandé gentiment, ne donnez jamais votre clé privée !
Une autorité de certification, l'autorité qui vous délivrera votre certificat de sécurité ne doit, elle non plus, pas connaitre votre clé privée ! Dans notre exemple, LetsEncrypt pourra vérifier que nous possédons la clé privée en analysant la signature de notre demande de certificat à l'aide de la clé publique et uniquement de la clé publique.
C'est cette clé privée qui fera qu'on sait que c'est vous et votre certificat sur un site sécurisé. C'est cette clé qui servira à établir une connexion sécurisée sur votre site.
Si quelqu'un connait cette clé privée, il pourra créer un "vrai faux certificat" et/ou intercepter la clé générée pour établir la connexion sécurisée et ainsi lancer une attaque de l'homme du milieu (https://fr.wikipedia.org/wiki/Attaque_de_l%27homme_du_milieu).
J'insiste et j'insiste lourdement ! Votre clé privée doit rester secrète !
D'une façon générale, quand vous travaillez avec des clés RSA, la clé privée est secrète, elle est à vous seul.
La clé publique peut être divulguée sans aucun souci et elle doit quasiment toujours être divulguée.
(Haut de Page) (#post_haut)
Commençons
La façon de faire est la même sous Linux que sous Windows. Quand une manipulation spéciale pour un système sera demandée, cela sera précisé.
Sur votre serveur, Rendez vous à la racine de celui ci (le point d'entrée où se trouve index.php ou index.html). La racine de votre site est le dossier où atterrissent chaque visiteur ou membre.
Créez un dossier que vous appellerez .well-known/.
Ensuite, dans ce dossier .well-known/, créez un autre dossier qui s'appellera acme-challenge/.
Voilà, votre site contient les dossiers .well-known/acme-challenge/, il est prêt pour répondre aux requêtes de vérification de Lets Encrypt.
(Haut de Page) (#post_haut)
Préparation pour Windows
Maintenant, nous allons télécharger l'outil LE de la bibliothèque Crypt::LE qui sera indispensable pour générer vos clés et votre certificat de requête en vue d'obtenir un vrai certificat signé par Lets Encrypt.
Pour Windows, rendez vous ici et téléchargez la version qui correspond à votre machine :
- Windows 32 Bits (https://github.com/do-know/Crypt-LE/releases/download/0.39/le32.zip)
- Windows 64 bits (https://github.com/do-know/Crypt-LE/releases/download/0.39/le64.zip)
Ces archives contiennent un fichier qui ne nécessite aucune installation, vous pouvez l'utiliser directement. Aucune dépendance n'est nécessaire, y compris OpenSSL. Ce fichier embarque tout ce dont il a besoin.
Ce tuto est maintenu à jour, mais si vous voulez être certain de télécharger une version toujours à jour, vous pouvez aller directement sur la page de téléchargements Github du projet (https://github.com/do-know/Crypt-LE/releases/latest).
Vous n'avez plus qu'à choisir le téléchargement qui correspond à votre machine (le32.zip & le64.zip pour win 32 ou 64 bit).
Si vous n'êtes pas intéressé par la façon de faire sous Linux, vous pouvez passer directement à la création du certificat de requête (CSR) (#post_csr).
(Haut de Page) (#post_haut)
Préparation pour Linux
Sous Linux avec Perl, utilisez CPAN.
Installez le module Crypt::LE
Si il vous manque des modules dont Crypt::LE a besoin, cela sera indiqué et l'installation stoppée. Installez les dépendances indiquées et reprenez l'installation de Crypt::LE
Les dépendances PERL s'installent automatiquement avec Crypt::LE.
En cas de gros problème pour installer les dépendances, n'omettez pas le paquet openssl-devel.
Vous êtes bien conscient que OpenSSL est absolument nécessaire, si ce n'est pas le cas, stoppez tout ici. Ce n'est pas la peine d'aller plus loin, ce sujet semble vous dépasser. Faites attention si vous continuez sans savoir ce que vous faites !
Pour CentOS/Fedora/Redhat
yum install openssl-devel
Ubuntu/Debian :
sudo apt-get install libssl-dev
Si vous avez Perl mais n'avez pas CPAN, installez le :
Pour CentOS/Fedora/Redhat
Ubuntu/Debian :
apt-get install build-essential
(Haut de Page) (#post_haut)
Entrons dans le vif du sujet en créant les clés et le certificat de requête (CSR)
Vous pouvez vous aider avec le site ZeroSSL.com (https://zerossl.com/) qui pourra même vous aider à obtenir des certificats "auto-signés" pour travailler en local et bien plus encore lorsque vous aurez votre CSR (ne donnez jamais votre clé privée ! Un CSR, oui. Une clé, non !).
Pour Windows, dans chaque fichier .zip, vous trouverez un fichier le32.exe ou le64.exe selon la version choisie.
Renommez votre fichier en le.exe
Ca me permettra de donner les mêmes instructions pour Windows 32bits et 64bits. Rassurez vous, ça ne changera rien.
Sous Linux, vous utiliserez le.pl qui présente exactement la même syntaxe que pour Windows.
Imaginons que nous souhaitons un certificat pour le domaine example.com
Ce domaine possède les sous domaines suivants et nous voulons aussi un certificat pour ces sous domaines :
www.example.com
static.example.com
mail.example.com
Créez un dossier qui ne soit pas accessible au public et déplacez-y le.exe (le.pl sera accessible de partout).
Si vous souhaitez que ce fichier le.exe soit accessible de partout, peu importe le dossier dans lequel vous travaillez, je vous recommande de le placer dans le dossier C:\windows. De cette façon, vous n'aurez pas à copier/déplacer le fichier selon le dossier où vous vous trouvez pour travailler.
Vous pouvez également en placer une copie sur clé USB pour dépanner les copains qui auraient des soucis de SSL avec leur WAMP.
Sous Windows, avec WAMP, le dossier créé sera par exemple : C:\Wamp\ssl dans le cas où la racine du site est C:\Wamp\www
Sous Linux, ce dossier pourra être : /var/ssl dans le cas où la racine du site est /var/www
C'est vous qui choisissez comme vous en avez envie. Cependant, dites vous bien que le dossier devra être accessible pour le serveur.
Dans ce dossier seront stockés la clé privée et le certificat de sécurité. Le public ne doit pas pouvoir accéder à ce dossier.
Soyez vigilant ! Pas de config du style example.com/ssl, ce serait la plus grosse boulette que vous ayez faite.
Ouvrez une invite de commande (la console sous Linux) et placez vous dans le dossier créé.
Sous Windows, appuyez sur la touche "Windows" et entrez "CMD" suivit de entrée. Sous Linux, ouvrez la console ou le shell, c'est pareil.
Rendez vous dans le dossier créé, pour Windows :
Ou, sous Linux :
Sous Windows, nous allons utiliser le.exe et entrer ce qui suit :
le.exe --key account-key.key --email "hostmaster@example.com" --csr example.com.csr --csr-key example.com.key --domains "example.com,www.example.com,static.example.com,mail.example.com" --generate-missing --generate-only
Sous Linux, vous entrerez :
le.pl --key account-key.key --email "hostmaster@example.com" --csr example.com.csr --csr-key example.com.key --domains "example.com,www.example.com,static.example.com,mail.example.com" --generate-missing --generate-only
Bien entendu, vous modifierez le nom de domaine et le mail pour les remplacer par les votres. (Il n'existe aucun risque de SPAM avec le mail)
Suite à ceci, vous allez obtenir plusieurs fichiers :
account-key.key : Il s'agit de votre clé privée vous permettant de vous identifier chez Lets Encrypt. Il s'agit de la clé de votre compte, elle n'a rien à voir avec votre certificat mais elle doit aussi rester secrète. Cette clé peut être utilisée pour révoquer votre certificat.
Le mail fourni ne sera utilisé que pour vous prévenir en cas de problème avec votre certificat. Il est optionnel mais recommandé.
example.com.csr : C'est ce fichier qui contient votre demande de certificat. Il a été signé avec votre clé privée et il contient la clé publique.
example.com.key : Il s'agit de votre clé privée qui doit rester secrète. C'est cette clé qui servira sur votre serveur pour établir une connexion sécurisée. C'est également cette clé qui fera de vous le propriétaire officiel de votre certificat de sécurité.
Si vous perdez cette clé, votre certificat ne sera plus utilisable et vous êtes bon pour en demander un autre avec une nouvelle clé.
(Haut de Page) (#post_haut)
Demandons notre certificat !
Attention ! Chacun des domaines ou sous domaines indiqués dans le CSR, le certificat de requête, doit pointer sur votre serveur et avoir accès au dossier /.well-known/acme-challenge/
Si ce n'est pas le cas, vous n'aurez pas votre certificat.
Tout est en règle ? Allons-y !
Pour Windows, la demande sera sous cette forme :
le.exe --key account-key.key --email "hostmaster@example.com" --csr example.com.csr --crt example.com.crt --generate-missing --unlink --path "C:\wamp\www\.well-known\acme-challenge" --live
Pour Linux, ce sera pareil mais avec le.pl :
le.pl --key account-key.key --email "hostmaster@example.com" --csr example.com.csr --crt example.com.crt --generate-missing --unlink --path "/var/www/.well-known/acme-challenge" --live
Bien sûr, modifiez le chemin après le paramètre --path pour indiquer où se trouve /.well-known/acme-challenge selon votre configuration.
Le.exe ou le.pl créera des fichiers de signature dans le dossier afin de valider vos domaines et sous domaines qui seront lus par Lets Encrypt pour validation puis il détruira ces fichiers immédiatement après.
Si tout se passe bien, vous allez obtenir votre certificat. Dans notre exemple il s'appellera example.com.crt
Il ne reste plus qu'à l'installer sur le serveur.
Si vous souhaitez vous entrainer, retirez le paramètre "--live". Vous obtiendrez un "Fake certificat", un faux certificat. Vous replacerez ce paramètre "--live" quand vous serez prêt. Ca vous permettra d'étudier le certificat obtenu afin de vérifier que tout est bien là. Ces fakes certificats n'ont aucune valeur, vous pouvez en demander autant que vous le voulez pour vérifier que tout se passe bien.
Enfin, quand je dis "autant que vous le voulez", c'est presque ça mais pas tout à fait. Dans un environnement de test, la limite est fixée à 30.000 certificats par semaine et par domaine, 60 vérifications échouées par heure, 50 comptes par adresse IP et par période de 3 heures, etc. Alors doucement quand même. ;)
Pour plus d'infos, lisez la documentation de test Lets Encrypt (Staging) (https://letsencrypt.org/docs/staging-environment/) (en anglais).
(Haut de Page) (#post_haut)
Installer le certificat sur le serveur
Vous avez besoin de 3 choses.
- La clé privée.
- Le certificat de vos domaines et sous domaines.
- Le certificat intermédiaire (normalement, ce certificat est fourni avec le certificat des domaines, il est compris dedans) et est compris par Apache 2.4 avec la directive Apache SSLCertificateChainFile.
On va faire plus compliqué, pour que Apache 2.2 soit utilisable, téléchargez le certificat intermédiaire ou Bundle ici (https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem) et stockez le dans le même dossier que les autres.
Attention quand même. Si vous utilisez Apache 2.2, pensez à mettre à jour votre version de Apache.
Il n'est jamais recommandé d'utiliser de vieilles versions de Apache/PHP.
Maintenant, rendez vous dans la configuration de Apache.
Vous devriez trouver un fichier httpd-ssl.conf dans le dossier extra/
L'arborescence est comme ceci à peu de choses prêt :
httpd.conf ---
|
extra/ ---
|
httpd-ssl.conf
Vous pouvez vous inspirer de httpd.conf pour avoir une idée des chemins.
Dans ce fichier, nous allons créer un Virtual Host puis nous réglerons les chiffrages autorisés.
En tête de fichier, entrez ce qui suit en modifiant les chemins pour qu'ils pointent vers vos certificats (vous avez 2 certificats, le votre mais aussi le Bundle, celui de l'autorité) et votre clé privée.
Listen 443
<VirtualHost *:443>
# General setup for the virtual host
ServerName example.com
ServerAlias www.example.com
ServerAlias mail.example.com
ServerAlias static.example.com
DocumentRoot "C:/wamp/www"
ServerAdmin noreply@example.com
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
SSLCertificateFile "c:/wamp/ssl/example.com.crt"
SSLCertificateKeyFile "c:/wamp/ssl/example.com.key"
SSLCACertificateFile "c:/wamp/ssl/lets-encrypt-x3-cross-signed.pem"
</VirtualHost>
Sous Linux, vous n'avez qu'à simplement modifier les chemins des dossiers (/var/ssl dans notre exemple).
Ensuite, nous allons nous intéresser aux chiffrages autorisés ainsi qu'aux logs.
CustomLog "C:/wamp/logs/access_ssl.log" \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
ErrorLog "C:/wamp/logs/apache_error.log"
TransferLog "C:/wamp/logs/access.log"
# modern configuration, tweak to your needs
SSLProtocol all -SSLv3 -SSLv2 -TLSv1 -TLSv1.1
SSLCipherSuite HIGH:!RSA:!RC4:!3DES:!DES:!IDEA:!MD5:!aNULL:!eNULL:!EXP
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets on
Le protocole SSL n'est plus assez sûr, il présente des vulnérabilités, il est donc interdit sur notre serveur. Seul le TLS est à la hauteur.
Cependant, le TLS 1 est considéré comme plus assez sûr depuis le mois de juin 2018.
De même, vous remarquerez que le TLS 1.1 n'est pas pris en charge. Aucun appareil ni logiciel ne l'utilisent, ce protocole semble être le grand délaissé du monde SSL. Seul le TLS 1.2 est proposé. Ce protocole est utilisé par tous les appareils et navigateurs modernes voir un peu plus ancien.
TLS 1.1 ne sert à rien du tout et TLS 1 n'est plus assez sûr. Vu qu'il ne seront pas utilisés, nous les interdisons donc. Ca ne sert à rien de laisser une porte ouverte et ce n'est pas prudent pour la sûreté de vos communications.
Ensuite, nous autorisons certaines suites de chiffrage parmi les plus solides (HIGH) et nous refusons les autres moins fiables (!RSA:!RC4:!3DES:!DES:!IDEA etc.). Si vous avez vu que RSA n'est pas utilisé, ne prenez pas peur. RSA ne peut être utilisé que pour l'échange de clés, ce qui n'est plus sûr depuis l'année 2017. RSA n'est jamais utilisé pour chiffrer une connexion, la longueur des clés utilisées est un handicap majeur en terme de performances.
Une fois redémarré votre serveur (le redémarrage du serveur est une obligation pour qu'il charge le certificat de sécurité) sous Windows ou le service HTTPD rechargé sous Linux, rendez vous sur ce site : https://www.ssllabs.com/ssltest/ (https://www.ssllabs.com/ssltest/) pour tester votre installation SSL.
En espérant que tout va pour le mieux.
Et voilà, désormais votre site est accessible en HTTPS ! :)
ATTENTION !
Un certificat de sécurité n'a rien de secret et il ne faut pas y "cacher" des sous domaines que vous souhaitez garder pour vous.
Votre certificat va participer à la "transparence des certificats de sécurité" et il sera vérifié par tous les géants du web.
Vous pourrez le retrouver ici : https://crt.sh/ (https://crt.sh/). Ce site semble être victime de son succès et il peut arriver qu'il vous affiche des erreurs 404 qui n'en sont pas ou qu'il soit carrément inaccessible. Patientez, le site est surchargé.
La transparence des certificats est nécessaire afin qu'il n'y ait pas de "triche" comme ça a déjà été le cas avec StartSSL (Startcom) et Woosign qui a été gravement puni en voyant tous ses certificats et ceux de ses clients invalidés.
Ce site en a été victime et notre certificat délivré par Startcom et valable 3 ans n'a plus aujourd'hui aucune valeur. Nous avons donc été obligés de changer dans l'urgence. :iq:
(Haut de Page) (#post_haut)
A quoi va ressembler notre certificat ?
Prenons le certificat de ce site pour se simplifier la vie. Je vous le répète, un certificat de sécurité n'a rien de secret, vous pouvez récupérer le certificat de ce site ou d'un autre si ça vous chante.
Par contre, si vous n'avez pas la clé privée du certificat, il pourra servir uniquement de décoration au dessus de la télé si vous trouvez ça joli...
Ouvrez votre certificat.
La première chose que vous remarquerez, c'est le chemin d'accès jusqu'à l'autorité de certification qui permettra à votre navigateur web de valider le certificat ou pas.
(https://static.chez-oim.org/img/certif-root.png)
Ensuite, en regardant plus loin, vous verrez apparaitre pour quel site le certificat a été délivré.
Ca se passe à la ligne "Objet"
(https://static.chez-oim.org/img/certif1-le.png)
Et ensuite, vous aurez la liste des autre domaines ou sous domaines validés pour lesquels votre certificat fonctionnera.
Il s'agit de la ligne "Autre nom de l'objet" (San).
(https://static.chez-oim.org/img/certif2-le.png)
Faites très attention aux dates de validité du certificat ! Le certificat devra être renouvelé avant sa date de péremption.
Les navigateurs web refuseront d'utiliser un certificat qui n'est plus valide. Ils seront tellement alarmistes que n'importe quel internaute ne prendra pas le risque d'utiliser un certificat périmé et ne viendra plus sur votre site.
(https://static.chez-oim.org/img/ssl_unvalid.png)
(Haut de Page) (#post_haut)
Exemple de script Bash pour renouvellement automatique du certificat sous Linux
Renouveler le certificat manuellement tous les 3 mois est une tâche qui devient vite pénible.
Voilà donc pourquoi je vous propose un petit script pour Linux qui se chargera de renouveler le certificat automatiquement. Il vous suffit de créer une tâche cron pour que ce script se lance tous les jours.
Ce script lancera le renouvellement de votre certificat Let's Encrypt si sa date de fin de validité est inférieure à 30 jours.
Pour Windows, vous avez un exemple de script un peu plus bas.
Dans votre dossier ./ssl, créez un sous dossier ssl-renew/.
Dans ce sous dossier, placez votre clé privée de compte Let's Encrypt, votre clée privée SSL, votre certificat de requête CSR et aussi le certificat SSL (je vous expliquerai plus loin pourquoi tout ce bazard).
Voilà donc ce script : (vous modifierez les chemins et adresse mail selon votre configuration)
#!/bin/bash
if ! openssl x509 -checkend 2592000 -in /var/ssl/ssl-renew/example.com.crt
then
echo "Renouvellement du certificat SSL." &>TMP_SSL1
/usr/local/bin/le.pl --key "/var/ssl/ssl-renew/account-key.key" --csr "/var/ssl/ssl-renew/example.com.csr" --crt "/var/ssl/ssl-renew/example.com.crt" --generate-missing --unlink --path "/var/www/html/.well-known/acme-challenge" --live --renew 30 &>TMP_SSL2
cp -f /var/ssl/ssl-renew/example.com.crt /var/ssl/example.com.crt
cp -f /var/ssl/ssl-renew/example.com.csr /var/ssl/example.com.csr
cp -f /var/ssl/ssl-renew/example.com.key /var/ssl/example.com.key
chown -R root:root /var/ssl/
systemctl reload httpd &>TMP_SSL3
cat TMP_SSL1 TMP_SSL2 TMP_SSL3 | mail -s "Renouvellement du certificat SSL LetsEncrypt" webmaster@example.com
rm -f TMP_SSL*
else
echo "Renouvellement du certificat SSL non nécessaire." # | mail -s "Certificat SSL LetsEncrypt valide" webmaster@example.com
fi
La première ligne utilise openssl pour tester la fin de validité du cetificat, en secondes, afin de ne pas lancer le.pl et des requêtes inutiles vers Let's Encrypt, tous les jours.
Un peu de respect ne peut pas faire de mal. Inutile d'interroger les serveurs Let's Encrypt si ce n'est pas nécessaire.
La suite du script se charge de renouveler le certificat si cela est nécessaire et de recharger la nouvelle configuration si le certificat a été renouvelé. Dans la foulée, vous recevrez un mail vous donnant tous les détails du renouvellement afin de savoir si tout c'est bien passé.
Vous remaquerez que le groupe du dossier /var/ssl/ et son contenu est passé à root:root pour plus de sureté.
Pas d'inquiétudes ! Apache pourra accéder à ce dossier. Lorsqu'il démarre, Apache a les permissions root. Ce n'est qu'une fois démarré qu'il prend le nom d'utilisateur et les autorisations apache (ou httpd).
Pourquoi renouveler le certificat dans un autre dossier pour le copier ensuite dans son dossier de "travail" ?
C'est la seule méthode que j'ai trouvée pour pouvoir changer de clé. Si vous avez une meilleure idée, je suis preneur !
Si vous décidez de changer de clé pour votre certificat, ce sera très simple. Il vous suffira de créer la nouvelle clé, de générer le nouveau certificat CSR et de copier le tout dans ssl-renew/. Au prochain renouvellement du certificat, c'est cette nouvelle clé qui sera utilisée puis la clé et le nouveau certificat seront copiés dans le dossier SSL de Apache.
Si tout se passe correctement, vous recevrez un mail ayant un contenu similaire à celui-ci lors du renouvellement :
Renouvellement du certificat SSL.
2018/01/01 00:30:03 [ ZeroSSL Crypt::LE client v0.26 started. ]
2018/01/01 00:30:03 Loading an account key from /var/www/ssl/ssl-renew/account-key.key
2018/01/01 00:30:03 Loading a CSR from /var/www/ssl/ssl-renew/chez-oim.org.csr
2018/01/01 00:30:03 Checking certificate for expiration (local file).
2018/01/01 00:30:03 Expiration threshold set at 30 days, the certificate expires in 29 days - will be renewing.
2018/01/01 00:30:04 Registering the account key
2018/01/01 00:30:09 The key is already registered. ID: XXXXXXXX
2018/01/01 00:30:09 Current contact details: dans_ton_cul@chez-oim.org
2018/01/01 00:30:30 Successfully saved a challenge file '/var/www/html/.well-known/acme-challenge/5FQo7DyvIOoPnfSun6yl61MpD9ER-2f1CGI5N6YqW4M' for domain 'chez-oim.org'
2018/01/01 00:30:30 Successfully saved a challenge file '/var/www/html/.well-known/acme-challenge/55ehka3_yRyHYAHSRcNqAPe1gzzeBMSauwycc52HJCM' for domain 'www.chez-oim.org'
2018/01/01 00:30:30 Successfully saved a challenge file '/var/www/html/.well-known/acme-challenge/r_8DpOcjaEES5ByPB_RQdgToAl8DHumZFIVQaWL8RhI' for domain 'static.chez-oim.org'
2018/01/01 00:30:30 Successfully saved a challenge file '/var/www/html/.well-known/acme-challenge/d3GgjJ2-PbKiHl3C8qt-ovZsHEzFlyMD7h99tCV0CV8' for domain 'mail.chez-oim.org'
2018/01/01 00:30:30 Successfully saved a challenge file '/var/www/html/.well-known/acme-challenge/MS8ESOStnvOyukdg9BYMDr7LkkY34M8o4PI2nI-E_D8' for domain 'ban.chez-oim.org'
2018/01/01 00:30:35 Domain verification results for 'chez-oim.org': success.
2018/01/01 00:30:35 Challenge file '/var/www/html/.well-known/acme-challenge/5FQo7DyvIOoPnfSun6yl61MpD9ER-2f1CGI5N6YqW4M' has been deleted.
2018/01/01 00:30:38 Domain verification results for 'www.chez-oim.org': success.
2018/01/01 00:30:38 Challenge file '/var/www/html/.well-known/acme-challenge/55ehka3_yRyHYAHSRcNqAPe1gzzeBMSauwycc52HJCM' has been deleted.
2018/01/01 00:30:42 Domain verification results for 'static.chez-oim.org': success.
2018/01/01 00:30:42 Challenge file '/var/www/html/.well-known/acme-challenge/r_8DpOcjaEES5ByPB_RQdgToAl8DHumZFIVQaWL8RhI' has been deleted.
2018/01/01 00:30:46 Domain verification results for 'mail.chez-oim.org': success.
2018/01/01 00:30:46 Challenge file '/var/www/html/.well-known/acme-challenge/d3GgjJ2-PbKiHl3C8qt-ovZsHEzFlyMD7h99tCV0CV8' has been deleted.
2018/01/01 00:30:49 Domain verification results for 'ban.chez-oim.org': success.
2018/01/01 00:30:49 Challenge file '/var/www/html/.well-known/acme-challenge/MS8ESOStnvOyukdg9BYMDr7LkkY34M8o4PI2nI-E_D8' has been deleted.
2018/01/01 00:30:49 Requesting domain certificate.
2018/01/01 00:30:50 Requesting issuer's certificate.
2018/01/01 00:30:51 Saving the full certificate chain to /var/www/ssl/ssl-renew/chez-oim.org.crt.
2018/01/01 00:30:51 The job is done, enjoy your certificate! For feedback and bug reports contact us at [ https://ZeroSSL.com | https://Do-Know.com ]
(Haut de Page) (#post_haut)
Exemple de script Batch pour renouvellement automatique du certificat sous Windows (avec WAMP ou EasyPHP, par exemple)
Comme pour Linux, dans votre dossier ./ssl, créez un sous dossier ssl-renew/.
Dans ce sous dossier, placez votre clé privée de compte Let's Encrypt, votre clée privée SSL, votre certificat de requête CSR et aussi le certificat SSL. N'ommetez pas de copiez également l'exécutable le.exe
Sous Windows, vous utilisez l'exécutable le.exe que nous avons toujours utilisé jusqu'à présent.
C'est ce script qui renouvellera votre certificat (créez un fichier *.bat que vous appellerez lors du renouvellement)
Vous possédez OpenSSL pour Windows :
@echo off
openssl x509 -checkend 2592000 -in c:\wamp\ssl\ssl-renew\example.com.crt
if errorlevel 1 (
c:\wamp\ssl\ssl-renew\le.exe --key "c:\wamp\ssl\ssl-renew\account-key.key" --csr "c:\wamp\ssl\ssl-renew\example.com.csr" --crt "c:\wamp\ssl\ssl-renew\example.com.crt" --generate-missing --unlink --path "c:\wamp\www\.well-known\acme-challenge" --live --renew 30
copy c:\wamp\ssl\ssl-renew\example.com.crt c:\wamp\ssl\example.com.crt
copy c:\wamp\ssl\ssl-renew\example.com.csr c:\wamp\ssl\example.com.csr
copy c:\wamp\ssl\ssl-renew\example.com.key c:\wamp\ssl\example.com.key
echo.
net stop wampapache64
net start wampapache64
rem php -f c:\wamp\ssl\script_annonçant_le_renouvellement.php
)
Vous ne possédez pas OpenSSL pour Windows :
@echo off
c:\wamp\ssl\ssl-renew\le.exe --key "c:\wamp\ssl\ssl-renew\account-key.key" --csr "c:\wamp\ssl\ssl-renew\example.com.csr" --crt "c:\wamp\ssl\ssl-renew\example.com.crt" --generate-missing --unlink --path "c:\wamp\www\.well-known\acme-challenge" --live --renew 30 --issue-code 99
if errorlevel 99 (
copy c:\wamp\ssl\ssl-renew\example.com.crt c:\wamp\ssl\example.com.crt
copy c:\wamp\ssl\ssl-renew\example.com.csr c:\wamp\ssl\example.com.csr
copy c:\wamp\ssl\ssl-renew\example.com.key c:\wamp\ssl\example.com.key
echo.
net stop wampapache64
net start wampapache64
rem php -f c:\wamp\ssl\script_annonçant_le_renouvellement.php
)
ATTENTION !
Sous Windows, vous n'aurez pas la possibilité de recevoir un Email si le certificat est renouvelé. Soyez vigilants lors du renouvellement !
Vous remarquerez une ligne en commentaire (débutant par "rem") qui exécute un script PHP. Vous êtes libres de retirer ce commentaire, de renommer le script et de le créer pour qu'il vous envoie un mail ou toute autre information lors du renouvellement.
Pour lancez ce script Batch toutes les 24 heures, cette horreur appelée "Planificateur de Tâches" de Windows vous attend...
Cliquez sur Démarrer et Ouvrez le planificateur de tâches en tapant son nom puis cliquez sur Créer une tâche (pas Tâche de base !)
Dans la fenêtre qui s'ouvre, au premier onglet, donnez un nom à votre tâche et une description si le coeur vous en dit.
Cliquez sur Utilisateurs ou groupe... suivi de Avancé puis Rechercher. Là, sélectionnez l'utilisateur Administrateur et validez (Le script doit être exécuté avec les privilèges Administrateur sinon le service Apache ne pourra pas être redémmarré automatiquement).
Ensuite, passez à l'onglet Déclencheurs dans lequel vous allez définir l'heure d'exécution du script en cliquant sur Nouveau et vous cocherez la case Chaque jour et Répéter chaque 1 jour.
Et enfin, dans l'onglet Actions, vous n'avez plus qu'à cliquez sur Nouveau et indiquer l'emplacement de votre script.
Ouf ! C'est fini ! Ah oui, ça n'a rien à voir avec la cron de Nunux, hein ?
Pourquoi renouveler le certificat dans un autre dossier pour le copier ensuite dans son dossier de "travail" ?
C'est la seule méthode que j'ai trouvée pour pouvoir changer de clé. Si vous avez une meilleure idée, je suis preneur !
Si vous décidez de changer de clé pour votre certificat, ce sera très simple. Il vous suffira de créer la nouvelle clé, de générer le nouveau certificat CSR et de copier le tout dans ssl-renew/. Au prochain renouvellement du certificat, c'est cette nouvelle clé qui sera utilisée puis la clé et le nouveau certificat seront copiés dans le dossier SSL de Apache.
(Haut de Page) (#post_haut)
Mise à Jour : Obtenir un certificat Wildcard (Certificat générique)
On est d'accord que vous avez lu ce qui est ci-dessus, afin que vous sachiez obtenir un certificat avec les outils nécessaires installés.
Depuis l'adoption du protocole ACMEv2 par Lets Encrypt, au début du mois de mars 2018, adopté par la bibliothèque Crypt::LE depuis la version v0.30, il est désormais possible d'obtenir un certificat de sécurité wildcard (un certificat générique) auprès de Lets Encrypt.
Un certificat Wildcard permet d'avoir un certificat de sécurité fonctionnant avec un nombre illimité de sous domaines, même si ceux-ci n'existent pas à la création du certificat.
Le seul vrai souci réside dans l'obtention de ce certificat de sécurité. Seule une validation DNS est possible, aucune vérification HTTP n'est proposée comme avec un certificat "normal". Cela viendra certainement, mais ce n'est pas encore proposé.
Ceci vous obligera à créer des enregistrements DNS afin de valider les requêtes de vérification de Lets Encrypt et ce, sans aucune API disponible pour automatiser tout cela.
Il serait donc plus pratique de se tourner vers un outil proposant beaucoup d'APIs DNS comme acme.sh (cliquez pour voir le tuto acme.sh (https://chez-oim.org/index.php/topic,2171.0.html)).
Pour obtenir notre certificat, il ne sera pas nécessaire d'indiquer les sous domaines utilisés. Seul le domaine et le sous domaine wildcard (générique en français) seront utilisés. Par exemple : example.com et *.example.com.
Pour Windows, il vous faudra entrer ceci :
le.exe --key account-key.key --email "hostmaster@example.com" --csr example.com.csr --csr-key example.com.key --crt example.com.crt --domains "example.com,*.example.com" --generate-missing --handle-as dns --api 2 --live
Pour Linux, vous savez maintenant que la syntaxe est la même, il suffit simplement d'utiliser le.pl et pas le.exe :
le.pl --key account-key.key --email "hostmaster@example.com" --csr example.com.csr --csr-key example.com.key --crt example.com.crt --domains "example.com,*.example.com" --generate-missing --handle-as dns --api 2 --live
Bien entendu, vous remplacerez example.com par votre nom de domaine. Une fois le script lancé, il vous sera demandé de créer un enregistrement DNS TXT et d'appuyer sur entrée. Appuyez donc sur entrée.
Une seconde demande d'enregistrement DNS vous sera demandée et ensuite un appuis sur entrée. ATTENTION ! Cette seconde fois, n'appuyez pas sur entrée tout de suite !
Votre écran ressemblera à cette image ci-dessous :
(https://static.chez-oim.org/uploads/member_1/stock1/1523532359.png)
Dans notre exemple, il nous sera demandé de créer 2 enregistrements DNS TXT pour le sous domaine _acme-challenge.example.com (en bleu).
En rouge, une instruction vous est donnée afin de vérifier que les enregistrements DNS se sont propagés (la propagation est très rapide, Lets Encrypt interroge les DNS les plus proches du domaine, les DNS autoritaires).
Vous pouvez copier/coller l'instruction donnée pour l'utiliser dans une nouvelle console (fenêtre). N'interrompez pas le.pl/le.exe pour vérifier les enregistrements DNS ! Faites le dans une nouvelle console (fenêtre). Sinon, vous seriez contraint de tout recommencer.
N'essayez pas de créer d'enregistrement TXT pour le sous domaine *._acme-challenge.example.com. Le caractère wildcard n'est pas autorisé dans cette situation.
Une fois que vos enregistrements sont créés et propagés (2 minutes d'attente suffisent amplement), vous pouvez enfin appuyer un dernière fois sur la touche entrée et laisser faire.
Lets Encrypt va vérifier vos enregistrements DNS et il créera le certificat immédiatement après. Sinon, il vous sera mentionné ce qui ne va pas et il faudra tout recommencer.
Vous avez votre certificat wildcard ? Vous pouvez supprimer les enregistrements DNS et installer le certificat sur votre serveur.
(Haut de Page) (#post_haut)
Révoquer un certificat
Révoquer un certificat revient à l'invalider pour qu'il ne puisse plus être utilisé. Les raisons de la révocation d'un certificat sont nombreuses :
- Votre clé privée a été divulguée. Par sécurité, la révocation du certificat est une obligation !
- Vous avez perdu votre clé privée.
- Vous voulez ajouter un domaine/sous domaine sur un nouveau certificat. Il est plus prudent de révoquer l'ancien.
- Vous avez fait des essais sans passer par des "fakes certificats" et il est nécessaire de faire du ménage.
- Vous vendez votre domaine. Si ce n'est pas fait, le nouvel acquéreur vous demandera très certainement de révoquer tous les certificats concernant ce domaine.
- Etc, etc, etc...
La révocation ne sera pas immédiate, ne vous impatientez pas. Il faut plusieurs heures et chaque navigateur vérifie comme il veut les certificats.
Pour les geeks, il s'agira d'une révocation OCSP. Cela ira donc un peu plus vite que pour les listes CRL.
Quelques jours après une révocation, ne vous étonnez pas de voir un certificat inutilisable sur un navigateur mais parfaitement valable sur un autre.
La révocation d'un certificat est très simple. Vous aurez besoin de votre clé privée de compte Lets Encrypt et du certificat à révoquer.
Dans notre exemple, nous allons révoquer le certificat example.com.crt
Sous Linux, il faudra simplement entrer :
le.pl --key account.key --crt example.com.crt --revoke
Et pour Windows :
le.exe --key account.key --crt example.com.crt --revoke
Et voilà, c'est fini ! Vous pourrez vérifier que la révocation a bien été prise en compte sur le site crt.sh (https://crt.sh/).
Recherchez votre certificat et affichez le. Sur la page qui s'affiche, repérez la ligne Revocation et la colonne Status.
Là, cliquez sur Check. Le statut révoqué de votre certificat devrait apparaitre après un petit temps d'attente.
(https://static.chez-oim.org/uploads/member_1/stock1/1523955891.png)
Ce status apparait comme ceci :
(https://static.chez-oim.org/uploads/member_1/stock1/1523956610.png)
(https://static.chez-oim.org/Logo/logo_seul.png)
Mise à jour du 22 août 2017
Mise à jour des liens vers la nouvelle version des exécutables - v0.25
Mise à jour
Exemple de script Bash de renouvellement automatique du certificat de sécurité Let's Encrypt.
Renouveler le certificat manuellement tous les 3 mois est une tâche qui devient vite pénible.
Voilà donc pourquoi je vous propose un petit script pour Linux qui se chargera de renouveler le certificat automatiquement. Il vous suffit de créer une tâche cron pour que ce script se lance tous les jours.
Ce script lancera le renouvellement de votre certificat Let's Encrypt si sa date de fin de validité est inférieure à 30 jours.
Je suis désolé pour les utilisateurs Windows, il vous faudra adapter ce script pour en faire un Batch que vous lancerez depuis le planificateur de tâches. (il existe des domaines où Windows n'est plus à la hauteur du tout. Un serveur Apache SSL fait partie de ces domaines)
Dans votre dossier ./ssl, créez un sous dossier ssl-renew/.
Dans ce sous dossier, placez votre clé privée de compte Let's Encrypt, votre clée privée SSL, votre certificat de requête CSR et aussi le certificat SSL (je vous expliquerai plus loin pourquoi tout ce bazard).
Voilà donc ce script : (vous modifierez les chemins et adresse mail selon votre configuration)
#!/bin/bash
if ! openssl x509 -checkend 2592000 -in /var/ssl/ssl-renew/example.com.crt
then
echo "Renouvellement du certificat SSL." &>TMP_SSL1
/usr/local/bin/le.pl --key "/var/ssl/ssl-renew/account-key.key" --csr "/var/ssl/ssl-renew/example.com.csr" --crt "/var/ssl/ssl-renew/example.com.crt" --generate-missing --unlink --path "/var/www/html/.well-known/acme-challenge" --live --renew 30 &>TMP_SSL2
cp -f /var/ssl/ssl-renew/example.com.crt /var/ssl/example.com.crt
cp -f /var/ssl/ssl-renew/example.com.csr /var/ssl/example.com.csr
cp -f /var/ssl/ssl-renew/example.com.key /var/ssl/example.com.key
chown -R apache:apache /var/ssl/
systemctl reload httpd &>TMP_SSL3
cat TMP_SSL1 TMP_SSL2 TMP_SSL3 | mail -s "Renouvellement du certificat SSL LetsEncrypt" webmaster@example.com
rm -f TMP_SSL*
else
echo "Renouvellement du certificat SSL non nécessaire." # | mail -s "Certificat SSL LetsEncrypt valide" webmaster@example.com
fi
La première ligne utilise openssl pour tester la fin de validité du cetificat, en secondes, afin de ne pas lancer le.pl et des requêtes inutiles vers Let's Encrypt, tous les jours.
Un peu de respect ne peut pas faire de mal. Inutile d'interroger les serveurs Let's Encrypt si ce n'est pas nécessaire.
La suite du script se charge de renouveler le certificat si cela est nécessaire et de recharger la nouvelle configuration si le certificat a été renouvelé. Dans la foulée, vous recevrez un mail vous donnant tous les détails du renouvellement afin de savoir si tout c'est bien passé.
Pourquoi renouveler le certificat dans un autre dossier pour le copier ensuite dans son dossier de "travail" ?
C'est la seule méthode que j'ai trouvée pour pouvoir changer de clé. Si vous avez une meilleure idée, je suis preneur !
Si vous décidez de changer de clé pour votre certificat, ce sera très simple. Il vous suffira de créer la nouvelle clé, de générer le nouveau certificat CSR et de copier le tout dans ssl-renew/. Au prochain renouvellement du certificat, c'est cette nouvelle clé qui sera utilisée puis la clé et le nouveau certificat seront copiés dans le dossier SSL de Apache.
Le wildcard est prêt ! :)
Mise à jour du 12 avril 2018
Ce tuto a été mis à jour afin de donner la procédure permettant d'obtenir un certificat wildcard (générique).
Ah d'accord, c'est pour revoker le certificat.
Il suffit de faire :
le.pl --key account.key --crt example.com.crt --revoke
Et pour Windows :
le.exe --key account.key --crt example.com.crt --revoke
Sinon, tu détruis la clé privée du certificat pour que plus personne ne puisse l'utiliser et tu le laisses arriver à sa date de fin de validité.
Moins de 3 mois, ça passe vite.
Bonjour,
j'essai de suivre le tuto, mais je rencontre un soucis à la génération du certificat, j'ai ceci :
Path to save challenge files into should be a writable directofy for: C:\wamp\www.sav_interface_client\.well-know\acme-challenge
J'ai vérifie les droits, je vois rien d'anormale surtout mon invite de commande est en mode admin.
Si vous avez une idée je suis preneur :)
Cordialement,
Geoffrey.
Désolé, j'ai cliqué trop vite sur envoyer, le message d'erreur que j'ai copié contient une erreur, le bon est le suivant :
Path to save challenge files into should be a writable directofy for: C:\wamp\www\sav_interface_client\.well-know\acme-challenge
Désolé pour ce double post, pas d'édition en invité...
Tu as décoché mais il n'en tient pas compte ?! Alors ça c'est bizarre...
D'après ce que je lis, tu es déjà allé dans la partie sécurité pour donner le contrôle total du dossier à toi (l'utilisateur portant ton nom), l'administrateur et l'utilisateur système.
C'est bien ça ?
Si cette partie sécurité permet à tout le monde un contrôle total, tu ne devrais pas avoir de souci.
Sinon, au pire, crée un dossier C:\.well-know\acme-challenge
Ensuite, dans ta configuration Apache, dans httpd.conf, tu crées un alias :
Alias /.well-know/acme-challenge/ C:\.well-know\acme-challenge\
Bien entendu, quand tu utiliseras le fichier le.exe, tu modifieras le chemin pour qu'il soit C:\.well-know\acme-challenge
Pas nécessairement, tu peux demander une validation DNS. Regarde ce tuto à "obtenir un certificat Wildcard". Bien sûr, tu n'es pas obligé d'indiquer le sous domaine *.aviatechno quand tu fais ta demande de certificat.
Mais franchement, avec le.exe, c'est plutôt du type emmerdant, tout est manuel.
Mais bon, si c'est pour tests, c'est pas la mer à boire. Tu crées un ou des enregistrements DNS TXT et Lets Encrypt les valide.
Pour de l'automatique, il va falloir changer de technique avec Cygwin et acme.sh : Tuto : Certificats SSL wildcard sous Windows ou Linux avec acme.sh et Cloudflare (https://chez-oim.org/index.php/topic,2171.0.html)
Sinon, si c'est le fait de laisser ton dossier www ouvert aux quatre vents qui te chagrine, tu peux créer un alias pour Lets Encrypt afin de l'expédier dans un dossier "cul de sac" et le tour est joué.
Alias /.well-know/acme-challenge/ C:\.well-know\acme-challenge\
Ce qui me titille le plus, c'est le domaine utilisé. C'est aviatechno seul ? Pas de .net ? Tu utilises donc le hosts pour utiliser ce nom.
Si c'est le cas, Lets Encrypt risque d'avoir du souci pour trouver l'adresse IP de ton serveur local...
Bon, ben cette histoire de mod_md, c'est pas gagné !
J'ai bien lu ce que la documentation Apache dit, mais aucun résultat de concret !
En global, c'est à dire en dehors des vhost, j'ai fait tout comme il faut :
MDBaseServer off
MDCAChallenges http-01
MDCertificateAgreement accepted
MDCertificateAuthority https://acme-v02.api.letsencrypt.org/directory
MDPortMap http:80 https:433
MDPrivateKeys RSA 4096
MDRenewMode always
MDRenewWindow 30d
MDRequireHttps temporary
MDStoreDir "c:/ssl"
Ensuite, dans le vhost, j'ai fait aussi tout bien comme il faut :
MDomain XXXXXXX www.XXXXXXX
<VirtualHost *:443>
# General setup for the virtual host
LoadModule php7_module "E:/wamp/bin/php/php7.2.4/php7apache2_4.dll"
ServerName XXXXXXX
ServerAlias www.XXXXXXX
DocumentRoot "E:/wamp/www"
ServerAdmin noreply@XXXXXXX
<MDomain XXXXXXX>
MDCertificateFile "c:/ssl/XXXXXXX.cer"
MDCertificateKeyFile "c:/ssl/XXXXXXX.key"
</MDomain>
Jusque là, pas de souci, le certificat est correctement chargé en remplacement des directives SSLCertificateFile & SSLCertificateKeyFile.
Par contre, Apache dit que si le certificat n'existe pas, il sera créé. Ce n'est pas le cas, j'ai une erreur indiquant que le certificat n'existe pas. :iz:
Je vais continuer à chercher, mais je serais d'avis d'attendre que ce module ne soit plus expérimental. Ca clarifierait les choses.
(https://static.chez-oim.org/bloc/mod_md-avert.png)
Ca y est, j'ai réussi ! :gq:
Ca tenait à un tout petit détail de rien du tout dans la config, mais c'était suffisant pour que les certificats restent en statique sans jamais être renouvelés, voir créés.
Du coup, j'en ai profité pour télécharger la dernière mise à jour pour Windows de ce mod_md.
Apache 2.4.41 fonctionne avec la 2.0.10 (qui est une beta) alors qu'il est possible d'avoir la 2.1.9 déjà toute compilée avec VS16 ou le VC15 et la 2.2.0 arrive ces jours ci (c'est la version finale).
Ce module se télécharge ici : https://github.com/nono303/mod_md/releases (https://github.com/nono303/mod_md/releases)
Il suffit de télécharger le .zip de la dernière version, de décompresser et de copier/coller le module mod_md.so, compilé avec le VC++ choisi, dans le dossier modules de Apache en remplacement de l'ancien.
Ensuite, allons-y. Pour l'exemple, on demandera un certificat pour example.com et deux sous domaines.
Tout à la fin de HTTPD.CONF copier/coller ce qui suit :
<IfModule mod_status.c>
<Location "/server-status">
SetHandler server-status
Require local
</Location>
<IfModule mod_md.c>
<Location "/md-status">
SetHandler md-status
Require local
</Location>
</IfModule>
</IfModule>
<IfModule mod_md.c>
MDBaseServer off
MDCAChallenges http-01
MDCertificateAgreement accepted
MDCertificateAuthority https://acme-v02.api.letsencrypt.org/directory
# MDCertificateAuthority https://acme-staging-v02.api.letsencrypt.org/directory
MDCertificateProtocol ACME
MDCertificateStatus on
MDMustStaple on
MDPortMap http:80 https:443
MDPrivateKeys RSA 4096
MDRenewMode always
MDRenewWindow 30d
MDRequireHttps temporary
MDStoreDir "c:/ssl/md"
</IfModule>
Ensuite, au dessus de votre VHOST et comme VHOST, entrez ceci : (Attention ! On ne donne plus de certificat/clé dans le VHOST, c'est Mod_MD qui se charge de tout !)
<MDomain example.com auto>
MDMember www.example.com
MDMember mail.example.com
MDCertificateFile "c:/ssl/md/domains/example.com/pubcert.pem"
MDCertificateKeyFile "c:/ssl/md/domains/example.com/privkey.pem"
</MDomain>
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com
ServerAlias mail.example.com
ServerAdmin admin@example.com
DocumentRoot E:/wamp/www
SSLEngine on
# Ne spécifier aucun certificat ni clé à la suite, Mod_MD se charge de tout
</VirtualHost>
Bien entendu, il ne faudra pas oublier de créer un alias et une petite config pour les serveurs Lets Encrypt dans le dossier Alias de Wamp, afin que Lets Encrypt puisse librement accéder au dossier ./.well-known/acme-challenge/ afin de valider les fichiers de vérification créés par Mod_MD :
Alias /.well-known/acme-challenge "C:\ssl\md\challenges"
<directory "C:\ssl\md\challenges">
Options -Indexes
AllowOverride none
Require all granted
</Directory>
Et voilà, il ne reste plus qu'à laisser la magie opérer et lancer Apache !
Si le certificat n'existe pas, il sera créé.
Et voici la suite :
(https://static.chez-oim.org/uploads/member_1/stock1/1571329745.png)
Puis, après redémarrage du serveur :
(https://static.chez-oim.org/uploads/member_1/stock1/1571329786.png)
Dans error.log, ce message sera présent à chaque création/renouvellement de certificat :
[Thu Oct 17 03:54:53.065600 2019] [md:notice] [pid 2020:tid 1252] AH10059: The Managed Domain example.com has been setup and changes will be activated on next (graceful) server restart.
ATTENTION AUX DOSSIERS CRÉÉS !
Dans l'exemple, le chemin C:\ssl est utilisé.
Les dossiers suivants sont ceux du module MD, il n'est pas possible de les renommer !
Un autre lecteur et dossier peut-être utilisé, mais le dossier .\md\challenges, par exemple, venant à la suite n'est pas négociable !
Donc, quand un chemin comme C:\ssl\md est donné, seul ce qui vient avant \md peut être modifié !
Le module MD créera les dossiers et fichiers dont il a besoin dans le dossier md :
md-+--
+- accounts
+- archive
+- challenges
+- domains
+- fallback-privkey.pem
+- fallback-cert.pem
+- httpd.json
+- md_store.json
+- staging
+- tmp
Il est possible d'exécuter un script dès que quelque chose se passe avec les certificats gérés, comme par exemple un script se chargeant de redémarrer le serveur.
Pour ça, la documentation est notre amie à tous ! :)
Bonjour,
Je viens de faire des essais et, a priori, ça fonctionne maintenant avec Apache 2.4.41 VS16.
- Ajout d'un VirtualHost dans la page wamp add_vhosts.php
donc, modification des fichiers hosts et httpd-vhosts.conf
Lancement dans la page add_vhosts.php de :
$command = array(
'ipconfig /flushdns',
$c_apacheExe.' -n '.$c_apacheService.' -k restart',
);
ob_start();
foreach($command as $value) {
echo "Command-> ".$value."\n";
passthru($value);
}
$output = iconv("CP850","UTF-8//TRANSLIT", ob_get_contents());
ob_end_clean();
$dns_refresh_message = '<pre><code>'.$output.'</code></pre>';
Nouveaux fichiers hosts et httpd-vhosts.conf bien pris en compte par Windows et par Apache.
Bonsoir,
$c_apacheExe = chemin complet absolu sur httpd.exe
$c_apacheService = nom sur service qui lance Apache, en l'occurrence wampapache ou wampapache64
Quant à ipconfig /flushdns c'est pour que le modifications du fichier hosts soient prises en compte, vu qu'il n'est plus possible, sous Windows 10, d'arrêter et de redémarrer le service dnscache.
J'ajouterais que c'est lancé depuis une page web et qu'avant Apache 2.4.41 VS16, cela arrêtait purement et simplement Apache, donc le script était planté puisque PHP WEB n'était plus activé.
Bien vérifier qu'Apache 2.4.41 est compilé VS16, httpd.exe -v doit bien l'indiquer :
J:\wamp64\bin\apache\apache2.4.41\bin>httpd -v
Server version: Apache/2.4.41 (Win64)
Apache Lounge VS16 Server built: Aug 9 2019 16:46:32
Ah oui, dis donc, ça a à l'air de faire un reload ! :ip:
httpd -n wampapache64 -k restart
Atta, atta.
Pas d'emballement, pas de fausse joie, je fais un test de changement de config et je dis ce qu'il en est.
En tout cas, le service n'est pas interrompu, ça c'est certain. :)
Messages du même membre fusionnés car compris dans le délai d'édition (Vous avez 30 minutes pour éditer).
Et merde ! C'est pas ça.
Il se passe quelque chose, ça prend un peu de temps, mais la config n'est pas rechargée. :gk:
P'tain ! J'y croyais ! Merde alors ! :(
oui je suis chauffeur routier et j en ai profiter de mon conge pour passer en https lol j ai repondu au message precedent merci du coup de pouce et oui j ai mes yeux a moitie fermer a force de trouver la solution lol
#
# This is the Apache server configuration file providing SSL support.
# It contains the configuration directives to instruct the server how to
# serve pages over an https connection. For detailed information about these
# directives see <URL:http://httpd.apache.org/docs/2.4/mod/mod_ssl.html>
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#
# Required modules: mod_log_config, mod_setenvif, mod_ssl,
# socache_shmcb_module (for default value of SSLSessionCache)
#
# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the SSL library.
# The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
#
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed startup file:/dev/urandom 512
#SSLRandomSeed connect file:/dev/random 512
#SSLRandomSeed connect file:/dev/urandom 512
#
# When we also provide SSL we have to listen to the
# standard HTTP port (see above) and to the HTTPS port
#
Listen 443
##
## SSL Global Context
##
## All SSL configuration in this context applies both to
## the main server and all SSL-enabled virtual hosts.
##
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate,
# and that httpd will negotiate as the client of a proxied server.
# See the OpenSSL documentation for a complete list of ciphers, and
# ensure these follow appropriate best practices for this deployment.
# httpd 2.2.30, 2.4.13 and later force-disable aNULL, eNULL and EXP ciphers,
# while OpenSSL disabled these by default in 0.9.8zf/1.0.0r/1.0.1m/1.0.2a.
SSLCipherSuite HIGH:!RSA:!RC4:!3DES:!DES:!IDEA:!MD5:!aNULL:!eNULL:!EXP
SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4:!3DES
# By the end of 2016, only TLSv1.2 ciphers should remain in use.
# Older ciphers should be disallowed as soon as possible, while the
# kRSA ciphers do not offer forward secrecy. These changes inhibit
# older clients (such as IE6 SP2 or IE8 on Windows XP, or other legacy
# non-browser tooling) from successfully connecting.
#
# To restrict mod_ssl to use only TLSv1.2 ciphers, and disable
# those protocols which do not support forward secrecy, replace
# the SSLCipherSuite and SSLProxyCipherSuite directives above with
# the following two directives, as soon as practical.
# SSLCipherSuite HIGH:MEDIUM:!SSLv3:!kRSA
# SSLProxyCipherSuite HIGH:MEDIUM:!SSLv3:!kRSA
# User agents such as web browsers are not configured for the user's
# own preference of either security or performance, therefore this
# must be the prerogative of the web server administrator who manages
# cpu load versus confidentiality, so enforce the server's cipher order.
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets on
# SSL Protocol support:
# List the protocol versions which clients are allowed to connect with.
# Disable SSLv3 by default (cf. RFC 7525 3.1.1). TLSv1 (1.0) should be
# disabled as quickly as practical. By the end of 2016, only the TLSv1.2
# protocol or later should remain in use.
SSLProtocol all -SSLv3 -SSLv2 -TLSv1 -TLSv1.1
SSLProxyProtocol all -SSLv3
# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program (`builtin' is an internal
# terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog builtin
# Inter-Process Session Cache:
# Configure the SSL Session Cache: First the mechanism
# to use and second the expiring timeout (in seconds).
#SSLSessionCache "dbm:${SRVROOT}/logs/ssl_scache"
SSLSessionCache "shmcb:${SRVROOT}/logs/ssl_scache(512000)"
SSLSessionCacheTimeout 300
# OCSP Stapling (requires OpenSSL 0.9.8h or later)
#
# This feature is disabled by default and requires at least
# the two directives SSLUseStapling and SSLStaplingCache.
# Refer to the documentation on OCSP Stapling in the SSL/TLS
# How-To for more information.
#
# Enable stapling for all SSL-enabled servers:
#SSLUseStapling On
# Define a relatively small cache for OCSP Stapling using
# the same mechanism that is used for the SSL session cache
# above. If stapling is used with more than a few certificates,
# the size may need to be increased. (AH01929 will be logged.)
#SSLStaplingCache "shmcb:${SRVROOT}/logs/ssl_stapling(32768)"
# Seconds before valid OCSP responses are expired from the cache
#SSLStaplingStandardCacheTimeout 3600
# Seconds before invalid OCSP responses are expired from the cache
#SSLStaplingErrorCacheTimeout 600
##
## SSL Virtual Host Context
##
<VirtualHost *:443>
# General setup for the virtual host
DocumentRoot "E:/www"
ServerName lagmedia.ddns.net
ServerAdmin lagrace@lagmedia.ddns.net
ErrorLog "C:/wamp64/logs/apache_error.log"
TransferLog "C:/wamp64/logs/access.log"
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. Keep
# in mind that if you have both an RSA and a DSA certificate you
# can configure both in parallel (to also allow the use of DSA
# ciphers, etc.)
# Some ECC cipher suites (http://www.ietf.org/rfc/rfc4492.txt)
# require an ECC certificate which can also be configured in
# parallel.
SSLCertificateFile "c:/wamp64/ssl/lagmedia.ddns.net.crt"
#SSLCertificateFile "${SRVROOT}/conf/server-dsa.crt"
#SSLCertificateFile "${SRVROOT}/conf/server-ecc.crt"
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
# ECC keys, when in use, can also be configured in parallel
SSLCertificateKeyFile "c:/wamp64/ssl/lagmedia.ddns.net.key"
#SSLCertificateKeyFile "c:/wamp64/ssl/lagmedia.ddns.net.key"
#SSLCertificateKeyFile "${SRVROOT}/conf/server-ecc.key"
SSLCACertificateFile "c:/wamp64/ssl/lets-encrypt-x3-cross-signed.pem"
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convenience.
#SSLCertificateChainFile "${SRVROOT}/conf/server-ca.crt"
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath "${SRVROOT}/conf/ssl.crt"
#SSLCACertificateFile "${SRVROOT}/conf/ssl.crt/ca-bundle.crt"
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded).
# The CRL checking mode needs to be configured explicitly
# through SSLCARevocationCheck (defaults to "none" otherwise).
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath "${SRVROOT}/conf/ssl.crl"
#SSLCARevocationFile "${SRVROOT}/conf/ssl.crl/ca-bundle.crl"
#SSLCARevocationCheck chain
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# TLS-SRP mutual authentication:
# Enable TLS-SRP and set the path to the OpenSSL SRP verifier
# file (containing login information for SRP user accounts).
# Requires OpenSSL 1.0.1 or newer. See the mod_ssl FAQ for
# detailed instructions on creating this file. Example:
# "openssl srp -srpvfile ${SRVROOT}/conf/passwd.srpv -add username"
#SSLSRPVerifierFile "${SRVROOT}/conf/passwd.srpv"
# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o StrictRequire:
# This denies access when "SSLRequireSSL" or "SSLRequire" applied even
# under a "Satisfy any" situation, i.e. when it applies access is denied
# and no other module can change it.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory "${SRVROOT}/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is sent or allowed to be received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
CustomLog "C:/wamp64/logs/access_ssl.log" \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
#
# This is the main Apache HTTP server configuration file. It contains the
# configuration directives that give the server its instructions.
# See <URL:http://httpd.apache.org/docs/2.4/> for detailed information.
# In particular, see
# <URL:http://httpd.apache.org/docs/2.4/mod/directives.html>
# for a discussion of each configuration directive.
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#
# Configuration and logfile names: If the filenames you specify for many
# of the server's control files begin with "/" (or "drive:/" for Win32), the
# server will use that explicit path. If the filenames do *not* begin
# with "/", the value of ServerRoot is prepended -- so "logs/access_log"
# with ServerRoot set to "/usr/local/apache2" will be interpreted by the
# server as "/usr/local/apache2/logs/access_log", whereas "/logs/access_log"
# will be interpreted as '/logs/access_log'.
#
# NOTE: Where filenames are specified, you must use forward slashes
# instead of backslashes (e.g., "c:/apache" instead of "c:\apache").
# If a drive letter is omitted, the drive on which httpd.exe is located
# will be used by default. It is recommended that you always supply
# an explicit drive letter in absolute paths to avoid confusion.
ServerSignature On
ServerTokens Full
#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# Do not add a slash at the end of the directory path. If you point
# ServerRoot at a non-local disk, be sure to specify a local disk on the
# Mutex directive, if file-based mutexes are used. If you wish to share the
# same ServerRoot for multiple httpd daemons, you will need to change at
# least PidFile.
#
# Apache variable names used by Apache conf files:
# The names and contents of variables:
# APACHE24, VERSION_APACHE, INSTALL_DIR, APACHE_DIR, SRVROOT
# should never be changed.
Define APACHE24 Apache2.4
Define VERSION_APACHE 2.4.43a
Define INSTALL_DIR c:/wamp64
Define APACHE_DIR ${INSTALL_DIR}/bin/apache/apache${VERSION_APACHE}
Define SRVROOT ${INSTALL_DIR}/bin/apache/apache${VERSION_APACHE}
ServerRoot "${SRVROOT}"
#
# Mutex: Allows you to set the mutex mechanism and mutex file directory
# for individual mutexes, or change the global defaults
#
# Uncomment and change the directory if mutexes are file-based and the default
# mutex file directory is not on a local disk or is not appropriate for some
# other reason.
#
# Mutex default:logs
#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80
Listen 0.0.0.0:80
Listen [::0]:80
#
# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was built as a DSO you
# have to place corresponding `LoadModule' lines at this location so the
# directives contained in it are actually available _before_ they are used.
# Statically compiled modules (those listed by `httpd -l') do not need
# to be loaded here.
#
# Example:
# LoadModule foo_module modules/mod_foo.so
#
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule allowmethods_module modules/mod_allowmethods.so
LoadModule asis_module modules/mod_asis.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule auth_digest_module modules/mod_auth_digest.so
#LoadModule auth_form_module modules/mod_auth_form.so
#LoadModule authn_anon_module modules/mod_authn_anon.so
LoadModule authn_core_module modules/mod_authn_core.so
#LoadModule authn_dbd_module modules/mod_authn_dbd.so
#LoadModule authn_dbm_module modules/mod_authn_dbm.so
LoadModule authn_file_module modules/mod_authn_file.so
#LoadModule authn_socache_module modules/mod_authn_socache.so
#LoadModule authnz_fcgi_module modules/mod_authnz_fcgi.so
#LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule authz_core_module modules/mod_authz_core.so
#LoadModule authz_dbd_module modules/mod_authz_dbd.so
#LoadModule authz_dbm_module modules/mod_authz_dbm.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_host_module modules/mod_authz_host.so
#LoadModule authz_owner_module modules/mod_authz_owner.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule autoindex_module modules/mod_autoindex.so
#LoadModule brotli_module modules/mod_brotli.so
#LoadModule buffer_module modules/mod_buffer.so
LoadModule cache_module modules/mod_cache.so
LoadModule cache_disk_module modules/mod_cache_disk.so
#LoadModule cache_socache_module modules/mod_cache_socache.so
#LoadModule cern_meta_module modules/mod_cern_meta.so
LoadModule cgi_module modules/mod_cgi.so
#LoadModule charset_lite_module modules/mod_charset_lite.so
#LoadModule data_module modules/mod_data.so
#LoadModule dav_module modules/mod_dav.so
#LoadModule dav_fs_module modules/mod_dav_fs.so
#LoadModule dav_lock_module modules/mod_dav_lock.so
#LoadModule dbd_module modules/mod_dbd.so
#LoadModule deflate_module modules/mod_deflate.so
LoadModule dir_module modules/mod_dir.so
#LoadModule dumpio_module modules/mod_dumpio.so
LoadModule env_module modules/mod_env.so
#LoadModule expires_module modules/mod_expires.so
#LoadModule ext_filter_module modules/mod_ext_filter.so
LoadModule file_cache_module modules/mod_file_cache.so
#LoadModule filter_module modules/mod_filter.so
#LoadModule http2_module modules/mod_http2.so
#LoadModule headers_module modules/mod_headers.so
#LoadModule heartbeat_module modules/mod_heartbeat.so
#LoadModule heartmonitor_module modules/mod_heartmonitor.so
#LoadModule ident_module modules/mod_ident.so
#LoadModule imagemap_module modules/mod_imagemap.so
LoadModule include_module modules/mod_include.so
#LoadModule info_module modules/mod_info.so
LoadModule isapi_module modules/mod_isapi.so
#LoadModule lbmethod_bybusyness_module modules/mod_lbmethod_bybusyness.so
#LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so
#LoadModule lbmethod_bytraffic_module modules/mod_lbmethod_bytraffic.so
#LoadModule lbmethod_heartbeat_module modules/mod_lbmethod_heartbeat.so
#LoadModule ldap_module modules/mod_ldap.so
#LoadModule logio_module modules/mod_logio.so
LoadModule log_config_module modules/mod_log_config.so
#LoadModule log_debug_module modules/mod_log_debug.so
#LoadModule log_forensic_module modules/mod_log_forensic.so
#LoadModule lua_module modules/mod_lua.so
#LoadModule macro_module modules/mod_macro.so
#LoadModule md_module modules/mod_md.so
LoadModule mime_module modules/mod_mime.so
#LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule negotiation_module modules/mod_negotiation.so
#LoadModule proxy_module modules/mod_proxy.so
#LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
#LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
#LoadModule proxy_connect_module modules/mod_proxy_connect.so
#LoadModule proxy_express_module modules/mod_proxy_express.so
#LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
#LoadModule proxy_hcheck_module modules/mod_proxy_hcheck.so
#LoadModule proxy_html_module modules/mod_proxy_html.so
#LoadModule proxy_http_module modules/mod_proxy_http.so
#LoadModule proxy_http2_module modules/mod_proxy_http2.so
#LoadModule proxy_scgi_module modules/mod_proxy_scgi.so
#LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so
#LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so
#LoadModule ratelimit_module modules/mod_ratelimit.so
#LoadModule reflector_module modules/mod_reflector.so
#LoadModule remoteip_module modules/mod_remoteip.so
#LoadModule request_module modules/mod_request.so
#LoadModule reqtimeout_module modules/mod_reqtimeout.so
LoadModule rewrite_module modules/mod_rewrite.so
#LoadModule sed_module modules/mod_sed.so
#LoadModule session_module modules/mod_session.so
#LoadModule session_cookie_module modules/mod_session_cookie.so
#LoadModule session_crypto_module modules/mod_session_crypto.so
#LoadModule session_dbd_module modules/mod_session_dbd.so
LoadModule setenvif_module modules/mod_setenvif.so
#LoadModule slotmem_plain_module modules/mod_slotmem_plain.so
#LoadModule slotmem_shm_module modules/mod_slotmem_shm.so
#LoadModule socache_dbm_module modules/mod_socache_dbm.so
#LoadModule socache_memcache_module modules/mod_socache_memcache.so
#LoadModule socache_redis_module modules/mod_socache_redis.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
#LoadModule speling_module modules/mod_speling.so
LoadModule ssl_module modules/mod_ssl.so
#LoadModule status_module modules/mod_status.so
#LoadModule substitute_module modules/mod_substitute.so
#LoadModule unique_id_module modules/mod_unique_id.so
LoadModule userdir_module modules/mod_userdir.so
#LoadModule usertrack_module modules/mod_usertrack.so
#LoadModule version_module modules/mod_version.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
#LoadModule watchdog_module modules/mod_watchdog.so
#LoadModule xml2enc_module modules/mod_xml2enc.so
PHPIniDir "${APACHE_DIR}/bin"
LoadModule php7_module "${INSTALL_DIR}/bin/php/php7.4.5/php7apache2_4.dll"
<IfModule unixd_module>
#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# It is usually good practice to create a dedicated user and group for
# running httpd, as with most system services.
#
User daemon
Group daemon
</IfModule>
# 'Main' server configuration
#
# The directives in this section set up the values used by the 'main'
# server, which responds to any requests that aren't handled by a
# <VirtualHost> definition. These values also provide defaults for
# any <VirtualHost> containers you may define later in the file.
#
# All of these directives may appear inside <VirtualHost> containers,
# in which case these default settings will be overridden for the
# virtual host being defined.
#
#
# ServerAdmin: Your address, where problems with the server should be
# e-mailed. This address appears on some server-generated pages, such
# as error documents. e.g. admin@your-domain.com
#
ServerAdmin wampserver@wampserver.invalid
#
# ServerName gives the name and port that the server uses to identify itself.
# This can often be determined automatically, but we recommend you specify
# it explicitly to prevent problems during startup.
#
# If your host doesn't have a registered DNS name, enter its IP address here.
#
ServerName localhost:80
#
# Deny access to the entirety of your server's filesystem. You must
# explicitly permit access to web content directories in other
# <Directory> blocks below.
#
<Directory />
AllowOverride none
Require all denied
</Directory>
#
# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something's not working as
# you might expect, make sure that you have specifically enabled it
# below.
#
HostnameLookups Off
#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "E:/www"
<Directory "E:/www/">
#
# Possible values for the Options directive are "None", "All",
# or any combination of:
# Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important. Please see
# http://httpd.apache.org/docs/2.4/mod/core.html#options
# for more information.
#
Options +Indexes +FollowSymLinks +Multiviews
#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# AllowOverride FileInfo AuthConfig Limit
#
AllowOverride all
#
# Controls who can get stuff from this server.
#
# Don't modify this line - Instead modify Require of VirtualHost in httpd-vhost.conf
Require all granted
</Directory>
#
# DirectoryIndex: sets the file that Apache will serve if a directory
# is requested.
#
<IfModule dir_module>
DirectoryIndex index.php index.php3 index.html index.htm
</IfModule>
#
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#
<Files ".ht*">
Require all denied
</Files>
#
# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a <VirtualHost>
# container, error messages relating to that virtual host will be
# logged here. If you *do* define an error logfile for a <VirtualHost>
# container, that host's errors will be logged there and not here.
#
ErrorLog "${INSTALL_DIR}/logs/apache_error.log"
#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn
<IfModule log_config_module>
#
# The following directives define some format nicknames for use with
# a CustomLog directive (see below).
#
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
<IfModule logio_module>
# You need to enable mod_logio.c to use %I and %O
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
</IfModule>
#
# The location and format of the access logfile (Common Logfile Format).
# If you do not define any access logfiles within a <VirtualHost>
# container, they will be logged here. Contrariwise, if you *do*
# define per-<VirtualHost> access logfiles, transactions will be
# logged therein and *not* in this file.
#
CustomLog "${INSTALL_DIR}/logs/access.log" common
#
# If you prefer a logfile with access, agent, and referer information
# (Combined Logfile Format) you can use the following directive.
#
#CustomLog "logs/access.log" combined
</IfModule>
<IfModule alias_module>
#
# Redirect: Allows you to tell clients about documents that used to
# exist in your server's namespace, but do not anymore. The client
# will make a new request for the document at its new location.
# Example:
# Redirect permanent /foo http://www.example.com/bar
#
# Alias: Maps web paths into filesystem paths and is used to
# access content that does not live under the DocumentRoot.
# Example:
# Alias /webpath /full/filesystem/path
#
# If you include a trailing / on /webpath then the server will
# require it to be present in the URL. You will also likely
# need to provide a <Directory> section to allow access to
# the filesystem path.
#
# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the target directory are treated as applications and
# run by the server when requested rather than as documents sent to the
# client. The same rules about trailing "/" apply to ScriptAlias
# directives as to Alias.
#
ScriptAlias /cgi-bin/ "${SRVROOT}/cgi-bin/"
</IfModule>
<IfModule cgid_module>
#
# ScriptSock: On threaded servers, designate the path to the UNIX
# socket used to communicate with the CGI daemon of mod_cgid.
#
#Scriptsock cgisock
</IfModule>
#
# "${SRVROOT}/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#
<Directory "${SRVROOT}/cgi-bin">
AllowOverride None
Options None
Require all granted
</Directory>
<IfModule headers_module>
#
# Avoid passing HTTP_PROXY environment to CGI's on this or any proxied
# backend servers which have lingering "httpoxy" defects.
# 'Proxy' request header is undefined by the IETF, not listed by IANA
#
RequestHeader unset Proxy early
</IfModule>
<IfModule mime_module>
#
# TypesConfig points to the file containing the list of mappings from
# filename extension to MIME-type.
#
TypesConfig conf/mime.types
#
# AddType allows you to add to or override the MIME configuration
# file specified in TypesConfig for specific file types.
#
#AddType application/x-gzip .tgz
#
# AddEncoding allows you to have certain browsers uncompress
# information on the fly. Note: Not all browsers support this.
#
AddEncoding x-compress .Z
AddEncoding x-gzip .gz .tgz
#
# If the AddEncoding directives above are commented-out, then you
# probably should define those extensions to indicate media types:
#
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
#
# AddHandler allows you to map certain file extensions to "handlers":
# actions unrelated to filetype. These can be either built into the server
# or added with the Action directive (see below)
#
# To use CGI scripts outside of ScriptAliased directories:
# (You will also need to add "ExecCGI" to the "Options" directive.)
#
#AddHandler cgi-script .cgi
# For type maps (negotiated resources):
#AddHandler type-map var
#
# Filters allow you to process content before it is sent to the client.
#
# To parse .shtml files for server-side includes (SSI):
# (You will also need to add "Includes" to the "Options" directive.)
#
#AddType text/html .shtml
#AddOutputFilter INCLUDES .shtml
</IfModule>
#
# The mod_mime_magic module allows the server to use various hints from the
# contents of the file itself to determine its type. The MIMEMagicFile
# directive tells the module where the hint definitions are located.
#
#MIMEMagicFile conf/magic
#
# Customizable error responses come in three flavors:
# 1) plain text 2) local redirects 3) external redirects
#
# Some examples:
#ErrorDocument 500 "The server made a boo boo."
#ErrorDocument 404 /missing.html
#ErrorDocument 404 "/cgi-bin/missing_handler.pl"
#ErrorDocument 402 http://www.example.com/subscription_info.html
#
#
# MaxRanges: Maximum number of Ranges in a request before
# returning the entire resource, or one of the special
# values 'default', 'none' or 'unlimited'.
# Default setting is to accept 200 Ranges.
#MaxRanges unlimited
#
# EnableMMAP and EnableSendfile: On systems that support it,
# memory-mapping or the sendfile syscall may be used to deliver
# files. This usually improves server performance, but must
# be turned off when serving from networked-mounted
# filesystems or if support for these functions is otherwise
# broken on your system.
# Defaults: EnableMMAP On, EnableSendfile Off
#
EnableMMAP off
EnableSendfile off
# AcceptFilter: On Windows, none uses accept() rather than AcceptEx() and
# will not recycle sockets between connections. This is useful for network
# adapters with broken driver support, as well as some virtual network
# providers such as vpn drivers, or spam, virus or spyware filters.
AcceptFilter http none
AcceptFilter https none
# ThreadStackSize: sets the size of the stack (for autodata)
# of threads which handle client connections and call modules to help process
# those connections. In most cases the operating system default for stack size
# is reasonable, but there are some conditions where it may need to be adjusted.
# Apache httpd may crash when using some third-party modules which use a
# relatively large amount of autodata storage or automatically restart with
# message like: child process 12345 exited with status 3221225725 -- Restarting.
# This type of crash is resolved by setting ThreadStackSize to a value higher
# than the operating system default.
ThreadStackSize 8388608
# Supplemental configuration
#
# The configuration files in the conf/extra/ directory can be
# included to add extra features or to modify the default configuration of
# the server, or you may simply copy their contents here and change as
# necessary.
# Server-pool management (MPM specific)
#Include conf/extra/httpd-mpm.conf
# Multi-language error messages
#Include conf/extra/httpd-multilang-errordoc.conf
# Fancy directory listings
Include conf/extra/httpd-autoindex.conf
# Language settings
#Include conf/extra/httpd-languages.conf
# User home directories
#Include conf/extra/httpd-userdir.conf
# Real-time info on requests and configuration
#Include conf/extra/httpd-info.conf
# Virtual hosts
Include conf/extra/httpd-vhosts.conf
# Local access to the Apache HTTP Server Manual
#Include conf/extra/httpd-manual.conf
# Distributed authoring and versioning (WebDAV)
#Include conf/extra/httpd-dav.conf
# Various default settings
#Include conf/extra/httpd-default.conf
# Configure mod_proxy_html to understand HTML4/XHTML1
<IfModule proxy_html_module>
Include conf/extra/proxy-html.conf
</IfModule>
# Secure (SSL/TLS) connections
#Include conf/extra/httpd-ssl.conf
#
# Note: The following must must be present to support
# starting without SSL on platforms with no /dev/random equivalent
# but a statically compiled-in mod_ssl.
#
<IfModule ssl_module>
Include conf/extra/httpd-ssl.conf
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
</IfModule>
Include "${INSTALL_DIR}/alias/*.conf"
voici et les 2 autres fichiers dans le messages precedent j essaie de moins poluer lol merci
[Thu May 07 18:37:16.905458 2020] [mpm_winnt:notice] [pid 280:tid 456] AH00422: Parent: Received shutdown signal -- Shutting down the server.
[Thu May 07 18:37:18.905572 2020] [mpm_winnt:notice] [pid 4500:tid 380] AH00364: Child: All worker threads have exited.
[Thu May 07 18:37:21.371713 2020] [mpm_winnt:notice] [pid 280:tid 456] AH00430: Parent: Child process 4500 exited successfully.
[Thu May 07 18:37:38.073669 2020] [mpm_winnt:notice] [pid 5540:tid 456] AH00455: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.5 configured -- resuming normal operations
[Thu May 07 18:37:38.074669 2020] [mpm_winnt:notice] [pid 5540:tid 456] AH00456: Apache Lounge VS16 Server built: Apr 21 2020 16:23:13
[Thu May 07 18:37:38.074669 2020] [core:notice] [pid 5540:tid 456] AH00094: Command line: 'c:\\wamp64\\bin\\apache\\apache2.4.43a\\bin\\httpd.exe -d C:/wamp64/bin/apache/apache2.4.43a'
[Thu May 07 18:37:38.076669 2020] [mpm_winnt:notice] [pid 5540:tid 456] AH00418: Parent: Created child process 148
[Thu May 07 18:37:38.521694 2020] [mpm_winnt:notice] [pid 148:tid 380] AH00354: Child: Starting 64 worker threads.
[Thu May 07 18:38:17.628931 2020] [authz_core:error] [pid 148:tid 904] [client 91.86.192.206:49243] AH01630: client denied by server configuration: E:/www/
[Thu May 07 18:38:17.995952 2020] [authz_core:error] [pid 148:tid 904] [client 91.86.192.206:49243] AH01630: client denied by server configuration: E:/www/favicon.ico, referer: https://lagmedia.ddns.net/
[Thu May 07 18:50:27.769693 2020] [mpm_winnt:notice] [pid 5540:tid 456] AH00422: Parent: Received shutdown signal -- Shutting down the server.
[Thu May 07 18:50:29.769807 2020] [mpm_winnt:notice] [pid 148:tid 380] AH00364: Child: All worker threads have exited.
[Thu May 07 18:50:31.080882 2020] [mpm_winnt:notice] [pid 5540:tid 456] AH00430: Parent: Child process 148 exited successfully.
[Thu May 07 18:50:32.240948 2020] [mpm_winnt:notice] [pid 592:tid 456] AH00455: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.5 configured -- resuming normal operations
[Thu May 07 18:50:32.240948 2020] [mpm_winnt:notice] [pid 592:tid 456] AH00456: Apache Lounge VS16 Server built: Apr 21 2020 16:23:13
[Thu May 07 18:50:32.240948 2020] [core:notice] [pid 592:tid 456] AH00094: Command line: 'c:\\wamp64\\bin\\apache\\apache2.4.43a\\bin\\httpd.exe -d C:/wamp64/bin/apache/apache2.4.43a'
[Thu May 07 18:50:32.242949 2020] [mpm_winnt:notice] [pid 592:tid 456] AH00418: Parent: Created child process 5976
[Thu May 07 18:50:32.677973 2020] [mpm_winnt:notice] [pid 5976:tid 380] AH00354: Child: Starting 64 worker threads.
[Thu May 07 19:22:32.307804 2020] [mpm_winnt:notice] [pid 592:tid 456] AH00422: Parent: Received shutdown signal -- Shutting down the server.
[Thu May 07 19:22:34.307918 2020] [mpm_winnt:notice] [pid 5976:tid 380] AH00364: Child: All worker threads have exited.
[Thu May 07 19:22:34.341920 2020] [mpm_winnt:notice] [pid 592:tid 456] AH00430: Parent: Child process 5976 exited successfully.
[Thu May 07 19:22:35.450983 2020] [mpm_winnt:notice] [pid 5272:tid 456] AH00455: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.5 configured -- resuming normal operations
[Thu May 07 19:22:35.451983 2020] [mpm_winnt:notice] [pid 5272:tid 456] AH00456: Apache Lounge VS16 Server built: Apr 21 2020 16:23:13
[Thu May 07 19:22:35.451983 2020] [core:notice] [pid 5272:tid 456] AH00094: Command line: 'c:\\wamp64\\bin\\apache\\apache2.4.43a\\bin\\httpd.exe -d C:/wamp64/bin/apache/apache2.4.43a'
[Thu May 07 19:22:35.452984 2020] [mpm_winnt:notice] [pid 5272:tid 456] AH00418: Parent: Created child process 5388
[Thu May 07 19:22:35.887008 2020] [mpm_winnt:notice] [pid 5388:tid 380] AH00354: Child: Starting 64 worker threads.
[Thu May 07 19:31:58.172169 2020] [mpm_winnt:notice] [pid 5272:tid 456] AH00422: Parent: Received shutdown signal -- Shutting down the server.
[Thu May 07 19:32:00.172284 2020] [mpm_winnt:notice] [pid 5388:tid 380] AH00364: Child: All worker threads have exited.
[Thu May 07 19:32:00.205286 2020] [mpm_winnt:notice] [pid 5272:tid 456] AH00430: Parent: Child process 5388 exited successfully.
[Thu May 07 19:32:01.861380 2020] [mpm_winnt:notice] [pid 5812:tid 456] AH00455: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.5 configured -- resuming normal operations
[Thu May 07 19:32:01.861380 2020] [mpm_winnt:notice] [pid 5812:tid 456] AH00456: Apache Lounge VS16 Server built: Apr 21 2020 16:23:13
[Thu May 07 19:32:01.861380 2020] [core:notice] [pid 5812:tid 456] AH00094: Command line: 'c:\\wamp64\\bin\\apache\\apache2.4.43a\\bin\\httpd.exe -d C:/wamp64/bin/apache/apache2.4.43a'
[Thu May 07 19:32:01.862380 2020] [mpm_winnt:notice] [pid 5812:tid 456] AH00418: Parent: Created child process 592
[Thu May 07 19:32:02.297405 2020] [mpm_winnt:notice] [pid 592:tid 380] AH00354: Child: Starting 64 worker threads.
[Thu May 07 19:38:47.944607 2020] [mpm_winnt:notice] [pid 5812:tid 456] AH00422: Parent: Received shutdown signal -- Shutting down the server.
[Thu May 07 19:38:49.944721 2020] [mpm_winnt:notice] [pid 592:tid 380] AH00364: Child: All worker threads have exited.
[Thu May 07 19:38:49.976723 2020] [mpm_winnt:notice] [pid 5812:tid 456] AH00430: Parent: Child process 592 exited successfully.
[Thu May 07 19:38:51.399805 2020] [mpm_winnt:notice] [pid 5352:tid 456] AH00455: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.5 configured -- resuming normal operations
[Thu May 07 19:38:51.399805 2020] [mpm_winnt:notice] [pid 5352:tid 456] AH00456: Apache Lounge VS16 Server built: Apr 21 2020 16:23:13
[Thu May 07 19:38:51.399805 2020] [core:notice] [pid 5352:tid 456] AH00094: Command line: 'c:\\wamp64\\bin\\apache\\apache2.4.43a\\bin\\httpd.exe -d C:/wamp64/bin/apache/apache2.4.43a'
[Thu May 07 19:38:51.401805 2020] [mpm_winnt:notice] [pid 5352:tid 456] AH00418: Parent: Created child process 1656
[Thu May 07 19:38:51.843830 2020] [mpm_winnt:notice] [pid 1656:tid 380] AH00354: Child: Starting 64 worker threads.
[Thu May 07 19:50:52.975076 2020] [mpm_winnt:notice] [pid 5352:tid 456] AH00422: Parent: Received shutdown signal -- Shutting down the server.
[Thu May 07 19:50:54.975191 2020] [mpm_winnt:notice] [pid 1656:tid 380] AH00364: Child: All worker threads have exited.
[Thu May 07 19:50:57.067310 2020] [mpm_winnt:notice] [pid 5352:tid 456] AH00430: Parent: Child process 1656 exited successfully.
[Thu May 07 19:50:57.603341 2020] [mpm_winnt:notice] [pid 5668:tid 456] AH00455: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.5 configured -- resuming normal operations
[Thu May 07 19:50:57.604341 2020] [mpm_winnt:notice] [pid 5668:tid 456] AH00456: Apache Lounge VS16 Server built: Apr 21 2020 16:23:13
[Thu May 07 19:50:57.604341 2020] [core:notice] [pid 5668:tid 456] AH00094: Command line: 'c:\\wamp64\\bin\\apache\\apache2.4.43a\\bin\\httpd.exe -d C:/wamp64/bin/apache/apache2.4.43a'
[Thu May 07 19:50:57.605341 2020] [mpm_winnt:notice] [pid 5668:tid 456] AH00418: Parent: Created child process 1876
[Thu May 07 19:50:58.044366 2020] [mpm_winnt:notice] [pid 1876:tid 380] AH00354: Child: Starting 64 worker threads.
[Thu May 07 19:56:02.301769 2020] [mpm_winnt:notice] [pid 5668:tid 456] AH00422: Parent: Received shutdown signal -- Shutting down the server.
[Thu May 07 19:56:04.301883 2020] [mpm_winnt:notice] [pid 1876:tid 380] AH00364: Child: All worker threads have exited.
[Thu May 07 19:56:04.332885 2020] [mpm_winnt:notice] [pid 5668:tid 456] AH00430: Parent: Child process 1876 exited successfully.
[Thu May 07 20:06:30.077675 2020] [mpm_winnt:notice] [pid 2800:tid 456] AH00455: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.5 configured -- resuming normal operations
[Thu May 07 20:06:30.077675 2020] [mpm_winnt:notice] [pid 2800:tid 456] AH00456: Apache Lounge VS16 Server built: Apr 21 2020 16:23:13
[Thu May 07 20:06:30.077675 2020] [core:notice] [pid 2800:tid 456] AH00094: Command line: 'c:\\wamp64\\bin\\apache\\apache2.4.43a\\bin\\httpd.exe -d C:/wamp64/bin/apache/apache2.4.43a'
[Thu May 07 20:06:30.078676 2020] [mpm_winnt:notice] [pid 2800:tid 456] AH00418: Parent: Created child process 5908
[Thu May 07 20:06:30.509700 2020] [mpm_winnt:notice] [pid 5908:tid 380] AH00354: Child: Starting 64 worker threads.
[Thu May 07 20:07:19.051477 2020] [mpm_winnt:notice] [pid 2800:tid 456] AH00422: Parent: Received shutdown signal -- Shutting down the server.
[Thu May 07 20:07:21.051591 2020] [mpm_winnt:notice] [pid 5908:tid 380] AH00364: Child: All worker threads have exited.
[Thu May 07 20:07:21.084593 2020] [mpm_winnt:notice] [pid 2800:tid 456] AH00430: Parent: Child process 5908 exited successfully.
[Thu May 07 20:07:31.855209 2020] [mpm_winnt:notice] [pid 1064:tid 456] AH00455: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.5 configured -- resuming normal operations
[Thu May 07 20:07:31.855209 2020] [mpm_winnt:notice] [pid 1064:tid 456] AH00456: Apache Lounge VS16 Server built: Apr 21 2020 16:23:13
[Thu May 07 20:07:31.855209 2020] [core:notice] [pid 1064:tid 456] AH00094: Command line: 'c:\\wamp64\\bin\\apache\\apache2.4.43a\\bin\\httpd.exe -d C:/wamp64/bin/apache/apache2.4.43a'
[Thu May 07 20:07:31.857209 2020] [mpm_winnt:notice] [pid 1064:tid 456] AH00418: Parent: Created child process 5212
[Thu May 07 20:07:32.296234 2020] [mpm_winnt:notice] [pid 5212:tid 380] AH00354: Child: Starting 64 worker threads.
[Thu May 07 20:38:52.953308 2020] [mpm_winnt:notice] [pid 1064:tid 456] AH00422: Parent: Received shutdown signal -- Shutting down the server.
[Thu May 07 20:38:55.053428 2020] [mpm_winnt:notice] [pid 5212:tid 380] AH00364: Child: All worker threads have exited.
[Thu May 07 20:38:57.075544 2020] [mpm_winnt:notice] [pid 1064:tid 456] AH00430: Parent: Child process 5212 exited successfully.
[Thu May 07 20:38:58.293613 2020] [mpm_winnt:notice] [pid 4824:tid 456] AH00455: Apache/2.4.43 (Win64) OpenSSL/1.1.1g PHP/7.4.5 configured -- resuming normal operations
[Thu May 07 20:38:58.293613 2020] [mpm_winnt:notice] [pid 4824:tid 456] AH00456: Apache Lounge VS16 Server built: Apr 21 2020 16:23:13
[Thu May 07 20:38:58.293613 2020] [core:notice] [pid 4824:tid 456] AH00094: Command line: 'c:\\wamp64\\bin\\apache\\apache2.4.43a\\bin\\httpd.exe -d C:/wamp64/bin/apache/apache2.4.43a'
[Thu May 07 20:38:58.295613 2020] [mpm_winnt:notice] [pid 4824:tid 456] AH00418: Parent: Created child process 1684
[Thu May 07 20:38:58.745639 2020] [mpm_winnt:notice] [pid 1684:tid 380] AH00354: Child: Starting 64 worker threads.
libpng warning: Interlace handling should be turned on when using png_read_image
Il ne semble pas avoir grand chose.
Juste un Waning concernant des images PNG que tu manipules.
Mais je ne vois aucune trace de ton VHOST, aucune !
Commence déjà par ça :
Ouvre la console (touche Win + CMD suivi de Enter)
c:
cd wamp64\bin\apache\apache2.4.43a\bin
httpd -t
Tu dois obtenir ce message :
Syntax OK
Et j'aimerais avant tout voir ton httpd.conf et surtout ton VHOST !
Si ça se trouve, tu l'as créé mais il n'est pas appelé...
Sinon regarde ici une autre façon de gérer ses certificats : (c'est encore plus simple)
Tuto : Obtenir, gérer et renouveler ses certificats SSL automatiquement sous Wamp (Apache) avec le module Mod_md (https://chez-oim.org/index.php/topic,2282.0.html)
bon syntaxe ok
si sait du virtual host que tu parles le voici
<VirtualHost *:80>
ServerName localhost
ServerAlias localhost
DocumentRoot "E:/www"
<Directory "E:/www/">
Options +Indexes +Includes +FollowSymLinks +MultiViews
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
j ai toujours peur de me faire passer plus con que je ne le suis lol
pour moi le vhost est declarer ici
#
# This is the Apache server configuration file providing SSL support.
# It contains the configuration directives to instruct the server how to
# serve pages over an https connection. For detailed information about these
# directives see <URL:http://httpd.apache.org/docs/2.4/mod/mod_ssl.html>
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#
# Required modules: mod_log_config, mod_setenvif, mod_ssl,
# socache_shmcb_module (for default value of SSLSessionCache)
#
# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the SSL library.
# The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
#
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed startup file:/dev/urandom 512
#SSLRandomSeed connect file:/dev/random 512
#SSLRandomSeed connect file:/dev/urandom 512
#
# When we also provide SSL we have to listen to the
# standard HTTP port (see above) and to the HTTPS port
#
Listen 443
##
## SSL Global Context
##
## All SSL configuration in this context applies both to
## the main server and all SSL-enabled virtual hosts.
##
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate,
# and that httpd will negotiate as the client of a proxied server.
# See the OpenSSL documentation for a complete list of ciphers, and
# ensure these follow appropriate best practices for this deployment.
# httpd 2.2.30, 2.4.13 and later force-disable aNULL, eNULL and EXP ciphers,
# while OpenSSL disabled these by default in 0.9.8zf/1.0.0r/1.0.1m/1.0.2a.
SSLCipherSuite HIGH:!RSA:!RC4:!3DES:!DES:!IDEA:!MD5:!aNULL:!eNULL:!EXP
SSLProxyCipherSuite HIGH:MEDIUM:!MD5:!RC4:!3DES
# By the end of 2016, only TLSv1.2 ciphers should remain in use.
# Older ciphers should be disallowed as soon as possible, while the
# kRSA ciphers do not offer forward secrecy. These changes inhibit
# older clients (such as IE6 SP2 or IE8 on Windows XP, or other legacy
# non-browser tooling) from successfully connecting.
#
# To restrict mod_ssl to use only TLSv1.2 ciphers, and disable
# those protocols which do not support forward secrecy, replace
# the SSLCipherSuite and SSLProxyCipherSuite directives above with
# the following two directives, as soon as practical.
# SSLCipherSuite HIGH:MEDIUM:!SSLv3:!kRSA
# SSLProxyCipherSuite HIGH:MEDIUM:!SSLv3:!kRSA
# User agents such as web browsers are not configured for the user's
# own preference of either security or performance, therefore this
# must be the prerogative of the web server administrator who manages
# cpu load versus confidentiality, so enforce the server's cipher order.
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets on
# SSL Protocol support:
# List the protocol versions which clients are allowed to connect with.
# Disable SSLv3 by default (cf. RFC 7525 3.1.1). TLSv1 (1.0) should be
# disabled as quickly as practical. By the end of 2016, only the TLSv1.2
# protocol or later should remain in use.
SSLProtocol all -SSLv3 -SSLv2 -TLSv1 -TLSv1.1
SSLProxyProtocol all -SSLv3
# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program (`builtin' is an internal
# terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog builtin
# Inter-Process Session Cache:
# Configure the SSL Session Cache: First the mechanism
# to use and second the expiring timeout (in seconds).
#SSLSessionCache "dbm:${SRVROOT}/logs/ssl_scache"
SSLSessionCache "shmcb:${SRVROOT}/logs/ssl_scache(512000)"
SSLSessionCacheTimeout 300
# OCSP Stapling (requires OpenSSL 0.9.8h or later)
#
# This feature is disabled by default and requires at least
# the two directives SSLUseStapling and SSLStaplingCache.
# Refer to the documentation on OCSP Stapling in the SSL/TLS
# How-To for more information.
#
# Enable stapling for all SSL-enabled servers:
#SSLUseStapling On
# Define a relatively small cache for OCSP Stapling using
# the same mechanism that is used for the SSL session cache
# above. If stapling is used with more than a few certificates,
# the size may need to be increased. (AH01929 will be logged.)
#SSLStaplingCache "shmcb:${SRVROOT}/logs/ssl_stapling(32768)"
# Seconds before valid OCSP responses are expired from the cache
#SSLStaplingStandardCacheTimeout 3600
# Seconds before invalid OCSP responses are expired from the cache
#SSLStaplingErrorCacheTimeout 600
##
## SSL Virtual Host Context
##
<VirtualHost *:443>
# General setup for the virtual host
DocumentRoot "E:/www"
ServerName lagmedia.ddns.net
ServerAdmin lagrace@lagmedia.ddns.net
ErrorLog "C:/wamp64/logs/apache_error.log"
TransferLog "C:/wamp64/logs/access.log"
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. Keep
# in mind that if you have both an RSA and a DSA certificate you
# can configure both in parallel (to also allow the use of DSA
# ciphers, etc.)
# Some ECC cipher suites (http://www.ietf.org/rfc/rfc4492.txt)
# require an ECC certificate which can also be configured in
# parallel.
SSLCertificateFile "c:/wamp64/ssl/lagmedia.ddns.net.crt"
#SSLCertificateFile "${SRVROOT}/conf/server-dsa.crt"
#SSLCertificateFile "${SRVROOT}/conf/server-ecc.crt"
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
# ECC keys, when in use, can also be configured in parallel
SSLCertificateKeyFile "c:/wamp64/ssl/lagmedia.ddns.net.key"
#SSLCertificateKeyFile "c:/wamp64/ssl/lagmedia.ddns.net.key"
#SSLCertificateKeyFile "${SRVROOT}/conf/server-ecc.key"
SSLCACertificateFile "c:/wamp64/ssl/lets-encrypt-x3-cross-signed.pem"
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convenience.
#SSLCertificateChainFile "${SRVROOT}/conf/server-ca.crt"
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath "${SRVROOT}/conf/ssl.crt"
#SSLCACertificateFile "${SRVROOT}/conf/ssl.crt/ca-bundle.crt"
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded).
# The CRL checking mode needs to be configured explicitly
# through SSLCARevocationCheck (defaults to "none" otherwise).
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath "${SRVROOT}/conf/ssl.crl"
#SSLCARevocationFile "${SRVROOT}/conf/ssl.crl/ca-bundle.crl"
#SSLCARevocationCheck chain
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# TLS-SRP mutual authentication:
# Enable TLS-SRP and set the path to the OpenSSL SRP verifier
# file (containing login information for SRP user accounts).
# Requires OpenSSL 1.0.1 or newer. See the mod_ssl FAQ for
# detailed instructions on creating this file. Example:
# "openssl srp -srpvfile ${SRVROOT}/conf/passwd.srpv -add username"
#SSLSRPVerifierFile "${SRVROOT}/conf/passwd.srpv"
# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o StrictRequire:
# This denies access when "SSLRequireSSL" or "SSLRequire" applied even
# under a "Satisfy any" situation, i.e. when it applies access is denied
# and no other module can change it.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory "${SRVROOT}/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is sent or allowed to be received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
CustomLog "C:/wamp64/logs/access_ssl.log" \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
comme otto dit toujours a ces membres faites des vhosts moi je veux bien mais avec noip je n ais pas trouve comme rediriger mon nom de domaine directement dans le dossier de mon site dans le www pour ne poas me retrouver avec le nom de domaine/dossier du site voila mon plus gros probleme et pour l instant tous les fichiers de mon forom sont dans ce dossiers wwww et pour obtenir larborescence du root de wamp j ai renommer le index en index2.php
Pour créer un VHOST vers le dossier que tu veux, c'est pas compliqué.
On va créer un VHOST qui utilisera le dossier C:\wamp\www\forum
Regarde :
Vu que maintenant tu utilises le module mod_md, on va créer un VHOST qui utilisera ce module.
Le domaine sera example.com et www.example.com
<MDomain example.com>
MDCertificateFile "c:/wamp/md/domains/example.com/pubcert.pem"
MDCertificateKeyFile "c:/wamp/md/domains/example.com/privkey.pem"
</MDomain>
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com
DocumentRoot "E:/wamp/www/forum"
SSLEngine on
<directory E:/wamp/www/forum>
Require ip 127.0.0.1
<IfModule mod_headers.c>
# HSTS
#Header always set Strict-Transport-Security "max-age=15552000"
# secured cookies
#Header always edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
</IfModule>
</directory>
</VirtualHost>
Et voilà, c'est fini ! :)
Salut,
Tout d'abord vraiment merci pour ta réponse.
Cela fonctionne maintenant.
J'avais bien fait tout le tuto j'ai tout lu est au moins 3 fois.
Je m'était permis quelques "options" dans le VirtualHost tel que:
SSLVerifyClient require
SSLVerifyDepth 10
<Directory />
SSLOptions +StdEnvVars
Options -Indexes +FollowSymLinks +MultiViews
AllowOverride none
<RequireAny>
Require local
</RequireAny>
</Directory>
et d'autre encore...
De plus j'ai encore d'autres "options" dans le module bref cela fonctionne maintenant.
J'ai du un peu bidouillé pour tout adapter à mon chantier.
Mais avec ton tuto et m’être appuyé sur forum.wampserver.com Tout fonctionne.
C'est pourquoi je vous remercie toi et Otomatic.
Un grand merci vraiment, je salut vraiment la qualité de la suite de ton travail pour le renouvellement automatique.
PS: je suis loing d'etre aussi bon que toi mais example pour toi veut aussi dire example pour moi. :ih:
J'avais l'habitude de faire accepter les certificats par FireFox a cause des certificats auto Signés en local (Là j'ai plané)
Bonne journée!
Ce message fait suite à la "mort" de la racine DST Root CA X3 (Alex)
bonjour,
je suis sous windows 7, j'ai suivi votre tuto pour installer les nouveaux certificats, à priori c'est bon dans le manager de certificats mais j'ai toujours ce message lorsque je veux renouveler le certificat de mon site :
c:\xampp\ssl>le64.exe --key account-key.key --email "r.fra@laposte.net" --csr server.csr --crt server.crt --generate-missing --unlink --path "C:\xampp\htdocs\.well-known\acme-challenge" --live
2021/09/30 19:38:23 [ Crypt::LE client v0.37 started. ]
2021/09/30 19:38:23 Loading an account key from account-key.key
2021/09/30 19:38:23 Loading a CSR from server.csr
2021/09/30 19:38:26 Could not load the resource directory: SSL connection failed for acme-v02.api.letsencrypt.org: SSL connect attempt failed error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
pouvez-vous m'aider ?
je précise que les fichiers account-key.key, server.csr et server.key sont bien créés
le précédent certificat est valide jusqu'au 10 octobre.
merci d'avance,
François
bonjour Alex,
grand merci pour ton aide, je te confirme que mon problème venait bien de ma version LE.exe et que la version 0.38 a résolu le problème.
mon certificat est valide jusqu'au 31 décembre 2021 !
jusqu'à présent j'utilisais la version 0.35, hier, avant de te demander ton aide, je suis allé sur github et c'est la version 0.37 qui a été téléchargée, ce matin (1er octobre) j'ai suivi ton lien et c'est bien la version 0.38 qui est maintenant disponible.
pour faire un essai, j'ai relancé le script une seconde fois et il me répond :
c:\xampp\ssl>le64.exe --key account-key.key --email "r.fra@laposte.net" --csr server.csr --crt server.crt --generate-missing --unlink --path "C:\xampp\htdocs\.well-known\acme-challenge" --live
2021/10/01 15:19:12 [ Crypt::LE client v0.38 started. ]
2021/10/01 15:19:12 Loading an account key from account-key.key
2021/10/01 15:19:12 Loading a CSR from server.csr
2021/10/01 15:19:16 Registering the account key
2021/10/01 15:19:16 The key is already registered. ID: 221961220
2021/10/01 15:19:16 Current contact details: r.fra@laposte.net
2021/10/01 15:19:17 [b]Received domain certificate, no validation required at this time.[/b]
2021/10/01 15:19:17 Requesting issuer's certificate.
2021/10/01 15:19:17 Saving the full certificate chain to server.crt.
2021/10/01 15:19:17 The job is done, enjoy your certificate!
"no validation required at this time" je suppose que ça veut dire qu'on ne peut renouveler un certificat que dans le mois qui précède sa date d'expiration ?
encore grand merci et j'espère que cela permettra à d'autres de mettre à jour leur certificat.
Cordialement,
François