Forum Linux.debian/ubuntu activation ssl en local

Posté par gerard le 17 septembre 2019 à 07:54. Licence CC By‑SA.

Étiquettes :

sept.

2019

activation ssl en local

Bonjour,
J’ai installé Debian en local, et mise en place la solution lamp plus phpMyAdmin pour gérer mes sites web.
Enfin, j'ai installé LetSenCrypt pour crypter mes données entre mon serveur et celle des clients pour une meilleurs sécurités et protections sensibles de mes utilisateurs.
Mais seulement voilà, lorsque je tente d'activer le certificat ssl de mes noms de domaine, mes sites sont par la suite inaccessibles que ce soit en http qu’en https.

Alors j'ai tenté de le faire chez mon hébergeur, j'ai fait la même chose que j'ai fait en local, l'installation de lamp et de phpMyAdmin et là, j'arrive à avoir le certificat ssl qui fonctionne bien, mes noms de domaines passent bien ssl et je peux donc y accéder à mes sites via https.

Ma question est, pour qu'elle raison mes activations en ssl de mes noms de domaine fonctionne t'ils chez l'hébergeur "ovh" et non pas en local chez moi.

# C'est un comportement normal

Posté par seb le 17 septembre 2019 à 09:21. Évalué à 2. Dernière modification le 17 septembre 2019 à 09:21.

Salut,

Le but du SSL est entre autre d'essayer de garantir la communication entre le client et le serveur.
Lors de la création de ton certificat tu as renseigné un nom de domaine qui est donc le seul légitime.

Pour accéder en local, tu peux essayer via ton ip mais ça devrait te donner une erreur.
Sinon un certificat auto-signé pour l'environnement local devrait faire l'affaire.
- [^] # Re: C'est un comportement normal
  
  Posté par gUI (Mastodon) le 17 septembre 2019 à 10:45. Évalué à 2.
  
  Et si tu fais en local en mettant ton.domaine.tld dans ton /etc/hosts (et le faire pointer sur 127.0.0.1 ou une IP locale), ça pourrait marcher ?
  
  En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
  - [^] # Re: C'est un comportement normal
    
    Posté par gerard le 18 septembre 2019 à 00:18. Évalué à 1.
    
    Bonjour gUI,
    je vais creuser là dessus aussi.
    je vais essayer de le tester par la suite
# ports du routeur ?

Posté par ComputingFroggy (site web personnel) le 17 septembre 2019 à 09:23. Évalué à 1.

D'après ce que tu dis, j'aurai tendance à penser que c'est un problème de ports qui ne sont pas ouverts sur le routeur (ou de firewall).

Cependant, je trouve étonnant qu'en http tu n'arrives plus à accéder à tes sites. Je ne vois pas ce que l'activation du certificat SSL change à Apache ? ! ?

Peut-être que quelqu'un d'autre sera plus inspiré.
- [^] # Re: ports du routeur ?
  
  Posté par NeoX le 17 septembre 2019 à 11:39. Évalué à 2.
  
  Cependant, je trouve étonnant qu'en http tu n'arrives plus à accéder à tes sites. Je ne vois pas ce que l'activation du certificat SSL change à Apache ? ! ?
  
  apache ne se lancerait plus quand il remplace les certificats par defaut d'apache par ceux de letsencrypt ?
- [^] # Re: ports du routeur ?
  
  Posté par gerard le 18 septembre 2019 à 00:24. Évalué à 1.
  
  Bonjour ComputingFroggy, tout les ports 80, 443, 22 sont bien ouvert dans le routeur.
  comme je l'ai dit plus haut, le deux sites fonctionnes bien lorsque je n'active pas le ssl de mes noms de domaine avec letsencrypt.
  c'est en activant, que les deux noms de domaine que j'ai activé qui ne fonctionne plus.
  je n'ai pas encore trouvé de raison logique pour le instant.
# truc de base à savoir

Posté par NeoX le 17 septembre 2019 à 10:17. Évalué à 2.

letsencrypt a besoin d'un nom de domaine pour generer le certificat,
et lors de sa creation, il essaie d'acceder à http://ton.domaine.tld

s'il n'y arrive pas, il ne genere pas de certificat.

si dans ton cas il a généré un certificat, c'est que le domaine est accessible du point de vue de letsencrypt (de l'exterieur de chez ta machine/ton reseau)

en local, il te faut alors un DNS qui renvoie un client de ton.domaine.tld -> ip locale du serveur local
- [^] # Re: truc de base à savoir
  
  Posté par gerard le 18 septembre 2019 à 00:14. Évalué à 1.
  Bonsoir Neox,
  C'est très intéressante ta suggestion, concernant la mise en place d'une configuration DNS.
  Seulement voila, je ne maîtrise pas vraiment le DNS.
  Mais après quelques recherche, j'ai trouvé le site suivante
  "https://www.tutoriels-video.fr/installation-dun-serveur-ftp-et-configuration-dun-nom-de-domaine-dn/" et voici ce que je pense faire, avec quelques interrogation que j'ai souligné ci_dessus :
  1.
  configuration de la zone dans : #/etc/bind/named.conf.local#
