8
Linux Tools verhalten sich in Powershell anders
Hallo zusammen,
nachdem es heute auf Arbeit sehr ruhig ist, habe ich Zeit ein paar Spielereien nach zu gehen.
Ich beschäftige mich zur Zeit mit TLSA Einträge. Und zwar geht es um die Erzeugung des Hashwerts auf Grund des SSL-Zertifikats bzw. dessen SubjectPublicKeyInfo.
Unter Linux erstelle ich den Wert mit folgenden Befehl:
Ausgabe:
Eingesetzte Programmversionen
OpenSSL: 1.1.1f
xxd: V1.10
Nun habe ich die Tools openssl sowie xxd auf Windows Server 2019 und Windows 10 portiert.
Am Befehl hat sich im Wesentlichen nichts geändert:
Ausgabe:
Eingesetzte Programmversionen
OpenSSL: 1.1.1i
xxd: V1.10
Ausgangslage
Kann jemand beschriebene Verhalten nachstellen?
Kann mir jemand sagen, weshalb und warum unterschiedliche Hashes generiert werden?
Grüße,
Dani
nachdem es heute auf Arbeit sehr ruhig ist, habe ich Zeit ein paar Spielereien nach zu gehen.
Ich beschäftige mich zur Zeit mit TLSA Einträge. Und zwar geht es um die Erzeugung des Hashwerts auf Grund des SSL-Zertifikats bzw. dessen SubjectPublicKeyInfo.
Unter Linux erstelle ich den Wert mit folgenden Befehl:
openssl x509 -in kernel.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | xxd -p -u -c 32 Ausgabe:
BAE26A3F9BAD72F7325C37891581505C509B268C0BBD13E3E67CA26CD303BA0CEingesetzte Programmversionen
OpenSSL: 1.1.1f
xxd: V1.10
Nun habe ich die Tools openssl sowie xxd auf Windows Server 2019 und Windows 10 portiert.
Am Befehl hat sich im Wesentlichen nichts geändert:
openssl.exe x509 -in kernel.crt -pubkey -noout | openssl.exe pkey -pubin -outform der | openssl.exe dgst -sha256 -binary | xxd.exe -p -u -c 32 Ausgabe:
634F619492800FF360DFB6F9AA7D66E9EEBDBE97FE19F2D7F389480352A6CC820D0AEingesetzte Programmversionen
OpenSSL: 1.1.1i
xxd: V1.10
Ausgangslage
- In beiden Fällen wird das gleiche Zertifikat im BASE64 X.509 Format genutzt.
- Der Hash unter Linux ist der Richtige. Das habe ich mit Hilfe von Generate DANE TLSA Record gegen geprüft.
- Das Zertifikat "kernel.crt habe ich per SFTP vom Linux Server auf den Windows Server kopiert. Damit möchte ich Copy&Paste Fehler ausschließen.
Kann jemand beschriebene Verhalten nachstellen?
Kann mir jemand sagen, weshalb und warum unterschiedliche Hashes generiert werden?
Grüße,
Dani
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Kommentar vom Moderator Frank am Oct 04, 2021 um 06:23:23 Uhr
Zum Erfahrungsbericht hochgestuft
Content-Key: 1339306678
Url: https://administrator.de/contentid/1339306678
Printed on: April 23, 2024 at 08:04 o'clock
8 Comments
Latest comment
Das du den "dgst" Parameter ausgelassen hast ist gewollt ?
Moin @aqui,
Grüße,
Dani
Das du den "dgst" Parameter ausgelassen hast ist gewollt ?
Danke für den Hinweis. In meinen unzähligen Tests habe ich u.a. mit den Parametern gespielt. Die Ausgabe ist mit und ohne Parameter die Selbe. Ich habe es zur Sicherheit nochmals geprüft. Grüße,
Dani
Hallo,
irgendwo in deinen Pipes muss sich etwas ändern. Zum debuggen würde ich hinten beginnend, einen um den anderen Befehl weglassen und die Ausgabe in ein file schreiben.
Ansonsten würden mir spontan noch die üblichen Verdächtigen, nämlich die Zeilenumbrüche einfallen.
Grüße
lcer
irgendwo in deinen Pipes muss sich etwas ändern. Zum debuggen würde ich hinten beginnend, einen um den anderen Befehl weglassen und die Ausgabe in ein file schreiben.
Ansonsten würden mir spontan noch die üblichen Verdächtigen, nämlich die Zeilenumbrüche einfallen.
Grüße
lcer
1
Nabend,
was zunächst mal auffällt, wenn man sich die HEX-Hashes mal mit festem Zeichnenbstand direkt untereinander schreibt:
-> Der Hash unter Windows ist 2 Oktette länger.
Das würde für @icer00 These sprechen, dass irgendetwas da falsche Ergebnisse liefert. Ich hätte konkreter die xxd.exe unter Windows in Verdacht, eigentlich sollte die nur die in den Parametern (-c 32) angegebenen 32 "Spalten" bzw. Oktette ausgeben, es werden aber 34 Oktette ausgegeben.
Gruß
cykes
was zunächst mal auffällt, wenn man sich die HEX-Hashes mal mit festem Zeichnenbstand direkt untereinander schreibt:
BAE26A3F9BAD72F7325C37891581505C509B268C0BBD13E3E67CA26CD303BA0C
634F619492800FF360DFB6F9AA7D66E9EEBDBE97FE19F2D7F389480352A6CC820D0ADas würde für @icer00 These sprechen, dass irgendetwas da falsche Ergebnisse liefert. Ich hätte konkreter die xxd.exe unter Windows in Verdacht, eigentlich sollte die nur die in den Parametern (-c 32) angegebenen 32 "Spalten" bzw. Oktette ausgeben, es werden aber 34 Oktette ausgegeben.
Gruß
cykes
@lcer00
@cykes
Zum debuggen würde ich hinten beginnend, einen um den anderen Befehl weglassen und die Ausgabe in ein file schreiben.
Das habe ich natürlich getan. Schlussendlich liegt es unter Windows am Encoding. Ansonsten würden mir spontan noch die üblichen Verdächtigen, nämlich die Zeilenumbrüche einfallen.
Dadurch, dass ich von Anfang an Pipe kann somit nur das Zertifiktsdatei Zeilenumbrüche enthalten. Da ich diese per SFTP kopiert und bei Debugging auch schon direkt exportiert habe, schließe ich hier ein Fehler aus.@cykes
Ich hätte konkreter die xxd.exe unter Windows in Verdacht, eigentlich sollte die nur die in den Parametern (-c 32) angegebenen 32 "Spalten" bzw. Oktette ausgeben, es werden aber 34 Oktette ausgegeben.
Mein Fehler. Ich habe wohl beim Kopieren in die Frage den Zeilumbruch entfernt. In der Powershell sieht die Ausgabe ordnungsgemäß aus:634F619492800FF360DFB6F9AA7D66E9EEBDBE97FE19F2D7F389480352A6CC82
0D0A
Guten Abend zusammen,
nach einer längeren Pause, frisches Obst und einem Kaffee habe ich den Fehler gefunden.
Und zwar liegt es am Encoding unter Windows. Folgende Befehl liefert das korrekte Ergebnis:
Ausgabe:
Aus solchen Gründen potiere ich ungern etwas von Linux auf Windows. Aber manchmal ist es leider anders nicht möglich.
Herzlichen Dank an alle für die Unterstützung zu später Stunde!
Grüße,
Dani
nach einer längeren Pause, frisches Obst und einem Kaffee habe ich den Fehler gefunden.
openssl\openssl.exe x509 -in tmp.base64.cer -pubkey -noout | openssl\openssl.exe pkey -pubin -outform DER |openssl\openssl.exe enc | openssl\openssl.exe dgst -sha256 -binary | vim\xxd.exe -p -u -c 32 Ausgabe:
BAE26A3F9BAD72F7325C37891581505C509B268C0BBD13E3E67CA26CD303BA0CAus solchen Gründen potiere ich ungern etwas von Linux auf Windows. Aber manchmal ist es leider anders nicht möglich.
Herzlichen Dank an alle für die Unterstützung zu später Stunde!
Grüße,
Dani
Moin,
...es funktioniert in der Powershell nach wie vor nicht.
Ich Dackel habe ausversehen den openssl - Befehl in einer Eingabeaufforderung abgesetzt (warum auch immer dort die selbe Hintergrundfarbe genutzt wird wie in einer Powershell
). In der Eingabeaufforderung wird der richtige Hash ausgeben (wie oben geschrieben).
Parallel bin ich über folgende Beiträge zum Thema gestolpert:
Openssl result is not matching in cmd and power shell of windows
PowerShell’s Object Pipeline Corrupts Piped Binary Data
Jetzt ist die Powershell durch aus modern. Kann aber nicht mit binären Daten bei der Verwendung von Pipe umgehen?!
Gruß,
Dan
...es funktioniert in der Powershell nach wie vor nicht.
Ich Dackel habe ausversehen den openssl - Befehl in einer Eingabeaufforderung abgesetzt (warum auch immer dort die selbe Hintergrundfarbe genutzt wird wie in einer Powershell
). In der Eingabeaufforderung wird der richtige Hash ausgeben (wie oben geschrieben).Parallel bin ich über folgende Beiträge zum Thema gestolpert:
Openssl result is not matching in cmd and power shell of windows
PowerShell’s Object Pipeline Corrupts Piped Binary Data
Jetzt ist die Powershell durch aus modern. Kann aber nicht mit binären Daten bei der Verwendung von Pipe umgehen?!
Gruß,
Dan
