Traducido del English por IA ·
Soy estudiante, primera publicación. Estoy haciendo un registrador de humedad del suelo para un proyecto de laboratorio: Pi 3, sensor capacitivo mediante un ADS1115, paho-mqtt 1.6, enviando a Hermetry por el 8883. En mi Wi-Fi de casa todo funciona. En el laboratorio falla siempre:
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: certificate is not yet valid (_ssl.c:1006)La red del laboratorio bloquea muchas cosas, así que también probé a conectarme a la IP del broker en lugar del nombre de host (la resolví en casa y la puse fija), y entonces el error cambia a una falta de coincidencia del nombre de host. Reinstalé certifi y llamé a client.tls_set() con y sin la ruta de ca_certs. Nada ayuda. ¿Es el cortafuegos del laboratorio el que está interfiriendo con TLS?
Student here, first post. I’m doing a soil moisture logger for a lab project: Pi 3, capacitive sensor via an ADS1115, paho-mqtt 1.6, sending to Hermetry on 8883. On my home Wi-Fi everything works. In the lab it fails every time:
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: certificate is not yet valid (_ssl.c:1006)The lab network blocks a lot of things, so I also tried connecting to the broker’s IP instead of the host name (I resolved it at home and hardcoded it) and then the error changes to a hostname mismatch. I’ve reinstalled certifi and called client.tls_set() with and without the ca_certs path. Nothing helps. Is it the lab firewall messing with TLS?
Traducido del English por IA ·
¿Está siquiera abierto el 8883 en esa red? En algunos lugares solo permiten salir por el 80 y el 443.
Is 8883 even open on that network? Some places only allow 80 and 443 out.
Traducido del English por IA ·
Debe estar abierto, el handshake comienza, simplemente falla en el certificado.
It must be open, the handshake starts, it just fails on the certificate.
Traducido del English por IA ·
Quizás necesite un certificado de cliente para el broker. Tuvimos que cargar uno en los PC de nuestra línea.
Maybe you need a client certificate for the broker? We had to load one on our line PCs.
Traducido del English por IA ·
¿Qué muestra date en la Pi cuando estás en el laboratorio?
What does date say on the Pi when you’re in the lab?
Traducido del English por IA ·
…indica marzo del año pasado. En casa está bien.
…it says March of last year. At home it’s right.
Traducido del English por IA ·
Pues eso es. Una Pi 3 no tiene reloj en tiempo real. Al arrancar restaura la hora que guardó en el último apagado limpio (fake-hwclock) y luego espera a NTP. Tu red de laboratorio bloquea NTP (UDP 123), así que el reloj se queda en el pasado y, para la biblioteca TLS, el certificado del servidor aún no es válido. Lo he visto en la mitad de las Pi de campo que he puesto en marcha tras cortafuegos muy restrictivos.Soluciones, elige una:
# 1. pide a TI el servidor NTP interno y úsalo
sudo nano /etc/systemd/timesyncd.conf
[Time]
NTP=ntp.your-lab.example
sudo systemctl restart systemd-timesyncd
timedatectl # "System clock synchronized: yes"
# 2. si solo está abierto el 443: sincroniza con las cabeceras HTTPS
sudo apt install htpdate
sudo htpdate -s https://www.example.orgQuita la IP fija. El broker necesita SNI, así que conéctate por nombre de host; el certificado se comprueba con ese nombre de todos modos, por eso obtuviste el error de discrepancia. Un client.tls_set() sencillo con el paquete de CA del sistema está bien; Tyler, no se necesita certificado de cliente para los inicios de sesión con token, el servidor lo pide pero no lo exige.Además, haz que el script espere a un reloj sincronizado antes de conectarse; si no, un reinicio en el laboratorio volverá a romperlo. Un bucle sencillo sobre timedatectl show -p NTPSynchronized funciona. Consulta la sección TLS de MQTT.
That’s it then. A Pi 3 has no real time clock. At boot it restores the time it saved at the last clean shutdown (fake-hwclock) and then waits for NTP. Your lab network blocks NTP (UDP 123), so the clock stays in the past, and to the TLS library the server certificate isn’t valid yet. Seen this on half the field Pis I’ve commissioned behind locked-down firewalls.
Fixes, pick one:
# 1. ask IT for the internal NTP server and use it
sudo nano /etc/systemd/timesyncd.conf
[Time]
NTP=ntp.your-lab.example
sudo systemctl restart systemd-timesyncd
timedatectl # "System clock synchronized: yes"
# 2. if only 443 is open: sync from HTTPS headers
sudo apt install htpdate
sudo htpdate -s https://www.example.orgUndo the hardcoded IP. The broker needs SNI, so connect by host name, and the certificate is checked against that name anyway, which is why you got the mismatch. Plain client.tls_set() with the system CA bundle is fine; Tyler, no client certificate is needed for token logins, the server asks for one but doesn’t require it.
Also make the script wait for a synced clock before connecting, otherwise a reboot in the lab breaks it again. A quick loop on timedatectl show -p NTPSynchronized works. See the TLS section of MQTT.
Traducido del English por IA ·
TI me dio el servidor NTP interno, el reloj está bien, volví a poner el nombre de host, conecté al primer intento. También añadí el bucle de espera de sincronización a la unidad de systemd. No me puedo creer que fuera la fecha.
IT gave me the internal NTP server, clock is right, host name back in, connected on the first try. Added the wait-for-sync loop to the systemd unit too. Can’t believe it was the date.
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.