```
 zone "pclocal.cf" {
      type master;
      file "/etc/bind/db.pclocal.cf";
      allow-transfer {ip_local_type_master;};
      allow-query{any;};
      notify yes;
 };
```
  Commentaire :
  Pour l'adresse #ip_local_type_master# je ne sais pas qu'elle IP je dois mettre ici
  
  2.
  Commentaire :
  pour la configuration d’un fichier de zone dans #/etc/bind/db.pclocal# :
  ; pclocal.cf
  $TTL 3600
  @ IN SOA "que dois je mettre ici". root.pclocal.cf. (
  2011020906 ; SERIAL
  3600; REFRESH
  15M; RETRY
  1W; EXPIRE
  600 ) ; Negative Cache TTL
  ;
  ; NAMESERVERS
  ;
  pclocal.cf. IN NS "que dois je mettre ici"
  pclocal.cf.fr. IN NS "que dois je mettre ici"
  ;
  ; Nodes in domain
  ;
  www IN A "que dois je mettre ici"
  mail IN A "que dois je mettre ici"
  ns1 IN A "que dois je mettre ici"
  smtp IN A "que dois je mettre ici"
  pop IN A "que dois je mettre ici"
  ftp IN A "que dois je mettre ici"
  imap IN A "que dois je mettre ici"
  pclocal.cf. IN A "que dois je mettre ici"
  pclocal.cf. IN MX 10 "que dois je mettre ici"
  ;
  ; subdomains
  ;
  *.pclocal.cf. IN A "que dois je mettre ici"
  
  3.
  Je suis chez Free.
  Qu'elle adresse du nom de serveur DNS je dois mettre pour le type primaire et le type secondaire.
  
  Gérard
  - [^] # Re: truc de base à savoir
    
    Posté par NeoX le 19 septembre 2019 à 18:45. Évalué à 2.
    1.
    configuration de la zone dans : #/etc/bind/named.conf.local#
```
 zone "pclocal.cf" {
      type master;
      file "/etc/bind/db.pclocal.cf";
      allow-transfer {ip_local_type_master;};
      allow-query{any;};
      notify yes;
 };
```
    ~~Commentaire~~ Question :
    Pour l'adresse #ip_local_type_master# je ne sais pas qu'elle IP je dois mettre ici
    
    Reponse : tu mets un # devant, car tu n'as qu'un seul serveur DNS
    si tu en avais plusieurs, tu aurais un DNS master et tu mettrais cette ligne sur les slave qui vont recevoir les modifications de leur master
    
    2.
    Commentaire :
    pour la configuration d’un fichier de zone dans #/etc/bind/db.pclocal# :
```
$TTL 3600
@ IN SOA "que dois je mettre ici". root.pclocal.cf. (
2011020906 ; SERIAL
3600; REFRESH
15M; RETRY
1W; EXPIRE
600 ) ; Negative Cache TTL
 ;
 ; NAMESERVERS
 ;
pclocal.cf. IN NS "que dois je mettre ici"
pclocal.cf.fr. IN NS "que dois je mettre ici"
 ;
 ; Nodes in domain
 ;
www IN A "que dois je mettre ici"
mail IN A "que dois je mettre ici"
ns1 IN A "que dois je mettre ici"
smtp IN A "que dois je mettre ici"
pop IN A "que dois je mettre ici"
ftp IN A "que dois je mettre ici"
imap IN A "que dois je mettre ici"
pclocal.cf. IN A "que dois je mettre ici"
pclocal.cf. IN MX 10 "que dois je mettre ici"
 ;
 ; subdomains
 ;
*.pclocal.cf. IN A "que dois je mettre ici"
```
    en face d'un IN A
    tu dois mettre l'IP de la machine qui va fournir le service pour ce domaine.
    imap IN A une adresse IP qui fournira le service imap.pclocal.cf
    
    idem pour le MX, sauf que lui, c'est celui qui recoit les emails @pclocal.cf
    
    les lignes sont optionnelles, si tu n'as pas de services sous ce nom.
    et à l'inverse tu peux avoir
    PC1 IN A IP_a_b_c_d
    PC2 IN A IP_e_f_g_h
    
    NB : quand tu changes la configuration dans le fichier db.pclocal.cf
    il faut augmenter le serial qui est generalement la date du jour 20190919xxx
    avec xxx le numero de la modification dans la journée
    
    3.
    Je suis chez Free.
    Qu'elle adresse du nom de serveur DNS je dois mettre pour le type primaire et le type secondaire.
    
    j'imagine que c'est pour les "forwarders" à qui le DNS BIND va demander s'il ne connait pas un domaine,
    
    perso j'utilise les DNS de OPENDNS, mais tu peux aussi utiliser ceux de google (8.8.8.8) , ou de cloudflare (1.1.1.1)
