Forum Linux.android Client XMPP Chatsecure : certificat SSL reject

Posté par . Licence CC by-sa.
Tags : aucun
0
26
déc.
2017

Bonjour à tous,

J'ai mis en place un serveur prosody qui fonctionne plutôt bien jusqu'ici avec l'application conversations.

J'essaie également de faire en sorte que l'application chatsecure puisse envoyer des photos/vidéos comme l'appli conversations.

Le problème est qu'à priori le certificat que j'ai créé est rejeté par l'application chatsecure.

C'est un certificat auto-signé qui me permet de le transmettre du serveur vers les clients.

Question : Comment faire en sorte qu'un certificat SSL soit validé par l'application chatsecure ?

Merci par avance.

  • # Autorité pour création de certificats ?

    Posté par . Évalué à 2.

    A priori la raison est parce que le certificat créé n'est pas créé par une autorité.

    Par quel organisation passer pour créer mon certificat ?

    Lien chat secure : https://chatsecure.org/blog/page3/

    • [^] # Re: Autorité pour création de certificats ?

      Posté par . Évalué à 1.

      Voici l'erreur que j'ai en ce moment, je pense que c'est parce que je n'ai pas ouvert le port 443 sur ma box mais ouvert sur ma pi.

      root@raspberrypi:/home/pi# certbot renew --dry-run
      Saving debug log to /var/log/letsencrypt/letsencrypt.log
      
      -------------------------------------------------------------------------------
      Processing /etc/letsencrypt/renewal/serveur1.fr.conf
      -------------------------------------------------------------------------------
      Cert not due for renewal, but simulating renewal for dry run
      Plugins selected: Authenticator standalone, Installer None
      Attempting to renew cert (serveur1.fr) from /etc/letsencrypt/renewal/serveur1.fr.conf produced an unexpected error: HTTPSConnectionPool(host='acme-staging.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x76a50af0>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',)). Skipping.
      All renewal attempts failed. The following certs could not be renewed:
        /etc/letsencrypt/live/serveur1.fr/fullchain.pem (failure)
      
      -------------------------------------------------------------------------------
      ** DRY RUN: simulating 'certbot renew' close to cert expiry
      **          (The test certificates below have not been saved.)
      
      All renewal attempts failed. The following certs could not be renewed:
        /etc/letsencrypt/live/serveur1.fr/fullchain.pem (failure)
      ** DRY RUN: simulating 'certbot renew' close to cert expiry
      **          (The test certificates above have not been saved.)
      -------------------------------------------------------------------------------
      1 renew failure(s), 0 parse failure(s)
  • # Let's Encrypt est ton ami ?

    Posté par (page perso) . Évalué à 2.

    Let's Encrypt permet de récupérer des certificats qui sont considérés de confiance par environ tout le monde. Il y a même une page côté Prosody pour faire le lien entre Let's Encrypt et Prosody.

    Debian Consultant @ DEBAMAX

    • [^] # Re: Let's Encrypt est ton ami ?

      Posté par . Évalué à 1.

      Effectivement mais je ne vois pas pourquoi je n'arrive pas à en créer ! Il faut que le port 443 soit ouvert ?

      Egalement avec la commande qui va bien est-ce que le certificat sera auto-signé => en gros ai-je besoin de le transférer manuellement sur les téléphones ou alors le certificat sera proposé automatiquement ?

      Merci

      • [^] # Re: Let's Encrypt est ton ami ?

        Posté par . Évalué à 2.

        Effectivement mais je ne vois pas pourquoi je n'arrive pas à en créer ! Il faut que le port 443 soit ouvert ?

        c'est actuellement la contrainte avec letsencrypt,
        c'est qu'il teste ton serveur uniquement sur le port 443
        à toi ensuite de rediriger ce port vers le bon service avec le bon certificat

        • [^] # Re: Let's Encrypt est ton ami ?

          Posté par (page perso) . Évalué à 1.

          Pas besoin de redirection vers le bon service avec le bon certificat ? certbot a un mode standalone.

          Du coup une redirection de 80/443 de la box vers la bonne machine, et certbot écoutera le temps qu'il faut pour faire le renouvellement, et l'écoute locale sur ces ports s'arrêtera juste après ? Conséquence : absolument aucun impact sur le serveur XMPP, qui ne voit pas passer de connexions « étranges ».

          Debian Consultant @ DEBAMAX

          • [^] # Re: Let's Encrypt est ton ami ?

            Posté par . Évalué à 1. Dernière modification le 30/12/17 à 10:14.

            Merci pour vos remarques.

            J'ai retenté la commande ce matin. J'ai redirigé le port box 443 vers 443 (ou autre du service XMPP) de la pi et idem pour le 80 mais rien n'y fait, j'ai toujours la même erreur (26/12/17 à 19:11) en lançant l'une des deux commandes :

            certbot renew --deploy-hook "prosodyctl --root cert import /etc/letsencrypt/live"

            certbot renew --dry-run

            • [^] # Re: Let's Encrypt est ton ami ?

              Posté par . Évalué à 2.

              j'ai toujours la même erreur (26/12/17 à 19:11) en lançant l'une des deux commandes :

              quelle erreur ?

  • # J'crois que c'est clair...

    Posté par (page perso) . Évalué à 2.

    Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'

    [tth@padawan ~/POV/Parking]$ host serveur1.fr
    Host serveur1.fr not found: 3(NXDOMAIN)
    

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: J'crois que c'est clair...

      Posté par (page perso) . Évalué à 1.

      Je m'étais dit initialement que le nom du serveur avait pu être « anonymisé » en serveur1.fr pour la question dans le forum… mais effectivement, il est impératif que les serveurs Let's Encrypt puissent résoudre le(s) nom(s) spécifié(s) et se connecter sur les ports qui vont bien.

      Debian Consultant @ DEBAMAX

      • [^] # Re: J'crois que c'est clair...

        Posté par . Évalué à 1. Dernière modification le 31/12/17 à 11:00.

        En effet serveur1.fr n'est pas nom de domaine.

        Par contre, j'ai remarqué qu'en supprimant les règles de mon part-feu de ma raspberry et avec les ports 443 & 80 ouvert de ma box redirigé vers la raspberry, j'ai réussi à générer un certificat -> plus d'erreur.

        Pourtant j'avais bien ajouté les exceptions au port 443 et 80 en INPUT, qu'est-ce que je devrais ajouter en plus comme exception à mon part-feu ?

        Voici les règles concernant le port 443 et 80 :

        # Certificat (Prosody)
        /sbin/iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
        /sbin/iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
        root@raspberrypi:/home/pi# iptables -L
        Chain INPUT (policy DROP)
        target     prot opt source               destination         
        ACCEPT     all  --  anywhere             anywhere            
        ACCEPT     icmp --  anywhere             anywhere            
        ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:4448
        ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
        ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
        ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:xmpp-client state NEW,RELATED,ESTABLISHED
        ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:xmpp-server state NEW,RELATED,ESTABLISHED
        ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:5280 state NEW,RELATED,ESTABLISHED
        ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:5281 state NEW,RELATED,ESTABLISHED
        
        Chain FORWARD (policy ACCEPT)
        target     prot opt source               destination         
        
        Chain OUTPUT (policy ACCEPT)
        target     prot opt source               destination         
        ACCEPT     all  --  anywhere             anywhere            
        ACCEPT     icmp --  anywhere             anywhere

        Je ne vois pas ce qui peut pauser problème. Qu'est-ce que je dois ajouter comme exception pour que la commande suivante se fasse sans erreur du port 443 : certbot certonly -d serveur1.fr !?

        Merci d'avance

        • [^] # Re: J'crois que c'est clair...

          Posté par . Évalué à 1. Dernière modification le 31/12/17 à 17:37.

          En complément à cela,

          J'ai lancé la commande suivante :

          ss -nltp
          
          LISTEN   0   5 :::443   :::*   users:(("certbot",pid=3437,fd=8))

          A ce qu'on m'a dit c'est de l'ipv6 :::443

          Je vous recopie mon pare feu ipv4 avec iptables-persistant (j'ai créé l'exception pour le port 443 tout de même, … je ne comprend pas)

          *filter
          :INPUT DROP [0:0]
          :FORWARD ACCEPT [0:0]
          :OUTPUT ACCEPT [13:1456]
          -A INPUT -i lo -j ACCEPT
          -A INPUT -i eth0 -p icmp -j ACCEPT
          -A INPUT -p tcp -m tcp --dport 4448 -j ACCEPT
          
          #-A OUTPUT -p udp --dport 53 -j ACCEPT
          #-A OUTPUT -p tcp --dport 21 -j ACCEPT
          #-A OUTPUT -p tcp --dport 80 -j ACCEPT
          
          #-A INPUT -p udp --dport 53 -j ACCEPT
          #-A INPUT -p tcp --dport 21 -j ACCEPT
          #-A INPUT -p tcp --dport 80 -j ACCEPT
          
          -A INPUT -p tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
          -A INPUT -p tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
          
          #-A OUTPUT -p tcp -m multiport --dports 80,443,8000 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
          #-A INPUT -p tcp -m multiport --sports 80,443,8000 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
          
          -A INPUT -p tcp -m tcp --dport 5222 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
          -A INPUT -p tcp -m tcp --dport 5269 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
          -A INPUT -p tcp -m tcp --dport 5280 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
          -A INPUT -p tcp -m tcp --dport 5281 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
          
          -A OUTPUT -o lo -j ACCEPT
          -A OUTPUT -o eth0 -p icmp -j ACCEPT

          Enfin voila, avec mon pare feu certbot ne fonctionne pas (toujours la même erreur), même un aptitude install en fonctionne pas !

          • [^] # Re: J'crois que c'est clair...

            Posté par (page perso) . Évalué à 2.

            (toujours la même erreur)

            Quelle erreur ?

            * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

            • [^] # Re: J'crois que c'est clair...

              Posté par . Évalué à 0.

              Résultat d'un petit Wireshark.

              Les ports que je peux ouvrir dans mon firewall sont les suivants :
              53
              443

              Les ports qui sont utilisés aléatoirement :
              35260
              49008

              Les IP :
              10.0.0.1
              10.0.0.3
              2.18.117.197

              => Comment autoriser les ports d'entrées utilisés aléatoirement en sortie ? avec les états RELATED,ESTABLISHED

Suivre le flux des commentaires

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