20 Jan
2021
20 Jan
'21
10:15 p.m.
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.
20 Jan
20 Jan
11:40 p.m.
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.
21 Jan
21 Jan
12:01 a.m.
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)
8:35 a.m.
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.
9:08 a.m.
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(a)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(a)lists.linux-azur.org
https://lists.linux-azur.org/mailman/listinfo/linux06
Attention, les archives sont publiques
9:17 a.m.
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-handsha…
C'est peut être lié a ta version de openSSL 1.0.1 qui serait buggée ?
--
CgX (Christophe)
12:29 a.m.
Le 20/01/2021 à 22:15, Vincent 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).
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,
--
Sylvio DESJARDINS
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.
9:07 a.m.
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 :
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
Côté SSL, vu du net, tout va bien, il est
même noté A ici:
2. 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
3. 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?
4. 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.
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 ?
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.
3:38 p.m.
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 :
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.
Parfait.
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...
Reflexe de
fédoriste... ;-)
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 ?
Re...
Le 21/01/2021 à 00:29, sylvio DESJARDINS a écrit :
Effectivement.
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. Voici quelques
pistes vite faites :
...couic...
Côté SSL, vu du net, tout va bien, il est même noté A ici: 2. Si tu fais
un ping r3.o.lencr.org, as-tu un résultat ?
Oui, j'ai un accès au net complet :
...couic...
3. 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? 4. 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. 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 ?
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.
Gnument Vôtre,
--
Sylvio DESJARDINS
9:09 p.m.
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.
22 Jan
22 Jan
12:12 a.m.
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...
1197
days inactive
1198
days old
11 comments
6 participants
participants (6)
-
CgX -
CgX (Christophe)
-
Denis Arnaud -
philippe lhardy -
sylvio DESJARDINS -
Vincent