- [^] # Re: truc de base à savoir
  
  Posté par gerard le 18 septembre 2019 à 17:09. Évalué à 1.
  
  Bonjour NeoX,
  j'ai installé bind sur Debian 10, afin de configurer les DNS et rien que le fait d'avoir installé bind, j'ai le http qui fonctionne.
  est ce parce que, lors de la configuration de LetsEncrypt auto, le fait d'avoir fait le choix pour que les redirections des noms de domaine ne soit pas obligatoire fait que j'arrive à accéder à mon site avec le http.
  A présent je vais maintenant tacher de configurer le DNS et voir si cela va marcher.
  - [^] # Re: truc de base à savoir
    
    Posté par gerard le 11 octobre 2019 à 22:18. Évalué à 1.
    
    Rebonjour à tous,
    je reviens après avoir maîtrise la mise en place des DNS.
    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.
    mais nom de domaine fonctionne bien en http sans l'activation avec letsencrypt de mon nom de domaine demossl.cf avec le https.
    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, comme dit plus haut.
    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.
    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, 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.
    A l'aide !!!
    - [^] # Re: truc de base à savoir
      
      Posté par NeoX le 12 octobre 2019 à 10:58. Évalué à 2.
      bien comprendre qui va ou.
      
      en local
      
      ton PC demande tondomaine.tld (http ou https) à ton DNS local (Freebox ou service DNS)
      
      le DNS lui donne l'IP du serveur qui gère ce domaine (ip publique de la Freebox ou ip interne) ?
      
      ton PC tente de se connecter sur cette IP, sur le port 80 (http) ou 443 (https)
      
      dans le cas de letsencrypt,
      
      c'est les serveurs de letsencrypt qui demande à leur DNS ou se trouve ton serveur il faut donc configurer ton DNS externe pour que ca renvoie sur l'IP de ta Freebox
      
      le serveur de letsencrypt tente de se connecter à l'IP de ta Freebox, port 80 ou port 443 il faut configurer ta Freebox pour renvoyer ces ports vers ton serveur interne
      
      il cherche un fichier sur le serveur pour confirmer que le domaine arrive bien sur le bon serveur.
      
      pour diagnostiquer, tu peux deja tenter d'aller sur ton serveur, port 443
      en faisant https://adresseIPlocale
      
      ca te permettra de savoir si le serveur écoute en https
      
      ensuite il faut te connecter de l'extérieur (4G ?) en faisant https://addresseIPpublique
      ca doit te renvoyer la meme chose si la redirection de la Freebox vers le serveur est opérationnel
      - [^] # Re: truc de base à savoir
        
        Posté par gerard le 13 octobre 2019 à 12:28. Évalué à 1.
        
        j'utilise un serveur pour testé et c'est 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 pas 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.
        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.
        quand à mon nom de domaine il chez mon registrar il pointe bien vers mon adresse ip public.
        
        lorsque j'active pas le certificat de mon nom de domaine, j’accède donc bien à mon site lorsque je suis à la bibliotheque
        de mon quartier avec l'adresse http://demossl.cf. qui à pour dossier …/demosslcf/www/index.php
        et lorsque je tape mon adresse ip public, il pointe bien vers le site par défaut de apache qui se trouve dans le dossier /var/www/html/index.html
        Par contre comme je l'ai dit plus haut, lorsque j'active le ssl de mon nom de domaine demossl.cf en tapant dans la barre d'adresse
        https://demossl.cf, j’obtiens une page d'erreur : "Le délai d’attente est dépassé".
        
        on peux donc dire que la Personnaliser du contenu de DNS chez le rigistrar est bien fait, puisque j’accède à mon site sans aucun problème, lorsque j’enlève inactivation de mon nom de domaine lorsqu’il n'est plus en https.
        
        [^] # Re: truc de base à savoir
        
        Posté par NeoX le 13 octobre 2019 à 17:48. Évalué à 2. Dernière modification le 13 octobre 2019 à 17:49.
        
        Par contre comme je l'ai dit plus haut, lorsque j'active le ssl de mon nom
        
        le SSL tu l'actives ou ?
        chez ton registrar ou sur ton serveur ?
        
        sur ton serveur, tu as copier les certificats et clef dans les dossiers pour apache ?
        tu as mis les lignes qui vont bien dans le fichier de configuration de ton "domaines.cf" ?
        
        si le port 80 tombe aussi quand tu "actives" le SSL,
        c'est possiblement que le certificat n'est pas ouvert,
        apache ne se lance plus, et donc aucun service ne répond sur le port 80 ou 443
        
        la redirection de port, c'est juste en TCP/80 et TCP/443 pour le http et https.
        
        le DNS interne, c'était surtout pour toi, pour pouvoir demander
        https://domaine.cf et aller directement sur ta machine serveur sans sortir sur internet
        car certaines box n'aiment pas le fait de sortir et rerentrer

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.