Salut!
Avant d'abandonner l'approche, je poste ici le dernier truc bizarre dès fois que ça cause à l'un d'entre vous :
On a donc installé un serveur BigBlueButton dans un conteneur LXC... Redirection des ports, firewall é tutti quanti...
Le serveur web HTML5 est en défaut, à priori pour une histoire de certificat SSL.
Précision : c'est du Let's Encrypt géré par la machine host.
Donc, le truc bizarre : wget https://visio.connect.cafe/default.pdf
Cela fonctionne nickel de l'extérieur... vous pouvez tester, mais pas quand je la lance à partir du LXC (en root) : root@big-blue-button:~# wget https://visio.connect.cafe/default.pdf --2021-01-20 20:51:05-- https://visio.connect.cafe/default.pdf Resolving visio.connect.cafe (visio.connect.cafe)... 188.165.240.11 Connecting to visio.connect.cafe (visio.connect.cafe)|188.165.240.11|:443... connected. Unable to establish SSL connection.
Une idée?
Merci, Vincent.
Le 20/01/2021 à 22:15, Vincent a écrit :
Salut!
Avant d'abandonner l'approche, je poste ici le dernier truc bizarre dès fois que ça cause à l'un d'entre vous :
On a donc installé un serveur BigBlueButton dans un conteneur LXC... Redirection des ports, firewall é tutti quanti...
Le serveur web HTML5 est en défaut, à priori pour une histoire de certificat SSL.
Précision : c'est du Let's Encrypt géré par la machine host.
Donc, le truc bizarre : wget https://visio.connect.cafe/default.pdf
Cela fonctionne nickel de l'extérieur... vous pouvez tester, mais pas quand je la lance à partir du LXC (en root) : root@big-blue-button:~# wget https://visio.connect.cafe/default.pdf --2021-01-20 20:51:05-- https://visio.connect.cafe/default.pdf Resolving visio.connect.cafe (visio.connect.cafe)... 188.165.240.11 Connecting to visio.connect.cafe (visio.connect.cafe)|188.165.240.11|:443... connected. Unable to establish SSL connection.
Une idée?
Une précision : cela fonctionne très bien avec un wget vers un autre https... Ce n'est donc à priori pas un souci d'ouverture de ports ou d'accès au net.
Merci, Vincent.
Plusieurs pistes :
As-tu essayé avec curl ? Ton serveur est il à l'heure ? As tu testé wget avec une autre url gérée par du letsencrypt ? Que donne "openssl s_client -connect visio.connect.cafe:443" ? Ton serveur est il ancien ? (Gestion de tls1.3)
Salut!
Le 21/01/2021 à 00:01, CgX a écrit :
Plusieurs pistes :
As-tu essayé avec curl ?
Dans quel sens? Là où ça coince, c'est à partir du serveur vers lui-même en passant par l'IP publique (comme c'est du LXC, c'est derrière un NAT). J'ai déjà utilisé curl pour l'installation. Je précise, je gratte sur ce point car le serveur BBB HTML5 plante car il n'arrive pas à accéder à https://visio.connect.cafe ou plus exactement, n'arrive pas à récupérer un certificat valide. Et, de fait, Let's Encrypt ne couvre que les domaines, pas l'adresse IP.
Tests à l'instant avec curl :
root@big-blue-button:~# curl -O https://visio.connect.cafe/default.pdf % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (35) gnutls_handshake() failed: The TLS connection was non-properly terminated. root@big-blue-button:~# curl -O visio.connect.cafe/default.pdf % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 424k 100 424k 0 0 65.9M 0 --:--:-- --:--:-- --:--:-- 69.1M
Apparemment, il arrive à passer en HTTP, alors que c'est normalement interdit... ?
Ton serveur est il à l'heure ?
Oui, à l'heure UTC
As tu testé wget avec une autre url gérée par du letsencrypt ?
Oui, j'ai "wgetter" une image du blog ral-bsl.linux-azur.org avec succès...
Que donne "openssl s_client -connect visio.connect.cafe:443" ?
Précision : Let's Encrypt est géré par la machine host, pas dans le LXC qui est couvert en tant que sous-domaine.
root@big-blue-button:~# openssl s_client -connect visio.connect.cafe:443 CONNECTED(00000003) 139741104465560:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 265 bytes
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1611214364 Timeout : 300 (sec) Verify return code: 0 (ok)
Une idée?
Ton serveur est il ancien ? (Gestion de tls1.3)
La version courante de BBB impose une Ubuntu 16.04.LTS server... Donc, oui, ancien de ce point de vue, par contre à jour et dédié à BBB.
Une piste?
Merci, Vincent.
Bonjour,
serait-il possible que le /etc/hosts ait été modifié sur la VM (virtual machine) LXC? Il peut en effet s'agir d'un problème de routing. traceroute peut aider aussi. Et "ip addr show" / "ip route show", pour voir comment le trafic est routé.
Personnellement, j'ai une configuration similaire, où mes VM LXC sont derrière un proxy Nginx; SSL, aussi géré par Let's Encrypt Certbot, est géré au niveau de Nginx seulement. Le trafic entre Nginx et la VM LXC est en http seulement, ce qui simplifie beaucoup les choses.
Le jeu. 21 janv. 2021 à 08:35, Vincent dubsv@free.fr a écrit :
Salut!
Le 21/01/2021 à 00:01, CgX a écrit :
Plusieurs pistes :
As-tu essayé avec curl ?
Dans quel sens? Là où ça coince, c'est à partir du serveur vers lui-même en passant par l'IP publique (comme c'est du LXC, c'est derrière un NAT). J'ai déjà utilisé curl pour l'installation. Je précise, je gratte sur ce point car le serveur BBB HTML5 plante car il n'arrive pas à accéder à https://visio.connect.cafe ou plus exactement, n'arrive pas à récupérer un certificat valide. Et, de fait, Let's Encrypt ne couvre que les domaines, pas l'adresse IP.
Tests à l'instant avec curl :
root@big-blue-button:~# curl -O https://visio.connect.cafe/default.pdf % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (35) gnutls_handshake() failed: The TLS connection was non-properly terminated.
root@big-blue-button:~# curl -O visio.connect.cafe/default.pdf % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 424k 100 424k 0 0 65.9M 0 --:--:-- --:--:-- --:--:-- 69.1M
Apparemment, il arrive à passer en HTTP, alors que c'est normalement interdit... ?
Ton serveur est il à l'heure ?
Oui, à l'heure UTC
As tu testé wget avec une autre url gérée par du letsencrypt ?
Oui, j'ai "wgetter" une image du blog ral-bsl.linux-azur.org avec succès...
Que donne "openssl s_client -connect visio.connect.cafe:443" ?
Précision : Let's Encrypt est géré par la machine host, pas dans le LXC qui est couvert en tant que sous-domaine.
root@big-blue-button:~# openssl s_client -connect visio.connect.cafe:443 CONNECTED(00000003) 139741104465560:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 265 bytes
New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1611214364 Timeout : 300 (sec) Verify return code: 0 (ok)
Une idée?
Ton serveur est il ancien ? (Gestion de tls1.3)
La version courante de BBB impose une Ubuntu 16.04.LTS server... Donc, oui, ancien de ce point de vue, par contre à jour et dédié à BBB.
Une piste?
Merci, Vincent. _______________________________________________ Linux06 mailing list Linux06@lists.linux-azur.org https://lists.linux-azur.org/mailman/listinfo/linux06 Attention, les archives sont publiques
Le 21/01/2021 à 08:35, Vincent a écrit :
Salut!
Le 21/01/2021 à 00:01, CgX a écrit :
Plusieurs pistes :
[[--couic--]]
root@big-blue-button:~# openssl s_client -connect visio.connect.cafe:443 CONNECTED(00000003) 139741104465560:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 265 bytes
[[--couic--]]
J'ai cherché un peu cette erreur dans les ninternets :
https://serverfault.com/questions/389197/ssl-routinesssl23-writessl-handshak...
C'est peut être lié a ta version de openSSL 1.0.1 qui serait buggée ?
Le 20/01/2021 à 22:15, Vincent a écrit :
Salut!
Avant d'abandonner l'approche, je poste ici le dernier truc bizarre dès fois que ça cause à l'un d'entre vous :
On a donc installé un serveur BigBlueButton dans un conteneur LXC... Redirection des ports, firewall é tutti quanti...
Le serveur web HTML5 est en défaut, à priori pour une histoire de certificat SSL.
Précision : c'est du Let's Encrypt géré par la machine host.
Donc, le truc bizarre : wget https://visio.connect.cafe/default.pdf
Cela fonctionne nickel de l'extérieur... vous pouvez tester, mais pas quand je la lance à partir du LXC (en root) : root@big-blue-button:~# wget https://visio.connect.cafe/default.pdf --2021-01-20 20:51:05-- https://visio.connect.cafe/default.pdf Resolving visio.connect.cafe (visio.connect.cafe)... 188.165.240.11 Connecting to visio.connect.cafe (visio.connect.cafe)|188.165.240.11|:443... connected. Unable to establish SSL connection.
Une idée?
Une précision : cela fonctionne très bien avec un wget vers un autre https... Ce n'est donc à priori pas un souci d'ouverture de ports ou d'accès au net.
Merci, Vincent.
Bonsoir Vincent,
Si je comprends bien, c'est un échec d'accès au serveur qui fournit le certificat SSL, or celui-ci est clairement hébergé quelque part sur le net (hors de ton serveur).
Voici quelques pistes vite faites :
1. J'ai en effet détecté la source via Firefox et j'ai bien accès à ta page BBB (avec plein de pages vides :-) ).
Emplacement : http://r3.o.lencr.org http://r3.o.lencr.org
Méthode : Online Certificate Status Protocol (OCSP)
Nom : Cloudflare “Nimbus2021”
Algo de signature : SHA-256 ECDSA
2. Si tu fais un ping r3.o.lencr.org, as-tu un résultat ?
3. Peut-être une restriction au niveau des IP tables ?
4. SeLinux est-il activé ?
5. Le compte root peut avoir certaines restrictions pour éviter certains risques d'intrusion au sein même du système. Ainsi root ne peut pas faire certaines choses qu'un utilisateur peut faire.
As-tu essayé de créer un compte utilisateur classique pour re-tester ?
Gnument Vôtre,
Re...
Le 21/01/2021 à 00:29, sylvio DESJARDINS a écrit :
Bonsoir Vincent, Si je comprends bien, c'est un échec d'accès au serveur qui fournit le certificat SSL, or celui-ci est clairement hébergé quelque part sur le net (hors de ton serveur).
C'est du Let's Encrypt géré par la machine host, le serveur étant dans une LXC et couverte par le certificat en tant que sous-domaine.
Voici quelques pistes vite faites :
- J'ai en effet détecté la source via Firefox et j'ai bien accès à ta
page BBB (avec plein de pages vides :-) ).
Emplacement : http://r3.o.lencr.org <http://r3.o.lencr.org> Méthode : Online Certificate Status Protocol (OCSP) Nom : Cloudflare “Nimbus2021” Algo de signature : SHA-256 ECDSA
Côté SSL, vu du net, tout va bien, il est même noté A ici:
https://www.ssllabs.com/ssltest/analyze.html?d=visio.connect.cafe&hideRe...
- Si tu fais un ping r3.o.lencr.org, as-tu un résultat ?
Oui, j'ai un accès au net complet :
root@big-blue-button:~# ping r3.o.lencr.org PING a1887.dscq.akamai.net (104.123.50.33) 56(84) bytes of data. 64 bytes from a104-123-50-33.deploy.static.akamaitechnologies.com (104.123.50.33): icmp_seq=1 ttl=54 time=4.92 ms 64 bytes from a104-123-50-33.deploy.static.akamaitechnologies.com (104.123.50.33): icmp_seq=2 ttl=54 time=6.20 ms 64 bytes from a104-123-50-33.deploy.static.akamaitechnologies.com (104.123.50.33): icmp_seq=3 ttl=54 time=6.40 ms 64 bytes from a104-123-50-33.deploy.static.akamaitechnologies.com (104.123.50.33): icmp_seq=4 ttl=54 time=6.32 ms ^C --- a1887.dscq.akamai.net ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 4.921/5.962/6.405/0.612 ms
- Peut-être une restriction au niveau des IP tables ?
Ben... dans la mesure où cela ne coince que pour l'adresse publique du serveur à partir de lui-même, donc de son adresse privée... je vois mal pourquoi ce serait une question d'IP tables? Peux-tu développer?
- SeLinux est-il activé ?
A priori, non, il y a bien un répertoire /etc/selinux, mais les commandes 'sestatus' et 'getenforce' ne sont pas reconnues. En même temps, ce n'est pas installé par défaut sur Ubuntu 16.04.
- Le compte root peut avoir certaines restrictions pour éviter certains
risques d'intrusion au sein même du système. Ainsi root ne peut pas faire certaines choses qu'un utilisateur peut faire.
As-tu essayé de créer un compte utilisateur classique pour re-tester ?
J'ai squatté avec un 'su -l' un utilisateur présent, et le résultat est le même. J'en profite pour corriger ce que j'ai écrit sur 'curl' : le port 80 (HTTP) est bien accessible de la machine, même en wget.
Vincent.
Bonjour Vincent,
Mes connaissances sont certainement beaucoup moins avancées que celles de CGX sur ce sujet, mais j'essaye d' réfléchir avec vous. En même temps, ça me fait une petite récré ... ;-)
Le 21/01/2021 à 09:07, Vincent a écrit :
Re...
Le 21/01/2021 à 00:29, sylvio DESJARDINS a écrit :
Bonsoir Vincent, ...couic...
C'est du Let's Encrypt géré par la machine host, le serveur étant dans une LXC et couverte par le certificat en tant que sous-domaine.
Effectivement.
Voici quelques pistes vite faites : ...couic...
Côté SSL, vu du net, tout va bien, il est même noté A ici:
Ce n'était qu'un retour de consultation de ma part. Je ne le remettais pas en cause du moment que ça fonctionne de l'extérieur.
- Si tu fais un ping r3.o.lencr.org, as-tu un résultat ?
Oui, j'ai un accès au net complet :
Parfait.
...couic...
- Peut-être une restriction au niveau des IP tables ?
Ben... dans la mesure où cela ne coince que pour l'adresse publique du serveur à partir de lui-même, donc de son adresse privée... je vois mal pourquoi ce serait une question d'IP tables? Peux-tu développer?
Je pensais à l'accès au serveur de l'autorité publique sur lequel le certificat SSL est déposé. A moins que ce soit ton serveur qui fournisse lui-même le certificat et les informations que j'ai pu consulter via l'autorité.
J'avoue ne pas beaucoup m'y connaître sur ce terrain. J'explore...
- SeLinux est-il activé ?
A priori, non, il y a bien un répertoire /etc/selinux, mais les commandes 'sestatus' et 'getenforce' ne sont pas reconnues. En même temps, ce n'est pas installé par défaut sur Ubuntu 16.04.
Reflexe de fédoriste... ;-)
- Le compte root peut avoir certaines restrictions pour éviter certains
risques d'intrusion au sein même du système. Ainsi root ne peut pas faire certaines choses qu'un utilisateur peut faire.
As-tu essayé de créer un compte utilisateur classique pour re-tester ?
J'ai squatté avec un 'su -l' un utilisateur présent, et le résultat est le même. J'en profite pour corriger ce que j'ai écrit sur 'curl' : le port 80 (HTTP) est bien accessible de la machine, même en wget.
Il y a quelque chose qui parle dans tes retours :
error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177
As-tu un log plus détaillé dans /var/log ?
Vincent.
Gnument Vôtre,
t'es t'il possible de faire un tcdump du traffic client et de le fournir.
dans une console du guest LXC :
tcpdump port 443 -w bbb443client.pcap -s0
et le wget dans une autre
Puis ( Ctrl +C ) dans la console tcpdump pour arrêter la capture.
On devrait vite voir de quoi il en retourne dans le fichier bbb443client .pcap.
Salut!
Le 21/01/2021 à 21:09, philippe lhardy a écrit :
t'es t'il possible de faire un tcdump du traffic client et de le fournir.
dans une console du guest LXC :
tcpdump port 443 -w bbb443client.pcap -s0
et le wget dans une autre
Puis ( Ctrl +C ) dans la console tcpdump pour arrêter la capture.
On devrait vite voir de quoi il en retourne dans le fichier bbb443client .pcap.
En fait, suite à 3 sources différentes me conseillant de ne pas utiliser de SSL entre la LXC et la machine Host, j'ai tout rebasculé en HTTP sur port 80... Et effectivement, je n'ai plus eu ce message d'erreur... Oui, mais, j'ai pété le service html5.
Et du port 443 et du SSL est revenu par endroit... pas réussi à trouver où.
Et j'ai insisté, mais en fait, avec BBB, il y a trop d'interactions entre les différents composants, du coup une modification de l'un impacte un autre, et cela devient vite ingérable. J'ai tenté une nouvelle installation, mais il a retrouvé - partiellement - des paramètres de la version précédente...
Je suppose qu'à ce stade, il faut repartir d'une machine vierge, et du coup, Vincent (un autre) va tenter une installation docker, qui semble conçue pour un serveur derrière un NAT...
Qui vivra verra!
Merci pour les réponses! Vincent / j'ai un autre truc sur le feu...
-
CgX -
CgX (Christophe)
-
Denis Arnaud -
philippe lhardy -
sylvio DESJARDINS -
Vincent