SVN Umzug

Begonnen von rudolfkoenig, 05 März 2023, 17:48:51

Vorheriges Thema - Nächstes Thema

Otto123

Zitat von: Otto123 am 13 März 2023, 17:22:25Um einen Einfluss auszuschließen stoppe ich mal die zweite Instanz, brauchen wir bis zum nächsten Umzug Test ja nicht.
Aus meiner Sicht haben die Zeiten seitdem gestimmt.
Ich habe im neuen Forum den Poster Feed aktiv und im alten Forum deaktiviert. Ich hoffe es läuft rund. ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

betateilchen

Zitat von: betateilchen am 17 März 2023, 15:24:18Das könnte ich natürlich tun, aber das Problem habe ich ja nicht auf dem ipad (da funktioniert svn.fhem.de problemlos) sondern auf dem RaspberryPi hier, der sein FHEM aktualisieren möchte.

Das schaue ich mir nächste Woche von zuhause an, von da habe ich Zugriff auf den Raspi.

Lustig...

Updating '.':
Error validating server certificate for 'https://svn.fhem.de:443':
 - The certificate has expired.
Certificate information:
 - Hostname: svn.fhem.de
 - Valid: from Mar  5 16:22:27 2023 GMT until Jun  3 16:22:26 2023 GMT
 - Issuer: Let's Encrypt, US
 - Fingerprint: 23:25:69:65:8F:5D:15:EB:DC:94:2C:C9:4F:00:E0:B6:0A:18:27:8B

Ich habe das Zertifikat jetzt manuell permanent akzeptiert, nun funktioniert auch das svn update wieder.
Vermutlich bis zum 03.06.2023...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Zitat- The certificate has expired.
[...]
 - Valid: from Mar  5 16:22:27 2023 GMT until Jun  3 16:22:26 2023 GMT
Bei einem Anfaenger wuerde ich jetzt fragen, ob die Datumseinstellung auf dem Client richtig ist.

erwin

Hi community, ich habe meinen Zoo von Debian/Raspian installationen mal gecheckt:
SYSTEM    uname-a  vers *release wget fhemupdate 
CL_RPI-2  4.9.35     8  jessie   cert ok
CL-RPI-3  5.10.103  10  buster   ok   na
CL-CT-1   3.4.103    8  jessie   TLS  na
MH-RPI-1  3.18.7+    7  wheezy   TLS  OK
MH-RPI-4  3.18.7+    7  wheezy   TLS  OK
MH-RPI-10 4.2.13     8  jessie   ok   SSL
MH-RPI-21 6.1.19    11  bullseye ok   ok
MH-RPI-22 5.15.76   11  bullseye ok   na

Erklärung:
Spalte wget: Ergebnis von "wget https://svn.fhem.de"
 -cert -> ceritifikat expired
 -TLS  -> TLS error
Spalte fhemupdate: Ergebnis v. "fhem update check"
 -na  -> FHEM nicht installiert....
 -SSL  -> SSL error
conclusio: ich hab ein jessie system, wo zwar das wget fehlschlägt, fhem update aber funktioniert...
... ein zweites jessie system, wo das wget funktioniert, aber fhem update fehlschlägt...
... und noch zwei wheezy systeme, wo as wget fehlschlägt, fhem update aber funktioniert...

Es liegt also nicht unbedingt an der release ()wheezy,jessie,...), sondern vermutlich an openssl,... versionen, die mit "normalen" mitteln nicht mehr upgedatet werden können.

..und bevor jemand auf die Idee kommt, das ich upgraden soll: ich betreibe diese Versionen ganz bewusst, um meine Module auf backward compatibility zu checken. Das FHEM-update ist mir dabei auch nicht wirklich wichtig, da nutze ich andere Möglichkeiten.
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Otto123

Auf meinem wheezy System liefert
openssl s_client -connect svn.fhem.de:443|grep 'Certificate chain' -A13
Zitatdepth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
Certificate chain
 0 s:/CN=commandref.fhem.de
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
auf einem aktuellen ubuntu
Zitatdepth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = svn.fhem.de
verify return:1
Certificate chain
 0 s:CN = svn.fhem.de
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar  5 16:22:27 2023 GMT; NotAfter: Jun  3 16:22:26 2023 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT

Wieso liefert die gleiche Adresse unterschiedliche Zertifikate aus?
Auf der Adresse wiki.fhem.de (noch der alte Server) ist das ähnlich. Ist das ein Hinweis oder ist mein Test Unsinn?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig

Das sind keine unterschiedlichen Zertifikate, sondern die Zertifikats-Kette.
Lets-Encrypt hats fuer fhem.de erstellt, und Lets-Encrypt darf das, weil "Digital Signature Trust" es denen erlaubt hat.

Was mir noch nicht ganz klar ist, worauf sich "certificate expired" bezieht.
Ich tippe auf den Linux Zertifikats-Store in /etc/ca-certificates, da muss die von "Digital Signature Trust" hinterlegt sein, sonst koennte ja jeder kommen.

rudolfkoenig

@erwin: was muss man machen, damit wheezy bzw. jessie ein fhem-update durchfuehren kann?

Otto123

