Yapay zekâ tarafından English dilinden çevrildi ·
Öğrenci burada, ilk yazım. Bir laboratuvar projesi için toprak nem kaydedicisi yapıyorum: Pi 3, ADS1115 üzerinden kapasitif sensör, paho-mqtt 1.6, 8883 portundan Hermetry’ye gönderim. Ev Wi-Fi’ımda her şey çalışıyor. Laboratuvarda ise her seferinde başarısız oluyor:
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: certificate is not yet valid (_ssl.c:1006)Laboratuvar ağı birçok şeyi engelliyor, bu yüzden broker’ın host adı yerine IP adresine bağlanmayı da denedim (evde çözümleyip sabit kodladım) ve bunun üzerine hata bir host adı uyuşmazlığına dönüşüyor. certifi’yi yeniden kurdum ve client.tls_set()‘i ca_certs yolu ile ve yolsuz çağırdım. Hiçbiri işe yaramadı. Laboratuvar güvenlik duvarı TLS’i bozuyor olabilir mi?
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?
Yapay zekâ tarafından English dilinden çevrildi ·
Bu ağda 8883 portu gerçekten açık mı? Bazı yerler yalnızca dışarı çıkışta 80 ve 443’e izin veriyor.
Is 8883 even open on that network? Some places only allow 80 and 443 out.
Yapay zekâ tarafından English dilinden çevrildi ·
Açık olmalı, el sıkışma başlıyor, sadece sertifikada hata veriyor.
It must be open, the handshake starts, it just fails on the certificate.
Yapay zekâ tarafından English dilinden çevrildi ·
Belki broker için bir istemci sertifikasına ihtiyacınız vardır? Hat PC’lerimizde bir tane yüklemek zorunda kalmıştık.
Maybe you need a client certificate for the broker? We had to load one on our line PCs.
Yapay zekâ tarafından English dilinden çevrildi ·
Laboratuvardayken Pi üzerinde date ne gösteriyor?
What does date say on the Pi when you’re in the lab?
Yapay zekâ tarafından English dilinden çevrildi ·
…geçen yılın Mart ayını gösteriyor. Evde ise doğru.
…it says March of last year. At home it’s right.
Yapay zekâ tarafından English dilinden çevrildi ·
Demek ki sorun bu. Pi 3’te gerçek bir gerçek zamanlı saat (RTC) yok. Açılışta, son düzgün kapatmada kaydettiği zamanı geri yüklüyor (fake-hwclock) ve sonra NTP’yi bekliyor. Laboratuvar ağınız NTP’yi (UDP 123) engelliyor, bu yüzden saat geçmişte kalıyor ve TLS kütüphanesi açısından sunucu sertifikası henüz geçerli değil. Kilitli güvenlik duvarlarının arkasındaki sahadaki Pi’lerin yarısında bunu gördüm.Çözümler, birini seçin:
# 1. BT biriminden dahili NTP sunucusunu isteyin ve kullanın
sudo nano /etc/systemd/timesyncd.conf
[Time]
NTP=ntp.your-lab.example
sudo systemctl restart systemd-timesyncd
timedatectl # "System clock synchronized: yes"
# 2. yalnızca 443 açıksa: HTTPS başlıklarından senkronize edin
sudo apt install htpdate
sudo htpdate -s https://www.example.orgSabit kodlanmış IP’yi kaldırın. Broker SNI gerektirir, bu yüzden ana bilgisayar adıyla bağlanın; sertifika zaten bu ada göre kontrol edilir, uyuşmazlığın nedeni de budur. Sistem CA paketiyle düz client.tls_set() kullanmak uygundur; Tyler, belirteç ile girişlerde istemci sertifikası gerekmez, sunucu bir tane ister ama zorunlu tutmaz.Ayrıca betiğin bağlanmadan önce senkronize bir saati beklemesini sağlayın, aksi halde laboratuvarda bir yeniden başlatma sorunu yeniden oluşturur. timedatectl show -p NTPSynchronized üzerinde kısa bir döngü işe yarar. Ayrıntılar için MQTT sayfasının TLS bölümüne bakın.
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.
Yapay zekâ tarafından English dilinden çevrildi ·
BT bana dahili NTP sunucusunu verdi, saat doğru, ana bilgisayar adı geri eklendi, ilk denemede bağlandı. systemd birimine de senkronizasyon bekleme döngüsü ekledim. Sorunun tarih olduğuna inanamıyorum.
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.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.