Activation ssl pour un serveur en local

J’ai donc créer un serveur DNS avec lequel j’ai installé mon nom de domaine demossl.cf.
j’ai fait les tests du serveur DNS avec “named-checkconf -z” et la commande “dig” et tous fonctionne bien.
mon nom de domaine fonctionne bien en http sans l’activation avec letsencrypt de mon nom de domaine demossl.cf avec l extension http.
lorsque j’ active mes noms de domaine en https en local avec apache2, je n’arrive plus à accéder à mon site en https et http puisqu’il y a la redirection du http vers le https.
je rappel que je travail avec un serveur en local avec free, j’ai aussi ouvert le port 53 dans l’un des fichiers de configuration de bind9.
Et là j’arrive à mon maximum, je suis cuit du cerveau.
j’ai fait des recherche partout sur le net, mais je ne trouve pas comment activer en https avec debian9 et apache2 mon nom de domaine demossl.cf.
Pourtant chez ovh tous fonctionne bien et je n’ai aucun mal à activé mon nom de domaine demossl.cf en https et cela, sans même mettre en place un serveur DNS avec bind9.
Qu’est ce qui me manque comme configuration en local pour que cela fonctionne.
si quelqu’un entend mon appel d’aide qu’il se manifeste en tant héro saitama, car là j’en peux plus.
Afin que je sois libéré, car je suis dans ma cage depuis plusieurs semaines et ça craint pour moi maintenant.
Qu’un héro viennent à mon secours.

mot clé : domaine - nom - https - certificats - letsencrypte

Bonjour,
Je ne suis pas un spécialiste, mais est-ce que c’est ton certificat letsencrypt que tu n’arrives pas à installer ?
Quels sont tes ports ouverts (443/https) ?

Bind9, OSEF, la zone pourrait être gérée ailleurs sur un autre serveur ou chez ton isp, ça n’a aucune importance dans l’histoire, jamais letsencrypt ne s’en sert directement, il a juste besoin dans un premier temps de résoudre le ndd que tu veux certifier.
Donc première question:
est ce que de l’extérieur (en interrogeant le resolveur de ton free par exemple), le nom de domaine que tu veux certifier se résoud bien avec les ip free v4 et v6 de ta box internet ?

La redirection n’est pas automatique juste parce que tu actives un virtualhost https sur ton serveur.
Pour qu’il y ai redirection, il faut que tu explicites une règle dans la configuration de ton virtualhost, le htaccess de ton site, ou bien que tu passes un header dynamiquement au niveau du site.
Mais bon, bref, a priori, cette redirection n’est pas un probléme lors de la validation du certificat.

Et c’est important, car pour générer le certificat, letsencrypt a besoin d’accéder au serveur http du domaine.
Mais depuis où as tu testé cet accès http ?
Depuis une machine située sur ton LAN ou est ton serveur ?
Et on parle bien d’un test avec une résolution par le nom de domaine, d’un accés à http://mondomaine.cf ?
Es tu sûr d’avoir bien mis une redirection sur ta box des ports exterieurs 80/443 vers l’ip interne de ton serveur ?

Reponse 1

hero:
je rappel que je travail avec un serveur en local avec free, j’ai aussi ouvert le port 53 dans l’un des fichiers de configuration de bind9.
Bind9, OSEF, la zone pourrait être gérée ailleurs sur un autre serveur ou chez ton isp, ça n’a aucune importance dans l’histoire, jamais letsencrypt ne s’en sert directement, il a juste besoin dans un premier temps de résoudre le ndd que tu veux certifier.
Donc première question:
est ce que de l’extérieur (en interrogeant le resolveur de ton free par exemple), le nom de domaine que tu veux certifier se résoud bien avec les ip free v4 et v6 de ta box internet ?
On effet tu a raison, la configuration dns ne rendre pas en compte pour activé un domaine https pour crypté les données d’un site et le sécurisé, mais j’ai tenté de voir si le fait de mettre en place un serveur dns, cela allait resoudre mon problème, mais ça n’a pas été le cas.
Dans ta question :
[
Est-ce que de l’extérieur (en interrogeant le resolveur de ton free par exemple), le nom de domaine que tu veux certifier se résoud bien avec les ip free v4 et v6 de ta box internet ?
]
Je ne connaît pas le mot resolveur de free, mais ce que je peux dire, c’est que, de l’ordinateur de la bibliothèque de mon cartier j’accède à mon site http://demossl.cf, par contre lorsque je mis mon nom de domaine en https, je n’arrive plus à accéder à mon site avec https://demossl.cf.
Avec comme chemin […/demosslcf/www/index.php ]
Lorsqu’on tape mon IP de free, on accède bien au site par défaut d’apache qui se trouve dans le dossier [/var/www/html/index.html]