#52
an fhem update kann man "das Problem" mMn nicht festmachen, das funktioniert auf dem wheezy. Bei mir und bei Erwin ja auch  :-[

ich habe oben nur die Certifate Chain raus gefiltert um die Namen zu zeigen. Das Zertifikate ist mMn nach ein anderes:
wheezy
AjZISlT+Q3tOZ4oiJAiVCSKhaxp7TJkZAXrTVZGX
-----END CERTIFICATE-----
subject=/CN=commandref.fhem.de
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
---
SSL handshake has read 4593 bytes and written 484 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
ubuntu
/Sd1Ll9o/njp0WMN/fo/yp8=
-----END CERTIFICATE-----
subject=CN = svn.fhem.de
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4569 bytes and written 393 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

erwin

HI Rudolf,
ZitatIch tippe auf den Linux Zertifikats-Store in /etc/ca-certificates, ...
Ja, das ist auch meine Vermutung und dort ist das certifikat DST Root CA X3 expired.
Das Problem ist, das man auf dem betreffenden system kein funktionales apt-get... mehr hat, um die crt's upzudaten...
Zu deiner 2ten Frage: keine Idee... sonst hätte ich das schon gefixt, Vermutung: entweder SSL-version oder /etc/ca-certificates/.. updaten, aber wie?
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Otto123

#54
Man kann das eigentlich so machen?
update-ca-certificates (-f)Aber das behebt nicht das TLS Problem. Und es behebt nicht das Problem, dass er eigentlich das ISRG Root X1 und nicht das DST Root CA X3 nehmen sollte.

Aber ich verstehe das Ganze nicht wirklich, ich will nur Infos liefern.

Edit:
gerade was schräges probiert - bei mir ein Link /etc/ssl/certs/DST_Root_CA_X3.pem -> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt , den mal gelöscht und es sieht aus als ob TLS geht :)
sudo rm /etc/ssl/certs/DST_Root_CA_X3.pemIn neueren Systemen ist der nämlich nicht mehr vorhanden.
Vorher:
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 57D48A51C53F04CD742A369EEE7BC797436C9CF302F9046208F157CD925920FA
    Session-ID-ctx:
    Master-Key: 6449E43AD1081A5534A522526CCD02A71EB7E3D88E74787A655E1FCEA68D0AF33A8FBE48FBA2A3E4877FC50827B2DD9D
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1680687523
    Timeout   : 300 (sec)
    Verify return code: 10 (certificate has expired)
---
nachher
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: FD38F212BBC8652F9A66F6BA976CAE08C9783F68102043A5012CF998DE163784
    Session-ID-ctx:
    Master-Key: 932D91B7B31111C9113FE31BC09AD139B2F07C85954000A4DD499036DA0DD2383E8C3BE468DA26A677569BB3CDD126B3
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1680689520
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Wernieman

Hat LetsEncrypt nicht mal eine Zeitlang 2 verschieden Codierte Zertifikate ausgeliefert? Aus Kompartibilitätsgründen? Und genau in dem Zusammenhang ist mir irgendwo geläufig, das Jessy damit ein Problem hat ... habe nur aktuell keine Zeit es zu regergieren (Sorry) ..

Man kann übrigens manuell Stammzertifikate im System installieren/Löschen.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Otto123

Hier gibt es noch einen Fall der in die Richtung geht: https://forum.fhem.de/index.php?topic=133026
Es liegt bei ihm offenbar nicht am System, sondern an FHEM, welches bis in den Februar 2023 aktualisiert werden konnte.
Wenn er dieses FHEM auf einem aktuellen Ubuntu restored kann er auch nicht mehr updaten.

Nach was kann man da suchen? ich stochere in diesem Thread nur rum ;)

Sieht aber so aus als ob bei ihm in einem FHEM Modul etwas nicht stimmt?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

erwin

#57
Vermutung: global sslArgs...
edit:
richtig ist: attr global SSLVersion
... und die Vermutung ist, dass da SSLv23 drin steht, was offensichtlich nicht mehr funktioniert...
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Otto123

Zitat von: erwin am 08 April 2023, 02:47:25richtig ist: attr global SSLVersion
... und die Vermutung ist, dass da SSLv23 drin steht, was offensichtlich nicht mehr funktioniert...

Was aber mMn laut dieser Schilderung nicht der Grund sein kann?
Zitat von: roadghost am 07 April 2023, 23:04:483. Ubuntu 22.04 installiert, fhem frisch installiert, fhem.cfg aus dem Ubuntu 16.04 in die 22er Installation kopiert >>> Update funktioniert
@erwin kannst Du in deinem "Zoo" mal bitte die Existenz von
ls -l /etc/ssl/certs/DST_Root_CA_X3.pemprüfen?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

erwin

...mein Zoo, die 2 jessie systeme, die sich unterschiedlich benehmen:
### jessie 4.2.13
### OpenSSL 1.0.1t  3 May 2016
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = commandref.fhem.de
verify return:1
Certificate chain
 0 s:/CN=commandref.fhem.de
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

kein /etc/ssl/certs/DST_Root_CA_X3.*
... ich hab vorige Woche eins gelöscht, und zwar aus:  /usr/share/ca-certificates/mozilla
auf diesen system funktioniert ein svn update/commit, aber KEIN fhem update

### jessie 4.9.35
### OpenSSL 1.0.1t  3 May 2016
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:0
Certificate chain
 0 s:/CN=commandref.fhem.de
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

sudo find -name DST_Root_CA_X3.*
./usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt Timestamp aus 2018!!!
./etc/ssl/certs/DST_Root_CA_X3.pem
auf diesem system FUNKTIONIERT fhem update!!!
daraus werde ich nicht schlau!

auf einem bullseye system:
sudo find -name DST_Root_CA_X3.*
./usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt allerdings mit einem Timestamp Jan 19 2021
./etc/ssl/certs/DST_Root_CA_X3.pem

l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...