CA Zertifikate für ublox-Modem

HTTPS ist nur SSL + HTTP, d.h. bei den Zertifikaten ändert sich 
praktisch nix für OP.

Man kann also nach Anleitung vorgehen - allerdings nach der Anleitung 
bei eigener CA. HTTPS wird gerne mit fremder CA (wie Lets Encrypt) 
gefahren, die die Identität des Servers unabhängig feststellen soll und 
deren Root Zertifikat im Browser vorinstalliert ist.

Das Szenario von OP ist eher mit VPN vergleichbar, wo es ebenfalls 
Anleitungen zum Aufsetzen von CA und Zertifikaten - z.B. mit easy-RSA - 
gibt.

Falls Python Probleme macht: Stunnel kann auf bestehende TCP/IP 
Infrastuktur SSL draufsatteln.

Diverse Schlüssel und Zertifikate wurden jetzt erzeugt (OpenSSl...).
Leider möchte das Modem das Zertifikat aber nicht übernehmen.

Jim M. schrieb:
> Falls Python Probleme macht: Stunnel kann auf bestehende TCP/IP
> Infrastuktur SSL draufsatteln.

Eigentlich wollte ich dazu die ssl-Lib verwenden. Aber die zickt rum.

Nach dem Beispiel
https://gist.github.com/dergachev/7028596
bzw. dessen Quelle
https://piware.de/2011/01/creating-an-https-server-in-python/

wollte ich auf dem Raspberry Pi einen HTTPS-Server ausprobieren.
Fehlermeldung:
Traceback (most recent call last):
  File "/home/pi/simple-https-server.py", line 5, in <module>
    httpd.socket = ssl.wrap_socket(httpd.socket, 
certfile='./server.pem', server_side=True)
  File "/usr/local/opt/python-3.9.5/lib/python3.9/ssl.py", line 1402, in 
wrap_socket
    context.load_cert_chain(certfile, keyfile)
ssl.SSLError: [SSL] PEM lib (_ssl.c:4044)

Er erkennt also die Zertifikatsdatei nicht richtig?!
Edit:
Der Testserver unter python läuft soweit.
(Man sollte auch mal ganz unten bei den Atworten gucken...)

Hmmm schrieb:
> Rahul D. schrieb:
>> Leider möchte das Modem das Zertifikat aber nicht übernehmen.
>
> Was heisst das genau?

Antwort des Modems:
+CME ERROR: USECMNG import timeout expired (no input for > 20 s)

Eigentlich sollte eine Antwort mit MD5-Checksumme kommen.
Es möchte aber lieber eine Fehlermeldung abgeben ;)

Hmmm schrieb:
> Rahul D. schrieb:
>> Der Testserver unter python läuft soweit.
>
> Zum Testen ist OpenSSL immer sehr hilfreich:
>
> openssl s_client -connect <host>:<port>
>
> Erst wenn damit alles fehlerfrei funktioniert, würde ich die
> Client-Baustelle angehen.

OK. Ich bin ziemlich neu in dem Thema drin (Meine Netzwerk-Kenntnisse 
beschränken sich auf Standardinstallationen von nginx und Apache, sowie 
php im Intranet).

Hmmm schrieb:
> Evtl. eine falsche Länge übergeben, so dass auf weitere Daten gewartet
> wird?

Jein, wenn man die Zeilenwechsel in der Datei entfernt und dann die 
richtige Stringlänge verwendet, mag das Modem das Zertifikat.

Hmmm schrieb:
> Am besten erstmal an einen PC hängen und mit einem Terminal
> experimentieren.

Sowieso.

Mal sehen, wie sich python jetzt windet...

Hmmm schrieb:
> Rahul D. schrieb:
>> Jein, wenn man die Zeilenwechsel in der Datei entfernt und dann die
>> richtige Stringlänge verwendet, mag das Modem das Zertifikat.
>
> Hast Du das Zeilenende jeweils als 2 Bytes (CR/LF, wie unter DOS/Windows
> üblich) gezählt? Beim Pasten ins Terminal wird daraus vermutlich ein
> nacktes CR, eben so, als hätte man es manuell eingetippt.

Das Zertifikat wurde durch ein Raspberry Pi erstellt und enthielt nur 
<LF> als Zeilenendezeichen.
Das habe ich es auf meinen Windows-Rechner kopiert an dem das Modem per 
USB-RS232-Wandler hängt.
Die <LF> habe ich einfach alle (manuell) entfernt, den restelichen Text 
in die Zwischenablage kopiert und konnte dann mit der richtigen Anzahl 
das Zertifikat aufs Modem kopieren.
Alles gut - das Thema wäre erledigt.

Jetzt geht es darum, python dazu zu bringen, auch mit der TSL-Geschichte 
zurecht zu kommen...

Der Test mit

openssl s_server -key key.pem -cert cert.pem -accept ...

und hTerm auf der anderen Seite (vor dem Modem) funktionierte schon mal 
:D

Moin,
mal eine Rückmeldung, falls sich jemand auch so dämlich wie ich 
anstellt:

Das root certificate  habe ich mit
AT+USECMNG=0,0,"rootCA",1432
importiert (1432 Zeichen nach dem Entfernen der Zeilenumbrüche).

Das Zeritfikat wird dann durch
AT+USECPRF=0,2,0
verwendet.

Dann noch den Socket (nachdem er mit "+USOCR=6" zur Verwendung von TCP 
erzeugt wurde) auf TSL schalten:
AT+USOSEC=0,1,0

Danach kann man die Übertragung ganz "normal" durchführen.

Die notwendigen Dateien habe ich mit
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 
<Tage>

erzeugt (<Tage> durch die gewünschte "Haltbarkeitsdauer" ersetzen).
(Quelle: 
https://stackoverflow.com/questions/10175812/how-to-generate-a-self-signed-ssl-certificate-using-openssl)

Beim Zertifikatsimport ins u-blox-Modem sollte man sich nicht an der 
Dateigröße orientieren, sondern wirklich die (lesbaren) Zeichen zählen, 
da in der Dateigröße auch die Zeilenendezeichen mit gezählt werden.
Ob die das Modem stören weiß ich nicht (nicht getestet, da Workaround 
vorhanden).

Vielen Dank an die Unterstützer!

Hi Rahul.

Nett von Dir die Lösung dann auch hier zu präsentieren.
...könnte sein, dass ich in nächster Zukunft auch vor dem Problem 
gestanden hätte.

Grüße

Die Keys und Zertifikate erfordern noch eine Passwort-Eingabe.
Das sollte durch hinzufügen von "-nodes" (für "no DES") vermutlich 
entfallen (Vermutung, da ich gerade mal wieder mit was anderem 
beschäftigt bin; hatte ich aber auch irgendwo gelesen).

Rahul D. schrieb:
> Die Keys und Zertifikate erfordern noch eine Passwort-Eingabe.
> Das sollte durch hinzufügen von "-nodes" (für "no DES") vermutlich
> entfallen (Vermutung, da ich gerade mal wieder mit was anderem
> beschäftigt bin; hatte ich aber auch irgendwo gelesen).

Ich verbessere mich mal selbst:
"openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days
<Tage> -nodes"

wodurch die Passwortabfrage entfällt. Ansonsten wie oben geschrieben 
vorgehen.

Jetzt muss ich das "nur noch" einem funktionierenden, aber unsicheren 
monty-python-script beibringen.

So, läuft :D
Die Kommunikation lief problemlos ohne Verschlüsselung.
Mit Verschlüsselung lieferte das Modem keinen URC; allerdings wurden 
Daten empfangen. Also: regelmäßig pollen ...