**

Reponse 2

**

hero:
lorsque j’ active mes noms de domaine en https en local avec apache2, je n’arrive plus à accéder à mon site en https et http puisqu’il y a la redirection du http vers le https.
La redirection n’est pas automatique juste parce que tu actives un virtualhost https sur ton serveur.
Pour qu’il y ai redirection, il faut que tu explicites une règle dans la configuration de ton virtualhost, le htaccess de ton site, ou bien que tu passes un header dynamiquement au niveau du site.
Mais bon, bref, a priori, cette redirection n’est pas un probléme lors de la validation du certificat.
Effectivement, comme tu l’as dit toi-même, la redirection n’est pas un problème lors de la validation du certificat du nom de domaine,
En effet, lorsqu’on lance letsenscript avec la commande :
[
/opt/letsencrypt/letsencrypt-auto
]
Il se charge de tous, il te demande si on souhaite faire une redirection automatique de ton nom de domaine vers le https, lorsque tu valide, il fait le reste de la configuration sans que tu interviennes.
Et comme je l’ai dis plus haut, chez OVH, aucun problème tous fonctionne à merveille lorsque je le configure.

Reponse 3

hero:
mon nom de domaine fonctionne bien en http
Et c’est important, car pour générer le certificat, letsencrypt a besoin d’accéder au serveur http du domaine.
Mais depuis où as tu testé cet accès http ?
Depuis une machine située sur ton LAN ou est ton serveur ?
Et on parle bien d’un test avec une résolution par le nom de domaine, d’un accés à http://mondomaine.cf ?
Es tu sûr d’avoir bien mis une redirection sur ta box des ports exterieurs 80/443 vers l’ip interne de ton serveur ?

Mon serveur est testé depuis avec un pc portable que j’utilise chez moi. Avant, je n’avais pas de problème car les noms de domaine et les sites n’avais besoins d’être crypté, mais sous peu, pour une meilleure sécurité des données clients, tout est en https.
Du coup je dois passé tous mes sites en https.
Donc, les redirections des ports sont bien fait dans mon routeur de free.
Le port du routeur 80 en tcp et udp pointe bien vers ma machine interne qui est en ipv4, y compris pour les autres port 22 pour le ftp et le port 443 pour le ssl.
Le module d’apache ssl est bien activé et apache écoute bien sur le port 443.
Et je suis pose que, lorsque tu dit :
[
Et on parle bien d’un test avec une résolution par le nom de domaine, d’un accés à http://mondomaine.cf ?
]
Tu veux dire qu’on parle bien du nom de domaine « mondomaine.cf ».
Si c’est bien ce que tu veux dire, alors oui, il s’agit bien d’un nom de domaine demossl.cf, qu’on peut avoir accès en tapant http://demossl.cf

Récapitulation

Comme tu peux bien le voir, normalement, cela devrait fonctionner après tous ce que j’ai fait.
C’est pour cette raison, que je fais appel à un héro, car j’en peux plus.
Help me hero !!!

Pourrais tu être plus précis: quel message t’indique le navigateur, exactement ?
“impossible de trouver l’adresse IP du serveur” ?
“demossl.cf n’autorise pas la connection” ?
Autre ?

OK, donc la resolution d’ip est bonne, et ta redirection du port 80 aussi.

Là je ne comprends pas.
Normalement, à la fin de cette commande, les certificats devraient être installés, et si ça s’est mal passé, tu as le détail des opérations qui te dit où ça a planté.
Pourrais tu retrouver dans history la commande exacte que tu as utilisée avec tous les arguments, ainsi que les traces que ça a généré dans /var/log/letsencrypt/letsencrypt.log