Discussion:
Telekom-Rechnung, Signatur pruefen mit "openssl"
(zu alt für eine Antwort)
Marcel Logen
2020-10-17 17:48:43 UTC
Permalink
Hat hier schon mal jemand erfolgreich die Signatur einer Telekom-
Rechnung mit "openssl" (aus LibreSSL oder OpenSSL) verifiziert?

Ich plage mich schon seit Tagen damit herum.

Es gibt eine Rechnungs-Datei (.pdf) und eine "Signatur"-Datei (.pkcs7).
Die PKCS7-Datei ist im Binärformat.

Der erste Versuch war ganz naiv folgender:

| t20$ openssl cms -verify -inform der -in 2020_10_rechnung_5XXXXXXXX7_sign_20201012.pkcs7 -content 2020_10_rechnung_5XXXXXXXX7_sign_20201012.pdf -CAfile eidas-und-root.pem
| Verification failure
| 16843108543232:error:0DFFF09B:asn1 encoding routines:CRYPTO_internal:too long:/usr/src/lib/libcrypto/asn1/asn1_lib.c:143:
| 16843108543232:error:0DFFF066:asn1 encoding routines:CRYPTO_internal:bad object header:/usr/src/lib/libcrypto/asn1/tasn_dec.c:1135:
| 16843108543232:error:0DFFF03A:asn1 encoding routines:CRYPTO_internal:nested asn1 error:/usr/src/lib/libcrypto/asn1/tasn_dec.c:317:Type=ECDSA_SIG
| 16843108543232:error:2EFFF09E:CMS routines:CRYPTO_internal:verification failure:/usr/src/lib/libcrypto/cms/cms_sd.c:818:
| t20$

Dann habe ich gegoogelt und das hier gefunden:

<https://stackoverflow.com/questions/59904522/asn1-encoding-routines-errors-when-verifying-ecdsa-signature-type-with-openssl>.

Das ist schon mal recht aufschlußreich.

Jetzt stellt sich die Frage, wo in der PKCS7-Datei sich die
eigentliche Signatur befindet. Dazu habe ich "openssl asn1parse"
bemüht.

Es kommen zwei Stellen in Frage, wobei die erste ausscheidet,
da es sich dabei wohl um die Signatur im Zertifikat handelt.
Also bleiben die Daten ganz am Ende der PKCS7-Datei (64 Bytes):

| t20$ hexdump -Cv 2020_10_rechnung_5XXXXXXXX7_sign_20201012.pkcs7 | tail -n 6
| 00000980 01 01 04 01 03 05 00 04 40 46 52 99 86 4a f4 bb |***@FR..J..|
^^ ab hier
| 00000990 f4 30 e1 39 b6 fd 97 e1 1f 15 45 ab fb fe 08 c2 |.0.9......E.....|
| 000009a0 b4 4b df fe e7 f7 28 aa 0b 98 da c5 eb 2e 20 74 |.K....(....... t|
| 000009b0 5d 41 fb a3 cf de fa 94 48 8f a7 4f cf 8f a5 84 |]A......H..O....|
| 000009c0 28 b9 63 c3 9a 90 92 84 90 |(.c......|
| 000009c9

Diese Daten habe ich dann gemäß der stackoverflow-Anleitung
so aufbereitet:

| t20$ hexdump -Cv signature7ende.bin
| 00000000 30 45 02 20 46 52 99 86 4a f4 bb f4 30 e1 39 b6 |0E. FR..J...0.9.|
^^ ^^ ^^ ^^
| 00000010 fd 97 e1 1f 15 45 ab fb fe 08 c2 b4 4b df fe e7 |.....E......K...|
| 00000020 f7 28 aa 0b 02 21 00 98 da c5 eb 2e 20 74 5d 41 |.(...!...... t]A|
^^ ^^ ^^
| 00000030 fb a3 cf de fa 94 48 8f a7 4f cf 8f a5 84 28 b9 |......H..O....(.|
| 00000040 63 c3 9a 90 92 84 90 |c......|
| 00000047

Die unterhakelten Bytes habe ich also hinzugefügt.

Das ergibt offenbar eine *formal* richtig aufbereitete
Signatur (für "Public Key Algorithm: id-ecPublicKey (256 Bit)"
mit "ASN1 OID: brainpoolP256r1" und "ecdsa-with-SHA256" (laut der
PKCS7-Datei und dem darin enthaltenen Zertifikat)):

| t20$ openssl asn1parse -in signature7ende.bin -inform der
| 0:d=0 hl=2 l= 69 cons: SEQUENCE
| 2:d=1 hl=2 l= 32 prim: INTEGER :465299864AF4BBF430E139B6FD97E11F1545ABFBFE08C2B44BDFFEE7F728AA0B
| 36:d=1 hl=2 l= 33 prim: INTEGER :98DAC5EB2E20745D41FBA3CFDEFA94488FA74FCF8FA58428B963C39A90928490
| t20$

So, jetzt kommt die Prüfung:

| t20$ openssl dgst -sha256 -verify pubk-aus-cert.pem -signature signature7ende.bin 2020_10_rechnung_5XXXXXXXX7_sign_20201012.pdf
| Verification Failure
| t20$

Tja.

BTW: Der SHA256-Hash der PDF-Datei stimmt wohl - er taucht auch in
der PKCS7-Datei auf.

Keine Ahnung, was ich hier fslach mache ...

Vielleicht hat hier ja jemand eine Idee. TIA :-)

Marcel
--
╭─╮ ╭─────────╮ ╭─────────╮ ╭─╮ ╭─────╮
╭──╯ │ ╰────╮ ╭─╯ ╰───╮ ╰─╯ ╰─╮ ╭──╮ ╭────╯ ╭──╯
╯ │ ╭─╮ ╭───╯ ╰─╮ ╭─╮ ╰────╮ ╭───╯ │ │ ╰─╮ ╭──╯ ╭──╮
╰───────╯ ╰──╯ ╰─╯ ╰───────╯ ╰──────╯ ╰────╯ ╰──────╯ ╰─
Stefan Claas
2020-10-17 18:25:34 UTC
Permalink
Post by Marcel Logen
Hat hier schon mal jemand erfolgreich die Signatur einer Telekom-
Rechnung mit "openssl" (aus LibreSSL oder OpenSSL) verifiziert?
Ich plage mich schon seit Tagen damit herum.
[...]
Post by Marcel Logen
Keine Ahnung, was ich hier fslach mache ...
Vielleicht hat hier ja jemand eine Idee. TIA :-)
Wird dir sicherlich nicht weiterhelfen ...

Ich vermute mal das Telekom Kunden moderne und einfache
kostenlose Werkzeuge wie Adobe Reader dafür nutzen. Es
gibt da noch ein anderes Tool (Open Source) jedoch habe
ich den Link nicht mehr.

Grüße
Stefan
Stefan Claas
2020-10-17 19:03:30 UTC
Permalink
Post by Stefan Claas
Post by Marcel Logen
Hat hier schon mal jemand erfolgreich die Signatur einer Telekom-
Rechnung mit "openssl" (aus LibreSSL oder OpenSSL) verifiziert?
Ich plage mich schon seit Tagen damit herum.
[...]
Post by Marcel Logen
Keine Ahnung, was ich hier fslach mache ...
Vielleicht hat hier ja jemand eine Idee. TIA :-)
Wird dir sicherlich nicht weiterhelfen ...
Ich vermute mal das Telekom Kunden moderne und einfache
kostenlose Werkzeuge wie Adobe Reader dafür nutzen. Es
gibt da noch ein anderes Tool (Open Source) jedoch habe
ich den Link nicht mehr.
Ich habe mal bei 'Frag Magenta' einen live chat gestartet
und der Mitarbeiterin war die Frage auch neu (wie man die
Digitale Signatur eines .pdf Dokuments prüfen kann.) und
sie verwies auf folgenden link:

<https://www.t-online.de/digital/internet/id_65642588/signatur-pruefen-pdf-reader-und-onlinepruefung.html>

Grüße
Stefan
Marcel Logen
2020-10-17 21:47:19 UTC
Permalink
Post by Stefan Claas
Ich vermute mal das Telekom Kunden moderne und einfache
kostenlose Werkzeuge wie Adobe Reader dafür nutzen. Es
Eine Websuche führte mich zu folgendem Dokument:

<https://www.telekom.de/hilfe/rechnung/rechnung-erhalten/digital-signierte-rechnung>

Dort ist (unten) zu lesen:

| Die Signatur können Sie mit entsprechender Verifikations-
| software prüfen, zum Beispiel mit dem SecSigner von
| SecCommerce unter www.seccommerce.de. Die Signaturprüfung
| mit dem SecSigner kann direkt online erfolgen. Dazu müssen
| Sie die von der Telekom mitgelieferte Datei mit der Endung
| .pkcs7 sowie das signierte Rechnungsdokument im PDF-Format
| gemäß den Anweisungen auf der Seite von SecCommerce laden.
| Nach Prüfung der Signatur wird ein Prüfbericht zur Verfü-
| gung gestellt.

Und auf der Seite von SecCommerce finde ich:
<https://seccommerce.com/secsigner-online-uebersicht/>.

Es handelt sich BTW nicht um eine in das PDF integrierte
Signatur.

Mir geht es aber um die Prüfung mit "openssl". Das sollte
IMHO prinzipiell machbar sein. (Irgendwo in der PKCS7-Datei
sollte die ECDSA-Signatur vorhanden sein.)

Marcel
--
──╮ ╭──────────╮ ╭──╮ ╭─╮
│ ╭──╮ ╭─╯ ╭─╯ │ │ ╭──╮ ╭──╮ ╭──╯ │ ╭────
│ │ ╰──╯ ╰───╯ │ ╭─╯ ╰───╯ ╰─╮ │ ╭─╯ ╭─╮ ╭────╯
╰──╯ ╰───╯ ╰─╯ ╰─────╯ ╰─╯
Stefan Claas
2020-10-17 22:19:29 UTC
Permalink
Post by Marcel Logen
Post by Stefan Claas
Ich vermute mal das Telekom Kunden moderne und einfache
kostenlose Werkzeuge wie Adobe Reader dafür nutzen. Es
<https://www.telekom.de/hilfe/rechnung/rechnung-erhalten/digital-signierte-rechnung>
| Die Signatur können Sie mit entsprechender Verifikations-
| software prüfen, zum Beispiel mit dem SecSigner von
| SecCommerce unter www.seccommerce.de. Die Signaturprüfung
| mit dem SecSigner kann direkt online erfolgen. Dazu müssen
| Sie die von der Telekom mitgelieferte Datei mit der Endung
| .pkcs7 sowie das signierte Rechnungsdokument im PDF-Format
| gemäß den Anweisungen auf der Seite von SecCommerce laden.
| Nach Prüfung der Signatur wird ein Prüfbericht zur Verfü-
| gung gestellt.
<https://seccommerce.com/secsigner-online-uebersicht/>.
Es handelt sich BTW nicht um eine in das PDF integrierte
Signatur.
Ah, ok. Ist das dann richtig zu verstehen, als ob das mit
der Signatur so wie bei S/MIME der Fall ist. Falls ja, sollte
doch ein S/MIME fähiger MUA das können, obwohl ich nicht
weiß ob selbiger beim Signieren auch (.pdf Anhang?) mit
signieren würde.
Post by Marcel Logen
Mir geht es aber um die Prüfung mit "openssl". Das sollte
IMHO prinzipiell machbar sein. (Irgendwo in der PKCS7-Datei
sollte die ECDSA-Signatur vorhanden sein.)
Ja, ist mir schon klar. Ich wollte nur darauf hinweisen das
man es sich (wenn möglich) einfach machen sollte, so das
man solche Sachen auch anderen empfehlen kann. Nicht jeder
ist so visiert mit dem OpenSSL Umgang wie Du.

Grüße
Stefan
--
NaClbox: cc5c5f846c661343745772156a7751a5eb34d3e83d84b7d6884e507e105fd675
The computer helps us to solve problems, we did not have without him.
Marcel Logen
2020-10-17 22:57:49 UTC
Permalink
Post by Stefan Claas
Post by Marcel Logen
Es handelt sich BTW nicht um eine in das PDF integrierte
Signatur.
Ah, ok. Ist das dann richtig zu verstehen, als ob das mit
der Signatur so wie bei S/MIME der Fall ist.
Ja, das hatte ich auch gedacht (und denke es noch immer);
daher auch mein erster Versuch mit "openssl cms ..."

Aus der LibreSSL-man-page:

| The cms command handles S/MIME v3.1 mail. It can encrypt,
| decrypt, sign and verify, compress and uncompress S/MIME
| messages.

Ich vermute aber, daß "openssl cms ..." die eigentliche Signa-
tur (ECDSA) nicht korrekt aus der PKCS#7-Struktur herausziehen
kann, so daß man das selbst machen und dann auf "openssl dgst"
ausweichen muß.
Post by Stefan Claas
Falls ja, sollte
doch ein S/MIME fähiger MUA das können, obwohl ich nicht
weiß ob selbiger beim Signieren auch (.pdf Anhang?) mit
signieren würde.
Das weiß ich auch nicht. Hier geht es ja um eine *reine*
PDF-Datei (ohne Mailtext dabei).
Post by Stefan Claas
Post by Marcel Logen
Mir geht es aber um die Prüfung mit "openssl". Das sollte
IMHO prinzipiell machbar sein. (Irgendwo in der PKCS7-Datei
sollte die ECDSA-Signatur vorhanden sein.)
Ja, ist mir schon klar. Ich wollte nur darauf hinweisen das
man es sich (wenn möglich) einfach machen sollte, so das
man solche Sachen auch anderen empfehlen kann.
Klar, einverstanden. Aber Du weißt ja, daß ich nur ungern zu-
sätzliche Software installiere, so daß ich es vorzugsweise
mit Bordmitteln versuche (auch um das Prinzip verstehen zu
lernen).

Marcel
--
╮ ╭─╮ ╭───╮ ╭─────╮ ╭──────────╮ ╭──────╮ ╭────╮ ╭────╮
╰──╮ ╭─╯ ╰───╯ │ ╭─────╯ ╭──╯ │ ╰──╯ ╰──╯ ╭─╯ ╰─╮ ╰─
╰─╯ ╭──╯ │ ╭─────╯ ╭─╯ ╭───╯ ╭─╯
╰────╯ ╰────────╯ ╰────────╯
Christian @Soemtron
2020-10-19 13:03:00 UTC
Permalink
Post by Marcel Logen
| SecCommerce unter www.seccommerce.de. Die Signaturprüfung
| mit dem SecSigner kann direkt online erfolgen.
Finde ich generell wenig erstrebenswert: eigene Dokumente $irgendwohin
hochzuladen. Oder proprietäre Software zu nutzen, solange es gängige Open
Source-Tools gibt, die den Zweck erfüllen. Wir sind ja in
de.comp.security. Von daher wundert mich manche Antwort hier.
Post by Marcel Logen
Mir geht es aber um die Prüfung mit "openssl". Das sollte
IMHO prinzipiell machbar sein.
Betrifft mich zwar nicht, da hier immer nur ein einfaches pdf ankommt,
aber interessant wär's trotzdem.

cu,
Christian

PGP Key available.
Yamn Remailer
2020-10-19 19:09:14 UTC
Permalink
Post by Christian @Soemtron
Post by Marcel Logen
| SecCommerce unter www.seccommerce.de. Die Signaturprüfung
| mit dem SecSigner kann direkt online erfolgen.
Finde ich generell wenig erstrebenswert: eigene Dokumente $irgendwohin
hochzuladen. Oder proprietäre Software zu nutzen, solange es gängige Open
Source-Tools gibt, die den Zweck erfüllen. Wir sind ja in
de.comp.security. Von daher wundert mich manche Antwort hier.
Open Source Lösungen mögen erstrebenswert sein, wie aber das Beispiel
zeigt wohl nicht gerade Alltags tauglich. Des Weiteren müssen sich sehr
viele Menschen auf proprietäre Sicherheitslösungen verlassen, da es da
Open Source Lösungen nicht gibt, siehe z. B. eIDAS, oder Betriebssysteme
wie Windows oder macOS.
Marcel Logen
2020-10-19 20:36:48 UTC
Permalink
Post by Christian @Soemtron
Post by Marcel Logen
| SecCommerce unter www.seccommerce.de. Die Signaturprüfung
| mit dem SecSigner kann direkt online erfolgen.
Finde ich generell wenig erstrebenswert: eigene Dokumente $irgendwohin
hochzuladen. Oder proprietäre Software zu nutzen,
ACK
Post by Christian @Soemtron
solange es gängige Open
Source-Tools gibt, die den Zweck erfüllen.
Gibt es die?
Post by Christian @Soemtron
Post by Marcel Logen
Mir geht es aber um die Prüfung mit "openssl". Das sollte
IMHO prinzipiell machbar sein.
Betrifft mich zwar nicht, da hier immer nur ein einfaches pdf ankommt,
aber interessant wär's trotzdem.
Du kannst im Telekom-Kundencenter
<https://www.telekom.de/kundencenter/>
unter "Meine Rechnungen" unten bei "Rechnungseinstel-
lungen" unter "Download-Formate" die Signatur mit an-
fordern.

Dann oben die gewünschten Rechnungen ankreuzen und
"Sammeldownload starten". Das Ergebnis ist eine ZIP-Datei,
die die Rechnungen samt .pkcs7-Signaturen enthält (sofern
möglich).

Marcel
--
╭────────╮ ╭────────╮ ╭─────╮ ╭─╮ ╭────╮ ╭───╮
╯ │ ╰──────╮ ╰───╯ ╰─╯ ╰─╯ ╰──────────╯ ╰──╮
╭─╯ ╭─╮ ╭─╮ ╭─╮ ╭──╯ ╰─
╰───╯ ╰───╯ ╰─╯ ╰──╯
Christian @Soemtron
2020-10-20 20:09:00 UTC
Permalink
Post by Marcel Logen
Post by Christian @Soemtron
solange es
gängige Open
Source-Tools gibt, die den Zweck erfüllen.
Gibt es die?
Das werden Deine Tests ja vielleicht noch zeigen.
Post by Marcel Logen
unter "Meine Rechnungen" unten bei "Rechnungseinstel-
lungen" unter "Download-Formate" die Signatur mit an-
fordern.
Mache ich ggf., sobald man damit was Sinnvolles anfangen kann - wie z.B.
ein Script mit openssl darauf loslassen.

cu,
Christian

PGP Key available.
Yamn Remailer
2020-10-20 21:04:39 UTC
Permalink
Post by Marcel Logen
Post by Christian @Soemtron
Post by Marcel Logen
| SecCommerce unter www.seccommerce.de. Die Signaturprüfung
| mit dem SecSigner kann direkt online erfolgen.
Finde ich generell wenig erstrebenswert: eigene Dokumente $irgendwohin
hochzuladen. Oder proprietäre Software zu nutzen,
ACK
Post by Christian @Soemtron
solange es gängige Open
Source-Tools gibt, die den Zweck erfüllen.
Gibt es die?
https://www.linux.org/docs/man1/signver.html
Marcel Logen
2020-10-22 22:52:28 UTC
Permalink
Post by Yamn Remailer
Post by Marcel Logen
Post by Christian @Soemtron
Finde ich generell wenig erstrebenswert: eigene Dokumente $irgendwohin
hochzuladen. Oder proprietäre Software zu nutzen,
ACK
Post by Christian @Soemtron
solange es gängige Open
Source-Tools gibt, die den Zweck erfüllen.
Gibt es die?
https://www.linux.org/docs/man1/signver.html
Interessant, gehört wohl zu NSS, das ich (wg. Firefox) auch
schon hier auf dem OpenBSD-Rechner habe. Leider gibt es keine
man page dazu auf der Festplatte.

Ich habe ein wenig gebastelt und herumgespielt. Zunächst habe
ich das Intermediate- und das Root-Zertifikat in Firefox impor-
tiert. Die sind jetzt wohl in der Datei "cert9.db" (?) im Fire-
fox-Profilverzeichnis.

Jedenfalls konnte ich dann schon mal den Inhalt der PKCS#7-
Signaturdatei anzeigen lassen:

| t20$ signver -A -s 2020_10_rechnung_5XXXXXXXX7_sign_20201012.pkcs7 -d sql:/home/user20/.mozilla/firefox/8uuhate4.neu01
| pkcs7.contentInfo=PKCS #7 Signed Data
| pkcs7.version=1 (0x1)
| pkcs7.digestAlgorithmListLength=1
| pkcs7.digestAlgorithm[0]=SHA-256
| pkcs7.contentInformation=PKCS #7 Data
| pkcs7.data=<no content>
| pkcs7.certificateListLength=1
| certificate[0].data.version=3 (0x2)
| certificate[0].data.serialNumber=3a:39:87:e7:3e:8f:e4:ab:1c:34:24:cc:08:c3:6a:09
| certificate[0].data.signatureAlgorithm=X9.62 ECDSA signature with SHA256
| certificate[0].data.issuerName=OID.2.5.4.97=USt-IdNr. DE 123475223,CN=TeleSec PKS eIDAS QES CA 1,O=Deutsche Telekom AG,C=DE
| certificate[0].data.validity.notBefore=Mon Jul 01 13:05:50 2019
| certificate[0].data.validity.notAfter=Mon Jul 05 01:59:00 2021
| certificate[0].data.subject=pseudonym=Telekom Deutschland GmbH Dokument 3:PN,serialNumber=1,CN=Telekom Deutschland GmbH Dokument 3:PN,C=DE
[...]
| signerInformation[0].digestEncryptionAlgorithm=04:00:7f:00:07:01:01:04:01:03
| signerInformation[0].encryptedDigest=46:52:99:86:4a:f4:bb:f4:30:e1:39:b6:fd:97:e1:1f:15:45:ab:fb:fe:08:c2:b4:4b:df:fe:e7:f7:28:aa:0b:98:da:c5:eb:2e:20:74:5d:41:fb:a3:cf:de:fa:94:48:8f:a7:4f:cf:8f:a5:84:28:b9:63:c3:9a:90:92:84:90
| t20$

Die letzte Zeile - dachte ich bisher - wäre die eigentliche
Signatur. Jetzt lese ich da "encryptedDigest". Ja, was ist
das denn?! Muß ich mir noch näher ansehen.

Dann wollte ich natürlich die Signatur prüfen, aber da wird
mir dieser Fehler ausgegeben:

| t20$ signver -V -s 2020_10_rechnung_5XXXXXXXX7_sign_20201012.pkcs7 -i 2020_10_rechnung_5XXXXXXXX7_sign_20201012.pdf -d sql:/home/user20/.mozilla/firefox/8uuhate4.neu01 -v
| signatureValid=no:The certificate was signed using a signature algorithm that is disabled because it is not secure.
| t20$

Bisher habe ich da nichts von "SHA1" oder so gesehen. Vielleicht
kann das Tool nicht mit ECC umgehen? Muß ich auch noch mal etwas
googeln.

Aber immerhin. Danke für den Tip!

Marcel
--
╰─╮ ╭──╮ ╭─────╮ ╭──╮ ╭──╮ ╭─╮ ╭─╮ ╭────╮ ╭─
╰──╯ │ ╭──╮ ╰───╮ ╰─╯ ╰─╮ │ ╰─╮ │ ╰─╯ ╰──╮ ╰──╮ ╰─╯
╰─╯ ╰───╮ ╰─╮ ╭──╯ ╭─╯ ╭─╯ ╭─╯ ╭─────╯ ╭──╮ ╭─╮ │
╰────╯ ╰─────╯ ╰────╯ ╰────────╯ ╰─╯ ╰──╯
Marcel Logen
2020-10-22 23:06:24 UTC
Permalink
Marcel Logen in de.comp.security.misc:

[signver]
Post by Marcel Logen
Interessant, gehört wohl zu NSS, das ich (wg. Firefox) auch
schon hier auf dem OpenBSD-Rechner habe. Leider gibt es keine
man page dazu auf der Festplatte.
| t20$ pkg_info nss | head -n 7
| Information for inst:nss-3.58
|
| Comment:
| libraries to support development of security-enabled apps
|
| Required by:
| firefox-82.0

Statt man page kann man auch das hier verwenden:

| t20$ signver -h
| Usage: signver [ commands ] options
| signver - verify a detached PKCS7 signature - Version 3.58
| Commands:
| -A display all information from pkcs #7
| -V verify the signed object and display result
| Options:
| -a signature file is ASCII
| -d certdir directory containing cert database
| -i dataFileName input file containing signed data (default stdin)
| -o outputFileName output file name, default stdout
| -s signatureFileName input file for signature (default stdin)
| -v display verbose reason for failure
| t20$

Marcel
--
─╮ ╭────╮ ╭───────────╮ ╭─╮ ╭────╮
│ ╰──╮ │ ╭──╮ ╭─╮ ╰────╮ ╭─╯ ╭──╯ │ ╰──╮ │
│ ╭──╯ ╰─╯ │ ╭─╮ ╭─╮ ╭─╯ ╰──╮ │ ╰─╮ ╰─╮ ╰─────╮ ╭─╯ │
╰──╯ ╰──╯ ╰──╯ ╰─╯ ╰────╯ ╰────╯ ╰───────╯ ╰
Marcel Logen
2020-10-23 14:40:13 UTC
Permalink
Marcel Logen in de.comp.security.misc:

[...]
Post by Marcel Logen
Jedenfalls konnte ich dann schon mal den Inhalt der PKCS#7-
| t20$ signver -A -s 2020_10_rechnung_5XXXXXXXX7_sign_20201012.pkcs7 -d sql:/home/user20/.mozilla/firefox/8uuhate4.neu01
| pkcs7.contentInfo=PKCS #7 Signed Data
[...]
Post by Marcel Logen
| signerInformation[0].digestEncryptionAlgorithm=04:00:7f:00:07:01:01:04:01:03
| signerInformation[0].encryptedDigest=46:52:99:86:4a:f4:bb:f4:30:e1:39:b6:fd:97:e1:1f:15:45:ab:fb:fe:08:c2:b4:4b:df:fe:e7:f7:28:aa:0b:98:da:c5:eb:2e:20:74:5d:41:fb:a3:cf:de:fa:94:48:8f:a7:4f:cf:8f:a5:84:28:b9:63:c3:9a:90:92:84:90
| t20$
Die letzte Zeile - dachte ich bisher - wäre die eigentliche
Signatur. Jetzt lese ich da "encryptedDigest". Ja, was ist
das denn?! Muß ich mir noch näher ansehen.
In RFC2315 "PKCS #7: Cryptographic Message Syntax Version 1.5"
<https://tools.ietf.org/html/rfc2315> lese ich in Abschnitt 9:

| A recipient verifies the signatures by decrypting the encrypted
| message digest for each signer with the signer's public key, then
| comparing the recovered message digest to an independently computed
| message digest.

Aha. Mal sehen, ob ich damit irgendwie weiterkomme ...

Marcel
--
╭────╮ ╭─────────────╮ ╭──╮ ╭──────╮
─╯ ╭─╯ ╰──────╮ ╭───╯ │ ╰────────╮ ╰───╮ ╰──╮
╰──╮ ╭─╮ ╭─╮ ╭───╮ ╭─╮ ╭──╯ ╰─╮ ╭─╯ ╭─╯ ╰─╮ ╰
╰─╯ ╰──╯ ╰─╯ ╰──────╯ ╰──╯ ╰─╯ ╰──────────╯
Marcel Logen
2020-10-23 15:18:32 UTC
Permalink
Post by Marcel Logen
[...]
Post by Marcel Logen
| signerInformation[0].digestEncryptionAlgorithm=04:00:7f:00:07:01:01:04:01:03
| signerInformation[0].encryptedDigest=46:52:99:86:4a:f4:bb:f4:30:e1:39:b6:fd:97:e1:1f:15:45:ab:fb:fe:08:c2:b4:4b:df:fe:e7:f7:28:aa:0b:98:da:c5:eb:2e:20:74:5d:41:fb:a3:cf:de:fa:94:48:8f:a7:4f:cf:8f:a5:84:28:b9:63:c3:9a:90:92:84:90
| t20$
Die letzte Zeile - dachte ich bisher - wäre die eigentliche
Signatur. Jetzt lese ich da "encryptedDigest". Ja, was ist
das denn?! Muß ich mir noch näher ansehen.
In RFC2315 "PKCS #7: Cryptographic Message Syntax Version 1.5"
| A recipient verifies the signatures by decrypting the encrypted
| message digest for each signer with the signer's public key, then
| comparing the recovered message digest to an independently computed
| message digest.
Aha. Mal sehen, ob ich damit irgendwie weiterkomme ...
Kann doch eigentlich gar nicht sein. "Decrypt" sollte doch nur
mit einem "private key" gehen.

| t20$ openssl pkeyutl -decrypt -pubin -in signature91encrdig.bin -inkey pubk-aus-cert.der -keyform der -out signature91encrdig.decrypted
| A private key is needed for this operation
| Error initializing context
| usage: [...]

Klar. "A private key is needed".

Was nun?

Marcel
--
╭──────╮ ╭──────────╮ ╭──╮ ╭───╮ ╭──╮ ╭───╮ ╭──╮ ╭───
│ ╭───╯ ╰────────╮ │ ╭─╯ ╰─╯ ╰─╯ ╰─╮ │ │ ╭─╯ ╰─╯
│ ╰─────╮ ╭─╮ ╭──╮ ╭─╮ │ │ ╰─╮ ╭────────╯ │ ╰─╯
╯ ╰─────╯ ╰─╯ ╰─╯ ╰──╯ ╰────╯ ╰───────────╯
Marcel Logen
2020-10-23 15:36:50 UTC
Permalink
Post by Marcel Logen
| t20$ openssl pkeyutl -decrypt -pubin -in signature91encrdig.bin -inkey pubk-aus-cert.der -keyform der -out signature91encrdig.decrypted
| A private key is needed for this operation
| Error initializing context
| usage: [...]
Klar. "A private key is needed".
Was nun?
Mal mit "pkeyutl -verify" versuchen:

| t20$ openssl pkeyutl -verify -pubin -sigfile signature7ende.bin -keyform pem -inkey pubk-aus-cert.pem -in 2020_10_rechnung_5XXXXXXXX7_sign_20201012.pdf
| Signature Verification Failure
| t20$

Ich habe jetzt den Verdacht, daß man mit dem (derzeitigen)
OpenSSL/LibreSSL nicht weiterkommt, denn in der man page zu
LibreSSL steht unter "PKEYUTL" (ähnlich bei OpenSSL):

| The EC algorithm supports the sign, verify, and derive
| operations. The sign and verify operations use ECDSA and derive
| uses ECDH. Currently there are no additional options other than
| digest. Only the SHA1 digest can be used and this digest is
| assumed by default.

Tja.

Marcel
--
╭──────╮ ╭───╮ ╭─────────╮ ╭──╮ ╭─────╮ ╭─╮
╭──────────╯ ╭───╯ │ │ │ ╭──────╯ ╭──────╮ │ ╰─╯ ╭──╯ │ │
╯ ╭──────────╯ ╭─╮ │ ╰───╯ ╰─╮ ╰─╮ ╰─╯ ╭────╯ ╭───╯ ╰─╮
╰─────────────╯ ╰──╯ ╰────────╯ ╰──────╯ ╰─╮
Volker Delf
2020-10-23 17:32:14 UTC
Permalink
Post by Marcel Logen
Ich habe jetzt den Verdacht, daß man mit dem (derzeitigen)
OpenSSL/LibreSSL nicht weiterkommt, denn in der man page zu
| The EC algorithm supports the sign, verify, and derive
| operations. The sign and verify operations use ECDSA and derive
| uses ECDH. Currently there are no additional options other than
| digest. Only the SHA1 digest can be used and this digest is
| assumed by default.
Dann nimm doch secSignerVerify.jnlp, auch wenn dieTelekomrechnung
hochgeladen wird. So schön aufbereitet wie der Prüfbericht im
HTML-Format kann es OpenSSL/LibreSSL bestimmt nicht liefern ;-)

Benötigt wird mindestens Java JRE 8 und Windows 7 SP1 mit aktiviertem
TLS 1.2.

mfg Volker
Yamn Remailer
2020-10-19 21:24:17 UTC
Permalink
Post by Christian @Soemtron
Post by Marcel Logen
| SecCommerce unter www.seccommerce.de. Die Signaturprüfung
| mit dem SecSigner kann direkt online erfolgen.
Finde ich generell wenig erstrebenswert: eigene Dokumente $irgendwohin
hochzuladen. Oder proprietäre Software zu nutzen, solange es gängige Open
Source-Tools gibt, die den Zweck erfüllen. Wir sind ja in
de.comp.security. Von daher wundert mich manche Antwort hier.
Open Source Lösungen mögen erstrebenswert sein, wie aber das Beispiel
zeigt wohl nicht gerade Alltags tauglich. Des Weiteren müssen sich sehr
viele Menschen auf proprietäre Sicherheitslösungen verlassen, da es da
Open Source Lösungen nicht gibt, siehe z. B. eIDAS, oder Betriebssysteme
wie Windows oder macOS.
Volker Delf
2021-03-18 09:29:20 UTC
Permalink
Post by Marcel Logen
<https://www.telekom.de/hilfe/rechnung/rechnung-erhalten/digital-signierte-rechnung>
[...]
Post by Marcel Logen
<https://seccommerce.com/secsigner-online-uebersicht/>.
Es handelt sich BTW nicht um eine in das PDF integrierte
Signatur.
Tja, geht nicht mehr.
Der Limk "Online-Anwendung starten: Elektronische Signatur prüfen"

https://www.seccommerce.biz/secsigner/secSignerVerify.jnlp

führt zu einer unbenannten leeren Seite.
Eine Kontakt-Anfrage an SecCommerce Informationssysteme GmbH blieb
unbeantwortet.

Und in der "Telekom hilft Community | Vertrag & Rechnung" blieb auch
meine Antwort auf den Beitrag "Rechnung online- Digitale Signatur"
unbeantwortet. Es scheint sich wohl niemand mehr dafür zu interessieren.

mfg Volker
Marcel Logen
2021-03-29 10:23:44 UTC
Permalink
Post by Volker Delf
Post by Marcel Logen
<https://www.telekom.de/hilfe/rechnung/rechnung-erhalten/digital-signierte-rechnung>
[...]
Post by Marcel Logen
<https://seccommerce.com/secsigner-online-uebersicht/>.
Es handelt sich BTW nicht um eine in das PDF integrierte
Signatur.
Tja, geht nicht mehr.
Der Limk "Online-Anwendung starten: Elektronische Signatur prüfen"
https://www.seccommerce.biz/secsigner/secSignerVerify.jnlp
führt zu einer unbenannten leeren Seite.
Ja. Ist immer noch so, habe es soeben ausprobiert.
Post by Volker Delf
Eine Kontakt-Anfrage an SecCommerce Informationssysteme GmbH blieb
unbeantwortet.
Und in der "Telekom hilft Community | Vertrag & Rechnung" blieb auch
meine Antwort auf den Beitrag "Rechnung online- Digitale Signatur"
unbeantwortet. Es scheint sich wohl niemand mehr dafür zu interessieren.
Sieht so aus. :-(

Marcel
--
╭───╮ ╭─╮ ╭─╮ ╭─────╮ ╭──╮ ╭───╮ ╭──╯
╰─╮ ╰──────╮ ╭─────╯ ╰─╯ │ ╰─╮ ╰─╮ ╭───╯ │ │ ╰──╯
╭───╮ │ ╭─────╯ ╭──╯ ╭───╯ ╭───╮ │ ╭──╯ ╰──╮ ╰──╯
│ ╰──╯ ╰────────╯ ╰─────╯ ╰─╯ ╰────────╯
Marcel Logen
2021-03-29 10:39:37 UTC
Permalink
Post by Marcel Logen
Post by Volker Delf
Eine Kontakt-Anfrage an SecCommerce Informationssysteme GmbH blieb
unbeantwortet.
Und in der "Telekom hilft Community | Vertrag & Rechnung" blieb auch
meine Antwort auf den Beitrag "Rechnung online- Digitale Signatur"
unbeantwortet. Es scheint sich wohl niemand mehr dafür zu interessieren.
Sieht so aus. :-(
Ich habe es jetzt auch noch mal mit signver (NSS) versucht.
Immer noch: "disabled because it is not secure".

| t20$ nss-config --version nss
| 3.63.0

| t20$ signver -V -d sql:/home/user20/.mozilla/firefox/PROFIL/ -i /home/user20/ybtra-t20/2021_03_rechnung_BKTO_sign_20210310.pdf -s /home/user20/ybtra-t20/2021_03_rechnung_BKTO_sign_20210310.pkcs7 -v
| signatureValid=no:The certificate was signed using a signature algorithm that is disabled because it is not secure.
| t20$

"Das Zertifikat wurde signiert", hm.

Das Rootzertifikat von 2017 und das Intermediatezertifikat von
2017 wurden so signiert:

| Signature Algorithm: ecdsa-with-SHA512

Das Endzertifikat so:

| Signature Algorithm: ecdsa-with-SHA256

Ich glaube ja immer noch, daß der verwendete Algorithmus
zu neu ist (statt unsicher).

Na ja, mal weiter beobachten ...

Vielleicht tut sich ja bei NSS etwas.

Marcel
--
╭─╮ ╭─╮ ╭──╮ ╭──╮ ╭──╮ ╭──╮ ╭─────╮ ╭───
│ ╰─╯ ╰──╮ │ ╰───╯ ╰──╮ ╭─────╯ ╰─╮ ╭─╯ ╰──╯ ╰──╯
╮ │ ╰─╯ ╭─╯ │ ╭───────╯ │
╰─────────╯ ╰───╯ ╰───────────╯
Marcel Logen
2021-09-27 21:53:54 UTC
Permalink
Post by Marcel Logen
Ich habe es jetzt auch noch mal mit signver (NSS) versucht.
Immer noch: "disabled because it is not secure".
| t20$ nss-config --version nss
| 3.63.0
| t20$ signver -V -d sql:/home/user20/.mozilla/firefox/PROFIL/ -i /home/user20/ybtra-t20/2021_03_rechnung_BKTO_sign_20210310.pdf -s /home/user20/ybtra-t20/2021_03_rechnung_BKTO_sign_20210310.pkcs7 -v
| signatureValid=no:The certificate was signed using a signature algorithm that is disabled because it is not secure.
[...]
Post by Marcel Logen
Na ja, mal weiter beobachten ...
Vielleicht tut sich ja bei NSS etwas.
Neue Rechnung (2021-09), neue NSS-Version (3.70).

| t20$ signver -V -d sql:/home/user20/.mozilla/firefox/PROFIL/ -i 2021_09_rechnung_BKTO_sign_20210909.pdf -s 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -v
| signatureValid=no:Peer's Certificate issuer is not recognized.

=> etwas Neues (!)

Das eIDAS-5-Intermediate-Zertifikat in Firefox importiert:
<https://www.telesec.de/assets/downloads/PKI-Repository/TeleSec_PKS_eIDAS_QES_CA_5.cer>

<https://www.telesec.de/>, Root Programm, Intermediate-Zertifikate,
Intermediate-Zertifikate für qualifizierte Zertifikate, dort das
erste Zertifikat: "TeleSec PKS eIDAS QES CA 5"

Ergebnis:

| t20$ signver -V -d sql:/home/user20/.mozilla/firefox/PROFIL/ -i 2021_09_rechnung_BKTO_sign_20210909.pdf -s 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -v
| signatureValid=no:Signature verification failed: no signer found, too many signers found, or improper or corrupted data.

=> wieder etwas Neues, aber immer noch keine "valid signature"

Mit OpenSSL (subject) bin ich auch noch nicht weitergekommen.

Marcel
--
╭───╮ ╭──╮ ╭─╮ ╭─╮ ╭─╮ ╭─╮ ╭──────╮ ╭─
╰─╮ ╰─╮ ╭─╯ ╰──╯ │ │ ╰────╯ ╰─╯ ╰──╮ ╰────╮ ╰─╯
╮ ╰─╮ │ │ ╭──────╯ │ ╭────╯ ╭─╮ ╭──╮ ╰───╮
╰────╯ ╰──╯ ╰──────────╯ a86529 ╰──────────────────╯ ╰───╯ ╰──────╯
Stefan Claas
2021-09-28 14:38:55 UTC
Permalink
Post by Marcel Logen
Post by Marcel Logen
Ich habe es jetzt auch noch mal mit signver (NSS) versucht.
Immer noch: "disabled because it is not secure".
| t20$ nss-config --version nss
| 3.63.0
| t20$ signver -V -d sql:/home/user20/.mozilla/firefox/PROFIL/ -i /home/user20/ybtra-t20/2021_03_rechnung_BKTO_sign_20210310.pdf -s /home/user20/ybtra-t20/2021_03_rechnung_BKTO_sign_20210310.pkcs7 -v
| signatureValid=no:The certificate was signed using a signature algorithm that is disabled because it is not secure.
[...]
Post by Marcel Logen
Na ja, mal weiter beobachten ...
Vielleicht tut sich ja bei NSS etwas.
Neue Rechnung (2021-09), neue NSS-Version (3.70).
| t20$ signver -V -d sql:/home/user20/.mozilla/firefox/PROFIL/ -i 2021_09_rechnung_BKTO_sign_20210909.pdf -s 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -v
| signatureValid=no:Peer's Certificate issuer is not recognized.
=> etwas Neues (!)
<https://www.telesec.de/assets/downloads/PKI-Repository/TeleSec_PKS_eIDAS_QES_CA_5.cer>
<https://www.telesec.de/>, Root Programm, Intermediate-Zertifikate,
Intermediate-Zertifikate für qualifizierte Zertifikate, dort das
erste Zertifikat: "TeleSec PKS eIDAS QES CA 5"
| t20$ signver -V -d sql:/home/user20/.mozilla/firefox/PROFIL/ -i 2021_09_rechnung_BKTO_sign_20210909.pdf -s 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -v
| signatureValid=no:Signature verification failed: no signer found, too many signers found, or improper or corrupted data.
=> wieder etwas Neues, aber immer noch keine "valid signature"
Mit OpenSSL (subject) bin ich auch noch nicht weitergekommen.
Ich würde das mal lesen (letzer Absatz).

<https://www.telekom.de/hilfe/rechnung/rechnung-erhalten/digital-signierte-rechnung?samChecked=true>

Grüße
Stefan
Marcel Logen
2021-09-28 21:57:32 UTC
Permalink
Post by Stefan Claas
Ich würde das mal lesen (letzer Absatz).
<https://www.telekom.de/hilfe/rechnung/rechnung-erhalten/digital-signierte-rechnung?samChecked=true>
Danke, aber IIRC gibt es da seit dem Frühjahr (wo das hier im Thread
wohl schon mal zur Sprache kam) diesbezüglich keine Neuigkeiten.

Auf <https://seccommerce.com/> sucht man sich einen Wolf, bis man end-
lich <https://seccommerce.com/secsigner-online-uebersicht/> findet, und
wenn man dann auf "Online-Anwendung starten: Elektronische Signatur prü-
fen" klickt, kommt - immer noch - nur eine weiße Seite. Abgesehen davon,
daß ich meine Telekom-Rechnungen (mit Buchungskonto- und Telephonnummern)
nicht gern online irgendwo hochladen möchte.

Marcel
--
╭───────╮ ╭─╮ ╭───╮ ╭───╮ ╭───╮ ╭────╮ ╭─╮ ╭
╰────╮ ╰─╯ ╰──╯ │ ╭─╯ ╰─╮ │ ╰─────╯ ╰─╯ ╰────╯
╭─╮ │ ╰─╯ ╭────╯ ╭──╮ ╭─╮ ╭──╯
─╯ ╰──╯ ╰──────╯ ╰─╯ ╰────╯ 1acd27
Stefan Claas
2021-09-29 09:33:13 UTC
Permalink
Post by Marcel Logen
Post by Stefan Claas
Ich würde das mal lesen (letzer Absatz).
<https://www.telekom.de/hilfe/rechnung/rechnung-erhalten/digital-signierte-rechnung?samChecked=true>
Danke, aber IIRC gibt es da seit dem Frühjahr (wo das hier im Thread
wohl schon mal zur Sprache kam) diesbezüglich keine Neuigkeiten.
Auf <https://seccommerce.com/> sucht man sich einen Wolf, bis man end-
lich <https://seccommerce.com/secsigner-online-uebersicht/> findet, und
wenn man dann auf "Online-Anwendung starten: Elektronische Signatur prü-
fen" klickt, kommt - immer noch - nur eine weiße Seite. Abgesehen davon,
daß ich meine Telekom-Rechnungen (mit Buchungskonto- und Telephonnummern)
nicht gern online irgendwo hochladen möchte.
Ich würde da als Kunde einfach mal nachfragen, warum die Seite weiß ist.

Mit dem online hochladen dürfte wohl den Grund haben das nicht alle Kunden
sich das seccommerce Paket kaufen wollen. Ist ja bei mir auch so, wenn
ich ein eIDAS konformes .pdf signieren lasse und ggf. veröffentliche, sollen
Dritte auch die Möglichkeit haben, ohne extra Software etc. meine Signatur
online überprüfen zu können. Siehe dazu mein age pub key:

<https://github.com/sac001/my_public_age_key/blob/main/age.pdf_signed.pdf>

<https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation>

Grüße
Stefan
Stefan Claas
2021-09-29 09:41:15 UTC
Permalink
Post by Stefan Claas
<https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation>
Ich sehe gerade unter 'More options' das man da ein Zertifikat mit Dokument
hochladen kann ... Probiere das doch mal bitte.

Grüße
Stefan
Marcel Logen
2021-09-30 10:47:43 UTC
Permalink
Post by Stefan Claas
Post by Stefan Claas
<https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation>
Ich sehe gerade unter 'More options' das man da ein Zertifikat mit Dokument
hochladen kann ... Probiere das doch mal bitte.
| Privacy notice: Please note that by using the below functionality
| of the DSS demonstration, your files are going to be transmitted
| to the infrastructure of the European Commission. With your action
| to do so, you consent to this transmission of data and we strongly
^^^^^^^^^^^
| advise you to use documents that do not contain sensitive material.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Danke, aber wie ich schon schrieb: Ich werde auf solche Online-
Seiten keine Dokumente mit persönlichen Daten (Adresse, Buchungs-
kontonummer, Telephonnummern) hochladen.

Marcel
--
╭───────╮ ╭──╮ ╭─╮ ╭─────────╮ ╭─╮
╮ ╭─╮ ╭──╮ │ ╰──╯ ╰────╯ │ ╰─────╮ ╰──╮ ╭──╯ ╰─
╰──╮ ╭──╯ │ ╭───╯ ╰─╮ │ ╭────────────────╯ ╭─╮ │ ╭───╯ ╭─╯
╰─╯ ╰──╯ ╰─╯ ╰───────────────────╯ ╰───╯ ╰─────╯ c98f1a
Stefan Claas
2021-09-30 13:23:49 UTC
Permalink
Post by Marcel Logen
Post by Stefan Claas
Post by Stefan Claas
<https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation>
Ich sehe gerade unter 'More options' das man da ein Zertifikat mit Dokument
hochladen kann ... Probiere das doch mal bitte.
| Privacy notice: Please note that by using the below functionality
| of the DSS demonstration, your files are going to be transmitted
| to the infrastructure of the European Commission. With your action
| to do so, you consent to this transmission of data and we strongly
^^^^^^^^^^^
| advise you to use documents that do not contain sensitive material.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Danke, aber wie ich schon schrieb: Ich werde auf solche Online-
Seiten keine Dokumente mit persönlichen Daten (Adresse, Buchungs-
kontonummer, Telephonnummern) hochladen.
Wenigstens hast Du die Möglichkeit auch professionelle Werkzeuge
zu kaufen, falls die Linux Gemeinschaft das nicht gebacken bekommt.
Ggf. back to the roots (Rechnung per Briefpost).

Grüße
Stefan
Marcel Logen
2021-09-30 13:53:34 UTC
Permalink
Post by Stefan Claas
Post by Marcel Logen
Danke, aber wie ich schon schrieb: Ich werde auf solche Online-
Seiten keine Dokumente mit persönlichen Daten (Adresse, Buchungs-
kontonummer, Telephonnummern) hochladen.
Wenigstens hast Du die Möglichkeit auch professionelle Werkzeuge
zu kaufen, falls die Linux Gemeinschaft das nicht gebacken bekommt.
Ich weiß nicht, ob es an der "Linux-Gemeinschaft" oder an der
Telekom liegt. Aber Du hast recht: Den SecSigner gibt es wohl
auch für Linux:

<https://seccommerce.com/signatur-tools-fuer-endanwender/>

(Davon abgesehen läuft mein Hauptrechner hier unter OpenBSD.)
Post by Stefan Claas
Ggf. back to the roots (Rechnung per Briefpost).
Das würde dann natürlich extra kosten. Derzeit lade ich die
Rechnungen (mitsamt den Signaturdateien, falls das klappt! (das
ist nicht immer der Fall)) online aus dem Telekom-Kundencenter
herunter.

Das Ganze ist aber für mich nicht wirklich wichtig, da ich eigent-
lich nur wissen will, ob das von der Telekom angebotene Feature
(signierte Rechnungen) auch prinzipiell funktioniert.

Wahrscheinlich prüft sowieso 'niemand' solche Signaturen.

Ich glaube, STRATO (bin aber kein Kunde dort) bietet für seine
Rechnungen auch dieses Feature an.

Marcel
--
╰────╮ ╭───╮ ╭─╮ ╭─╮ ╭──────────
╭───╯ ╭─╮ ╭─╯ │ ╭──╯ ╰────╯ │ ╭────╮ ╰────╮
╰─╮ ╭─╯ │ ╰─╮ ╰────╮ ╰──────╮ ╭─╯ ╭─╮ ╭─╯ ╭─╯ ╭─────╯
╰───╯ ╰────╯ ╰──────────╯ ╰───────╯ ╰─╯ ╰───╯ 210237
Eike Rathke
2021-09-30 22:37:51 UTC
Permalink
Post by Stefan Claas
Wenigstens hast Du die Möglichkeit auch professionelle Werkzeuge
zu kaufen, falls die Linux Gemeinschaft das nicht gebacken bekommt.
Oder nur "professionelle Werkzeuge" funktionieren weil nur diese die
Standards nicht umgesetzt haben.

Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
Marcel Logen
2021-10-02 21:11:07 UTC
Permalink
Post by Marcel Logen
Post by Stefan Claas
Post by Stefan Claas
<https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation>
Ich sehe gerade unter 'More options' das man da ein Zertifikat mit Dokument
hochladen kann ... Probiere das doch mal bitte.
[...]
Post by Marcel Logen
Danke, aber wie ich schon schrieb: Ich werde auf solche Online-
Seiten keine Dokumente mit persönlichen Daten (Adresse, Buchungs-
kontonummer, Telephonnummern) hochladen.
Bei Klick auf obigen Link kommt jetzt leider ein 404er.

Ich hatte vor einigen Tagen gesehen, daß man dort auch SHA256-
Hashes zur Prüfung eingeben kann, was dann vermutlich wohl be-
deutet, daß ich nicht das originale PDF hochladen muß, sondern
nur die PKCS#7-Datei und den Hash der PDF-Datei.

Mal sehen, ob die Seite zu einem späteren Zeitpunkt mal wieder
aufrufbar ist.

Marcel
--
╭─╮ ╭───╮ ╭─────╮ ╭───╮ ╭────╮ ╭──╮ ╭─╮
──╯ │ │ │ │ ╰───╯ │ ╭────╮ ╰──╮ ╰───╯ ╰─╮ ╭──╯ ╰──
╰─╯ ╰───╯ ╭──────╯ │ ╭─╯ ╭──╯ ╰──╯
╰────────╯ ╰─────────────╯ ddbd2f
Stefan Claas
2021-10-03 09:26:02 UTC
Permalink
Post by Marcel Logen
Post by Marcel Logen
Post by Stefan Claas
Post by Stefan Claas
<https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation>
Ich sehe gerade unter 'More options' das man da ein Zertifikat mit Dokument
hochladen kann ... Probiere das doch mal bitte.
[...]
Post by Marcel Logen
Danke, aber wie ich schon schrieb: Ich werde auf solche Online-
Seiten keine Dokumente mit persönlichen Daten (Adresse, Buchungs-
kontonummer, Telephonnummern) hochladen.
Bei Klick auf obigen Link kommt jetzt leider ein 404er.
Ich hatte vor einigen Tagen gesehen, daß man dort auch SHA256-
Hashes zur Prüfung eingeben kann, was dann vermutlich wohl be-
deutet, daß ich nicht das originale PDF hochladen muß, sondern
nur die PKCS#7-Datei und den Hash der PDF-Datei.
Mal sehen, ob die Seite zu einem späteren Zeitpunkt mal wieder
aufrufbar ist.
Es gibt auch polnische und italienische Seiten, die eine Überprüfung
erlauben, jedoch IIRC nicht mit den extra Optionen.

Ich hatte auch mal weiter geforscht und drei weitere Linux Pakete
gefunden, jedoch da ich ja weiß das du nicht installierst brauche
ich darauf nicht näher eingehen.

Ein andere Artikel, über OpenSSL, beschreibt auch wie man selbst
eIDAS Zertifikate signieren kann, jedoch ist das auch nicht hilfreich.

Grüße
Stefan
Stefan Claas
2021-10-03 09:36:11 UTC
Permalink
Post by Stefan Claas
Ein andere Artikel, über OpenSSL, beschreibt auch wie man selbst
eIDAS Zertifikate signieren kann, jedoch ist das auch nicht hilfreich.
Was ich dir unbedinngt, als OpenSSL Nutzer, empfehlen würde, ist
deren Mailing List beizutreten. Die können garantiert helfen oder
falls da etwas nicht funktioniert, dann eben implementieren.

Das hilft dann auch anderen und nur nicht dir.

https://www.openssl.org/community/mailinglists.html

Grüße
Stefan
Eike Rathke
2021-09-29 22:47:21 UTC
Permalink
Post by Marcel Logen
Post by Stefan Claas
<https://www.telekom.de/hilfe/rechnung/rechnung-erhalten/digital-signierte-rechnung?samChecked=true>
Danke, aber IIRC gibt es da seit dem Frühjahr (wo das hier im Thread
wohl schon mal zur Sprache kam) diesbezüglich keine Neuigkeiten.
Wenn das wirklich PKCS #7 ist wie auf der Seite erwaehnt ("Name der
Signatur-Datei endet auf .pkcs7"), koennte openssl weiterhelfen.

man 1ssl pkcs7
man 1ssl smime

Zertifikat ausgeben:
openssl pkcs7 -in cert.pkcs7 -noout -print_certs

Dokument verifizieren:
openssl smime -verify -in pkcs7 -inform PEM -content document -certfile cert.pkcs7 -noverify

Wenn cert.pkcs7 nicht base64 (mit "----BEGIN CERTIFICATE-----" ...)
sondern binaer ist dann -inform DER statt PEM verwenden.

Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
Marcel Logen
2021-09-30 10:40:27 UTC
Permalink
Post by Eike Rathke
Post by Marcel Logen
Danke, aber IIRC gibt es da seit dem Frühjahr (wo das hier im Thread
wohl schon mal zur Sprache kam) diesbezüglich keine Neuigkeiten.
Wenn das wirklich PKCS #7 ist wie auf der Seite erwaehnt ("Name der
Signatur-Datei endet auf .pkcs7"), koennte openssl weiterhelfen.
Das war ja auch mein ursprünglicher Ansatz:

<https://groups.google.com/g/de.comp.security.misc/c/V4ZGHPCjZRg>
Post by Eike Rathke
man 1ssl pkcs7
man 1ssl smime
Ich benutze hier LibreSSL unter OpenBSD.

Idee: Vielleicht versuche ich es auch einmal mit Linux und OpenSSL.
Post by Eike Rathke
openssl pkcs7 -in cert.pkcs7 -noout -print_certs
| t20$ openssl pkcs7 -in 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -inform DER -noout -print_certs
| subject=/C=DE/CN=Telekom Deutschland GmbH - Dokument 4:PN/serialNumber=1/pseudonym=Telekom Deutschland GmbH - Dokument 4:PN
| issuer=/C=DE/O=Deutsche Telekom AG/CN=TeleSec PKS eIDAS QES CA 5/2.5.4.97=USt-IdNr. DE 123475223

Und

| t20$ openssl pkcs7 -in 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -inform DER -out zert20210930a.pem -outform PEM -print_certs

| t20$ ls -l zert2021093*
| -rw-r--r-- 1 user20 user20 2649 Sep 30 12:33 zert20210930a.pem
| t20$
Post by Eike Rathke
openssl smime -verify -in pkcs7 -inform PEM -content document -certfile cert.pkcs7 -noverify
Wenn cert.pkcs7 nicht base64 (mit "----BEGIN CERTIFICATE-----" ...)
sondern binaer ist dann -inform DER statt PEM verwenden.
Ich hatte es hier mit "cms" statt "smime" versucht, das sollte
aber IMHO keinen Unterschied machen.

Leider kommt wieder der "nested asn1 error":

| t20$ openssl smime -verify -in 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -inform DER -content 2021_09_rechnung_BKTO_sign_20210909.pdf -certfile zert20210930a.pem -noverify -out $(mktemp -p .)
| Verification failure
| 4621072050568:error:0DFFF0A8:asn1 encoding routines:CRYPTO_internal:wrong tag:/usr/src/lib/libcrypto/asn1/tasn_dec.c:1167:
| 4621072050568:error:0DFFF03A:asn1 encoding routines:CRYPTO_internal:nested asn1 error:/usr/src/lib/libcrypto/asn1/tasn_dec.c:337:Type=ECDSA_SIG
| 4621072050568:error:21FFF069:PKCS7 routines:CRYPTO_internal:signature failure:/usr/src/lib/libcrypto/pkcs7/pk7_doit.c:1073:
| 4621072050568:error:21FFF069:PKCS7 routines:CRYPTO_internal:signature failure:/usr/src/lib/libcrypto/pkcs7/pk7_smime.c:407:
| t20$

Marcel
--
╭─╮ ╭──╮ ╭───────────╮ ╭──╮ ╭───╮ ╭────╮ ╭────╮
╮ │ ╰─╯ │ ╰────────╮ │ │ ╰──╯ │ ╰─╮ ╰──╯ ╭─╯
│ ╭─╯ ╰─╮ ╭──╮ ╭─╯ ╰─╯ ╭──────╯ ╭──╮ ╭──╯ ╭─────╯ ╭───╮
╰───╯ ╰──╯ ╰─╯ ea01c4 ╰──────────╯ ╰──╯ ╰───────╯ ╰───
Eike Rathke
2021-09-30 22:37:51 UTC
Permalink
Post by Marcel Logen
Post by Eike Rathke
Wenn das wirklich PKCS #7 ist wie auf der Seite erwaehnt ("Name der
Signatur-Datei endet auf .pkcs7"), koennte openssl weiterhelfen.
<https://groups.google.com/g/de.comp.security.misc/c/V4ZGHPCjZRg>
Oh, das war mir nicht bekannt, ok, das dreht auf der Stelle im Kreis.
Post by Marcel Logen
| t20$ openssl pkcs7 -in 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -inform DER -noout -print_certs
| subject=/C=DE/CN=Telekom Deutschland GmbH - Dokument 4:PN/serialNumber=1/pseudonym=Telekom Deutschland GmbH - Dokument 4:PN
| issuer=/C=DE/O=Deutsche Telekom AG/CN=TeleSec PKS eIDAS QES CA 5/2.5.4.97=USt-IdNr. DE 123475223
Na wenigstens das stimmt..
Post by Marcel Logen
Post by Eike Rathke
openssl smime -verify -in pkcs7 -inform PEM -content document -certfile cert.pkcs7 -noverify
Ich hatte es hier mit "cms" statt "smime" versucht, das sollte
aber IMHO keinen Unterschied machen.
Hmja.. im Gegenteil, cms kann mehr als das alte smime.

Aber: ich hab da nen Fehler hinkopiert aus dem vorherigen pkcs7 Befehl,
-in pkcs7 gehoert da gar nicht hin. -in filename waere um eine ganze
message zu pruefen.
Post by Marcel Logen
| t20$ openssl smime -verify -in 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -inform DER -content 2021_09_rechnung_BKTO_sign_20210909.pdf -certfile zert20210930a.pem -noverify -out $(mktemp -p .)
| Verification failure
| 4621072050568:error:0DFFF03A:asn1 encoding routines:CRYPTO_internal:nested asn1 error:/usr/src/lib/libcrypto/asn1/tasn_dec.c:337:Type=ECDSA_SIG
Wieso -inform DER mit einer .pem Datei? Oder das ist aber nicht
zufaellig eine .pem Datei mit zu langer base64 Zeile? Kurze Suche nach
"nested asn1 error" ergab https://github.com/dotnet/runtime/issues/24525
und
https://blog.oneiroi.co.uk/openssl/x.509/pcks7/openssl-unable-to-load-certificate-wrong-asn1-encoding-routines-asn1-check-tlen-tag-tasn-dec-dot-c-1319/

openssl cms -verify -content 2021_09_rechnung_BKTO_sign_20210909.pdf -certfile zert20210930a.pem -noverify

tut auch nicht?

Eike
--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Use LibreOffice! https://www.libreoffice.org/
Marcel Logen
2021-09-30 23:28:08 UTC
Permalink
Post by Eike Rathke
Post by Marcel Logen
Ich hatte es hier mit "cms" statt "smime" versucht, das sollte
aber IMHO keinen Unterschied machen.
Hmja.. im Gegenteil, cms kann mehr als das alte smime.
CMS habe ich genommen, da es AFAIK neuer ist. Mit den genauen
Unterschieden habe ich mich nicht befaßt.
Post by Eike Rathke
Aber: ich hab da nen Fehler hinkopiert aus dem vorherigen pkcs7 Befehl,
-in pkcs7 gehoert da gar nicht hin. -in filename waere um eine ganze
message zu pruefen.
IMHO muß bei abgetrennten Signaturen die Signatur mit "-in" als PKCS#7
und der Content mit "-content" als PDF übergeben werden. Ich hatte es
auch zusätzlich mal mit "-binary" versucht, da es sich ja bei dem PDF
nicht um ein Mail-artiges Format handelt.
Post by Eike Rathke
Post by Marcel Logen
| t20$ openssl smime -verify -in 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -inform DER -content 2021_09_rechnung_BKTO_sign_20210909.pdf -certfile zert20210930a.pem -noverify -out $(mktemp -p .)
| Verification failure
| 4621072050568:error:0DFFF03A:asn1 encoding routines:CRYPTO_internal:nested asn1 error:/usr/src/lib/libcrypto/asn1/tasn_dec.c:337:Type=ECDSA_SIG
Wieso -inform DER mit einer .pem Datei?
Weil "-inform" meiner Meinung nach zu "-in" gehört (und nicht zu
"-content" oder "-certfile"; letzteres soll nach Aussage der Libre-
SSL-man-page immer im PEM-Format sein). Die PKCS#7-Datei ist hier
im Binärformat.

Ich denke auch, daß man "-certfile" hier nicht braucht, da es
sich dabei um "additional certificates" handelt.
Post by Eike Rathke
Oder das ist aber nicht
zufaellig eine .pem Datei mit zu langer base64 Zeile? Kurze Suche nach
"nested asn1 error" ergab https://github.com/dotnet/runtime/issues/24525
und
https://blog.oneiroi.co.uk/openssl/x.509/pcks7/openssl-unable-to-load-certificate-wrong-asn1-encoding-routines-asn1-check-tlen-tag-tasn-dec-dot-c-1319/
Danke für die Hinweise. Überlange Base64-Zeilen habe ich hier
nicht gesehen.

Was mich allerdings jetzt stutzig macht, ist das "Type=ECDSA_SIG"
(bei mir). In den von Dir genannten Web-Beispielen steht da "Type=
CMS_ContentInfo" bzw. "Type=X509_CINF".
Post by Eike Rathke
openssl cms -verify -content 2021_09_rechnung_BKTO_sign_20210909.pdf -certfile zert20210930a.pem -noverify
tut auch nicht?
Leider nein, da 'wartet' LibreSSL auf eine weitere Eingabe (von
STDIN), nämlich vermutlich auf die Signatur, die - wie ich meine
- mit "-in" übergeben werden sollte (s. o.).

Marcel
--
╭──────╮ ╭─╮ ╭───╮ ╭──╮ ╭─╮ ╭─
╭─╯ ╭───╯ │ │ ╭─╯ ╰─╮ ╭──╯ ╰─╯ │ │
─╮ ╭───────╮ ╭─╯ ╭─╯ ╭──╯ ╰──╯ ╭──╯ ╰─╮ ╰─╮ ╭──╯
╰─╯ ╰──╯ ╰────╯ ╰───────╯ 507d8f ╰───────────╯
Marcel Logen
2021-09-30 23:53:47 UTC
Permalink
Post by Marcel Logen
Post by Eike Rathke
openssl cms -verify -content 2021_09_rechnung_BKTO_sign_20210909.pdf -certfile zert20210930a.pem -noverify
tut auch nicht?
Leider nein, da 'wartet' LibreSSL auf eine weitere Eingabe (von
STDIN), nämlich vermutlich auf die Signatur, die - wie ich meine
- mit "-in" übergeben werden sollte (s. o.).
Ich habe es gerade noch einmal so versucht (was IMHO von der Syntax
her korrekt sein sollte):

| t20$ openssl cms -verify -binary -in 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -content 2021_09_rechnung_BKTO_sign_20210909.pdf -inform der -signer zert20210930a.pem -CAfile root-u-eidas5.pem
| Verification failure
| 10432027605624:error:0DFFF0A8:asn1 encoding routines:CRYPTO_internal:wrong tag:/usr/src/lib/libcrypto/asn1/tasn_dec.c:1167:
| 10432027605624:error:0DFFF03A:asn1 encoding routines:CRYPTO_internal:nested asn1 error:/usr/src/lib/libcrypto/asn1/tasn_dec.c:337:Type=ECDSA_SIG
| 10432027605624:error:2EFFF09E:CMS routines:CRYPTO_internal:verification failure:/usr/src/lib/libcrypto/cms/cms_sd.c:818:
| t20$

Genug für heute ...

Marcel
--
╭────────╮ ╭─────╮ ╭───╮ ╭─╮ ╭─╮ ╭─╮ ╭─
────╮ ╰──╮ ╰─╮ ╰───╮ ╰─╯ ╰─╮ │ ╰──╮ │ ╰──╮ │ ╰──╯
╭─╯ ╭───╮ ╰────╮ ╰───╮ ╰─╮ ╰───╯ ╰─╮ ╰─╮ │ │
╰───────╯ ╰───────╯ ╰────╯ ╰────╯ ╰───╯1842f5
Marcel Logen
2021-10-11 17:27:43 UTC
Permalink
Post by Marcel Logen
Ich habe es gerade noch einmal so versucht (was IMHO von der Syntax
| t20$ openssl cms -verify -binary -in 2021_09_rechnung_BKTO_sign_20210909.pkcs7 -content 2021_09_rechnung_BKTO_sign_20210909.pdf -inform der -signer zert20210930a.pem -CAfile root-u-eidas5.pem
| Verification failure
| 10432027605624:error:0DFFF03A:asn1 encoding routines:CRYPTO_internal:nested asn1 error:/usr/src/lib/libcrypto/asn1/tasn_dec.c:337:Type=ECDSA_SIG
| t20$
Das "-signer" hatte ich flacsh interpretiert, nämlich als Input
für das Signierzertifikat. Es ist aber eine Output-Datei, in die
das Zertifikat des Signierers hineingeschrieben wird.

Diese Option benutze ich deshalb jetzt nicht.
Post by Marcel Logen
Genug für heute ...
Neue Rechnung, neue Zertifikate <seufz>.

Aber jetzt geht's (!):

| t20$ openssl cms -verify -binary -in 2021_10_rechnung_BKTO_sign_20211011.pkcs7 -content 2021_10_rechnung_BKTO_sign_20211011.pdf -inform der -CAfile 2021_10CAfile.pem > /dev/null
| Verification successful
| t20$

Die Datei "2021_10CAfile.pem" enthält - jeweils im PEM-Format -
die Zertifikate

- T-TeleSec_GlobalRoot_Class_2.pem
- TeleSec_Business_CA_1.pem

Beide sind bei <https://www.telesec.de/> (dort "Root Programm" wählen)
zu beziehen (unter "Root-Zertifikate" bzw. "Intermediate-Zertifikate").

Sie müssen mit "openssl x509 ..." vom DER- in das PEM-Format über-
führt werden.

Wie ich den trusted Zertifikatsspeicher meines Systems bei der Veri-
fikation nutzen kann (er enthält das "T-TeleSec GlobalRoot Class 2"),
habe ich noch nicht herausgefunden.

Marcel
--
│ ╭──╮ ╭─╮ ╭───╮ ╭─────╮ ╭───────────╮ ╭─╮
╰─╯ │ │ ╰───╮ ╰─╮ ╰─╮ ╭─╮ ╰─╮ │ ╭─╮ ╰────────╮ ╰──╮ ╭───╯ ╰
╭───╯ ╰──╮ ╰───╮ ╰─╮ ╰─╯ ╰────╯ ╰───╯ ╰─╮ ╭───╮ │ ╭──╯ │
╰─────────╯ ╰────╯ ╰──╯ ╰──╯ ╰─────╯4aaa3a
Marcel Logen
2021-10-11 18:00:21 UTC
Permalink
Post by Marcel Logen
Neue Rechnung, neue Zertifikate <seufz>.
| t20$ openssl cms -verify -binary -in 2021_10_rechnung_BKTO_sign_20211011.pkcs7 -content 2021_10_rechnung_BKTO_sign_20211011.pdf -inform der -CAfile 2021_10CAfile.pem > /dev/null
| Verification successful
| t20$
Es funktioniert BTW jetzt auch mit nss/3.71:

| t20$ signver -V -d sql:/home/user20/.mozilla/firefox/PROFIL/ -i 2021_10_rechnung_BKTO_sign_20211011.pdf -s 2021_10_rechnung_BKTO_sign_20211011.pkcs7 -v
| signatureValid=yes
| t20$

Ich mußte dem Zertifikat "TeleSec Business CA 1" noch per Häkchen
im Firefox das Vertrauen für die eMail-Signatur aussprechen. Sonst
kam immer "signatureValid=no:Peer's Certificate issuer is not re-
cognized."

Ein Tag der Erfolge! :-)

Jetzt fehlt nur noch die Prüfung mit dem CEF-Digital-Online-
Tool (per SHA256-Upload). Die ist mir vor einigen Tagen (mit
der September-Rechnung) leider nicht gelungen (als die Website
wieder da war). Da kam immer ein "Hash-Fehler".

<https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation>

Marcel
--
╭─╮ ╭───╮ ╭─╮ ╭───╮
╭─╮ │ │ ╭─╯ │ ╭─────╯ ╰─╮ ╭─╮ ╭─────╯ │ ╭─╮ ╭──
╯ │ ╭─╯ ╰──╮ │ ╭─╯ │ ╭──────╯ │ │ ╭───╮ ╭───╯ ╰────╯ ╰──╯
╰─╯ ╰──╯ ╰────╯ ╰────────╯ ╰─╯ ╰─╯ 78d15c
Marcel Logen
2021-10-11 21:51:04 UTC
Permalink
Post by Marcel Logen
Neue Rechnung, neue Zertifikate <seufz>.
| t20$ openssl cms -verify -binary -in 2021_10_rechnung_BKTO_sign_20211011.pkcs7 -content 2021_10_rechnung_BKTO_sign_20211011.pdf -inform der -CAfile 2021_10CAfile.pem > /dev/null
| Verification successful
| t20$
Der Unterschied zu den bisherigen Zertifikaten ist:

Es wird jetzt "sha256WithRSAEncryption" verwendet statt
"ecdsa-with-SHA256" (bzw. "ecdsa-with-SHA512"), also RSA.

Keine Ahnung, warum es mit ECDSA nicht funktioniert hat.
Ob das noch nicht richtig implementiert ist?

Interessant ist auch, daß das (letzte, unterste) Zertifikat
einen IMHO ungewöhnlichen RSA-Exponenten e (65541 = 0x10005 =
3 * 7 * 3121) benutzt.

Marcel
--
╭─────╮ ╭────╮ ╭───╮ ╭─╮ ╭───╮ ╭─────────────────╮ ╭────╮
──╯ ╭──╯ │ ╰─╯ ╰─╯ ╰─╯ │ ╰───────╮ ╭──╯ ╰──╮ ╰──
╭───╯ ╰─╮ ╭──────╯ ╭───╮ ╭──╮ ╭─╯ ╭─╯ ╭─╮ ╰─╮
╰────────────╯ ╰────────╯ ╰──╯ ╰───╯2faa4f╰─────╯ ╰────╯
Volker Delf
2021-10-13 11:47:22 UTC
Permalink
Post by Marcel Logen
| t20$ openssl cms -verify -binary -in 2021_10_rechnung_BKTO_sign_20211011.pkcs7 -content 2021_10_rechnung_BKTO_sign_20211011.pdf -inform der -CAfile 2021_10CAfile.pem > /dev/null
| Verification successful
| t20$
Meine Anerkennung :-)

Funktioniert auch unter Windows, wenn in eine Dati (dummy.txt)
umgeleitet wird, deren Inhalt mir nichts sagt.
Post by Marcel Logen
Die Datei "2021_10CAfile.pem" enthält - jeweils im PEM-Format -
die Zertifikate
- T-TeleSec_GlobalRoot_Class_2.pem
- TeleSec_Business_CA_1.pem
Wie kommt man eigentlich darauf, dass das Zwischenzertifikat
TeleSec_Business_CA_1.pem erforderlich ist?
Post by Marcel Logen
Beide sind bei <https://www.telesec.de/> (dort "Root Programm" wählen)
zu beziehen (unter "Root-Zertifikate" bzw. "Intermediate-Zertifikate").
Sie müssen mit "openssl x509 ..." vom DER- in das PEM-Format über-
führt werden.
Die Umwandlung von einer binären CER-Datei in eine Base64-codierten
PEM-Datei kann auch in windows nach Aufruf in den Details erfolgen.


mfg Volker
Juergen Ilse
2021-10-13 12:34:46 UTC
Permalink
Hallo,
Post by Volker Delf
Post by Marcel Logen
| t20$ openssl cms -verify -binary -in 2021_10_rechnung_BKTO_sign_20211011.pkcs7 -content 2021_10_rechnung_BKTO_sign_20211011.pdf -inform der -CAfile 2021_10CAfile.pem > /dev/null
| Verification successful
| t20$
Meine Anerkennung :-)
Funktioniert auch unter Windows, wenn in eine Dati (dummy.txt)
umgeleitet wird, deren Inhalt mir nichts sagt.
Post by Marcel Logen
Die Datei "2021_10CAfile.pem" enthält - jeweils im PEM-Format -
die Zertifikate
- T-TeleSec_GlobalRoot_Class_2.pem
- TeleSec_Business_CA_1.pem
Wie kommt man eigentlich darauf, dass das Zwischenzertifikat
TeleSec_Business_CA_1.pem erforderlich ist?
Weil *alle* Intermediate Zertifikate (ja, das koennen auch mehrere sein)
Teil der gesamten Zertifikatskette sind. Durch das root Zertifikat wird
nicht die Echtheit des Zertifikats bestaetigt, dass du testen willst,
sondern nur die Echtheit des ersten Intermediate Zertifikats.
Durch dieses Zertifikat (und das Wissen um desssen Echtheit) wird die
Gueltigkeit des naechsten Zertifikats in der Kette bestaetigt usw.
Ist auch nur *ein* Zertifikat der Kette nicht bekannt oder kann dessen
Echtheit nicht verifiziert werden, ist die Kette unterbrochen, und die
Echtheit des Zertifikats am Ende der Kette kann nicht mehr verifiziert
werden.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Marcel Logen
2021-10-13 15:37:10 UTC
Permalink
Post by Juergen Ilse
Post by Volker Delf
Post by Marcel Logen
Die Datei "2021_10CAfile.pem" enthält - jeweils im PEM-Format -
die Zertifikate
- T-TeleSec_GlobalRoot_Class_2.pem
- TeleSec_Business_CA_1.pem
Wie kommt man eigentlich darauf, dass das Zwischenzertifikat
TeleSec_Business_CA_1.pem erforderlich ist?
Weil *alle* Intermediate Zertifikate (ja, das koennen auch mehrere sein)
Teil der gesamten Zertifikatskette sind. Durch das root Zertifikat wird
nicht die Echtheit des Zertifikats bestaetigt, dass du testen willst,
sondern nur die Echtheit des ersten Intermediate Zertifikats.
Durch dieses Zertifikat (und das Wissen um desssen Echtheit) wird die
Gueltigkeit des naechsten Zertifikats in der Kette bestaetigt usw.
Ist auch nur *ein* Zertifikat der Kette nicht bekannt oder kann dessen
Echtheit nicht verifiziert werden, ist die Kette unterbrochen, und die
Echtheit des Zertifikats am Ende der Kette kann nicht mehr verifiziert
werden.
Sei "2021_10cert.pem" das von der Rechnungsstelle der Telekom
benutzte Endzertifikat, ...

| t20$ openssl x509 -in 2021_10cert.pem -noout -subject -issuer -dates -serial
| subject= /C=DE/O=Telekom Deutschland GmbH/OU=Internal-Customers/OU=1-key/CN=GRP: Telekom Deutschland GmbH Dokument/GN=GRP:/SN=Telekom Deutschland GmbH Dokument/emailAddress=***@telekom.de/serialNumber=2
| issuer= /C=DE/O=T-Systems International GmbH/OU=T-Systems Trust Center/CN=TeleSec Business CA 1
| notBefore=Sep 23 15:17:35 2021 GMT
| notAfter=Sep 23 23:59:59 2024 GMT
| serial=363A552F20D2BAD114513DDAE25D80E4

... dann prüfe ich die Zert.-Kette wie folgt:

| t20$ openssl verify -untrusted TeleSec_Business_CA_1.pem 2021_10cert.pem
| 2021_10cert.pem: OK
| t20$

Das setzt voraus, daß das Root-Zertifikat im trusted Zertifikatsspeicher
des Systems enthalten ist.

Man kann auch mit "-CAfile" arbeiten, dann wird der Systmspeicher wohl
umgangen IMHO:

| t20$ openssl verify -untrusted TeleSec_Business_CA_1.pem -CAfile T-TeleSec_GlobalRoot_Class_2.pem 2021_10cert.pem
| 2021_10cert.pem: OK
| t20$

Marcel
--
╭──╮ ╭────╮ ╭─────────────╮ ╭───────╮
│ │ ╰─╮ │ ╰────────╮ ╭─╯ ╰────╮ │
│ ╰─╮ │ ╰──╮ ╭─╮ ╭──╮ ╭──╮ ╭─╮ ╭───╯ ╰───╮ ╭───╯ ╰─╮ ╭──╮
╯ ╰──╯ ╰──╯ ╰───╯ ╰───╯ ╰─╯ ╰──╯ ╰─╯ a61f61 ╰─╯ ╰────
Marcel Logen
2021-10-13 15:27:30 UTC
Permalink
Post by Volker Delf
Post by Marcel Logen
| t20$ openssl cms -verify -binary -in 2021_10_rechnung_BKTO_sign_20211011.pkcs7 -content 2021_10_rechnung_BKTO_sign_20211011.pdf -inform der -CAfile 2021_10CAfile.pem > /dev/null
| Verification successful
| t20$
Meine Anerkennung :-)
Danke, aber ich glaube inzwischen, daß es nur daran lag, daß die
Telekom jetzt RSA statt ECDSA verwendet hat. ECDSA ist wohl ver-
mutlich entweder bei der Telekom oder in Open-/LibreSSL und NSS
nicht richtig implementiert.
Post by Volker Delf
Funktioniert auch unter Windows, wenn in eine Dati (dummy.txt)
umgeleitet wird, deren Inhalt mir nichts sagt.
Das, was da ausgegeben wird, ist die ursprüngliche PDF-Datei:

| t20$ openssl cms -verify -binary -in 2021_10_rechnung_BKTO_sign_20211011.pkcs7 -content 2021_10_rechnung_BKTO_sign_20211011.pdf -inform der -CAfile 2021_10CAfile.pem -out dummy.txt
| Verification successful

| t20$ ls -l dummy.txt
| -rw-r--r-- 1 user20 user20 156840 Oct 13 17:12 dummy.txt

| t20$ cmp dummy.txt 2021_10_rechnung_BKTO_sign_20211011.pdf
| t20$

Die Dateien haben also den gleichen Inhalt.
Post by Volker Delf
Post by Marcel Logen
Die Datei "2021_10CAfile.pem" enthält - jeweils im PEM-Format -
die Zertifikate
- T-TeleSec_GlobalRoot_Class_2.pem
- TeleSec_Business_CA_1.pem
Wie kommt man eigentlich darauf, dass das Zwischenzertifikat
TeleSec_Business_CA_1.pem erforderlich ist?
In der .pkcs7-Datei ist das Endzertifikat enthalten. Dessen Issuer kann
man sich so anzeigen lassen:

| t20$ openssl pkcs7 -in 2021_10_rechnung_BKTO_sign_20211011.pkcs7 -inform DER -noout -print_certs
| subject=/C=DE/O=Telekom Deutschland GmbH/OU=Internal-Customers/OU=1-key/CN=GRP: Telekom Deutschland GmbH Dokument/GN=GRP:/SN=Telekom Deutschland GmbH Dokument/emailAddress=***@telekom.de/serialNumber=2
| issuer=/C=DE/O=T-Systems International GmbH/OU=T-Systems Trust Center/CN=TeleSec Business CA 1
|
| t20$

Das "TeleSec Business CA 1" wiederum wurde signiert von "T-TeleSec
GlobalRoot Class 2":

| t20$ openssl x509 -in TeleSec_Business_CA_1.pem -noout -subject -issuer -dates -serial
| subject= /C=DE/O=T-Systems International GmbH/OU=T-Systems Trust Center/CN=TeleSec Business CA 1
| issuer= /C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2
| notBefore=Nov 29 11:23:55 2012 GMT
| notAfter=Nov 29 23:59:59 2024 GMT
| serial=488D025DD6F4
| t20$
Post by Volker Delf
Post by Marcel Logen
Sie müssen mit "openssl x509 ..." vom DER- in das PEM-Format über-
führt werden.
Die Umwandlung von einer binären CER-Datei in eine Base64-codierten
PEM-Datei kann auch in windows nach Aufruf in den Details erfolgen.
Interessant. Muß ich mir bei Gelegenheit mal ansehen.

Für Windows gibt es ja laut Stefan Kanthak Bordmittel für die Zerti-
fikatsgeschichten:

<https://skanthak.homepage.t-online.de/certificate.html>

(Was ich für Windows noch vermisse, ist ein Pendant zu "openssl
s_client".)

Marcel
--
│ ╭──────────╮ ╭────╮ ╭─╮ ╭───╮ ╭────╮ ╭─────────╯
╰──╯ ╰───────╮ ╭──╮ │ ╭─╯ │ ╰───╯ │ ╰─╮ ╰─────╯
╰─╯ ╰──╯ ╰───╯ ╭─────╯ ╭─╯
╰────────╯ fb7a34
Stefan Claas
2021-10-13 18:34:33 UTC
Permalink
Post by Marcel Logen
(Was ich für Windows noch vermisse, ist ein Pendant zu "openssl
s_client".)
Gibt's doch.

Grüße
Stefan
Marcel Logen
2021-10-13 19:40:49 UTC
Permalink
Post by Stefan Claas
Post by Marcel Logen
(Was ich für Windows noch vermisse, ist ein Pendant zu "openssl
s_client".)
Gibt's doch.
Du sprichst von OpenSSL für Windows? Ja, klar.

Ich meinte ein Windows-Bordmittel. Da ist mir (noch) keines
bekannt, das ähnliche Funktionalität wie s_client aufweist.

Oder übersehe ich da einfach etwas?

(Ich weiß, daß es sftp und AFAIK auch curl in Windows gibt.)

Marcel
--
╭────────╮ ╭─╮ ╭────╮
╭──╯ ╭─╯ ╭─╯ ╰─╮ ╭───╮ ╭──╮ ╭────╯ │
╭───╮ │ ╭──────╯ ╭───╮ │ ╭──╯ ╭─╯ ╰───╯ ╰─╯ ╭─────╯ ╭──╮
─╯ ╰──╯ ╰──────────╯ ╰──╯ ╰─────╯ b11229 ╰───────╯ ╰───
Volker Delf
2024-09-11 16:37:40 UTC
Permalink
Post by Marcel Logen
Die Datei "2021_10CAfile.pem" enthält - jeweils im PEM-Format -
die Zertifikate
- T-TeleSec_GlobalRoot_Class_2.pem
- TeleSec_Business_CA_1.pem
Beide sind bei <https://www.telesec.de/> (dort "Root Programm" wählen)
zu beziehen (unter "Root-Zertifikate" bzw. "Intermediate-Zertifikate").
Die Telekomrechnung vom September 2024 kann nicht mehr mit OpenSSL
verifiziert werdsen. Es kommt die Fehlermeldung:

Verification failure
unable to get local issuer certificate

Die Datei "2021_10CAfile.pem" enthält die Zertifikate:

T-TeleSec GlobalRoot Class 2 (Stammzertifikat)
Gültig bis: Sonntag, 2. Oktober 2033 01:59:59

TeleSec Business CA 1 (Zwischenzertifikat)
Gültig bis: Samstag, 30. November 2024 01:59:59


Ich vermute, dass das Zwischenzertifikat erneuert wurde.
Woher bekommt man dieses Zwischenzertifikat und wie kann man
feststellen,dass das die Ursache ist?


mfg Volker
Marcel Logen
2024-09-11 17:15:42 UTC
Permalink
Post by Volker Delf
Post by Marcel Logen
Beide sind bei <https://www.telesec.de/> (dort "Root Programm" wählen)
zu beziehen (unter "Root-Zertifikate" bzw. "Intermediate-Zertifikate").
Die Telekomrechnung vom September 2024 kann nicht mehr mit OpenSSL
Verification failure
unable to get local issuer certificate
T-TeleSec GlobalRoot Class 2 (Stammzertifikat)
Gültig bis: Sonntag, 2. Oktober 2033 01:59:59
TeleSec Business CA 1 (Zwischenzertifikat)
Gültig bis: Samstag, 30. November 2024 01:59:59
Ich vermute, dass das Zwischenzertifikat erneuert wurde.
Das vermute ich auch.

Ich schaue mir das noch mal an. Zuerst muß ich aber
noch die aktuelle Rechnung (von heute) mit Signatur
aus dem Kundencenter der Telekom herunterladen. Das
geht leider immer noch nur über die 'alte' Ansicht,
und auch dann brauche ich immer zwei Anläufe im Ab-
stand mehrerer Stunden.
Post by Volker Delf
Woher bekommt man dieses Zwischenzertifikat und wie kann man
feststellen,dass das die Ursache ist?
Oben im Zitat ist ein Link "telesec.de". Dort sollte
das Nachfolgezertifikat zu finden sein. Um zu sehen,
welches das genau ist, brauche ich aber zuerst die
Signatur.

Ich melde mich wieder, sobald ich mehr weiß.

Marcel (Lines: 49)
--
╭─────────╮ ╭────╮ ╭─╮ ..58..╭────────
╰────╮ ╭─╯ │ ╭─╯ │ ╰──╮ ╭─╮ ..58..╰───╮
╭─╮ ╭─╯ ╰───╮ │ ╰────╯ ╭─╯ │ │ ╭──╮ ..62..│
──────────────────╯ ╰─╯ ╰─╯ ..39..╰────╯ ╰──╯ ╰─────────╯
Volker Delf
2024-09-12 07:10:01 UTC
Permalink
Post by Marcel Logen
Ich schaue mir das noch mal an. Zuerst muß ich aber
noch die aktuelle Rechnung (von heute) mit Signatur
aus dem Kundencenter der Telekom herunterladen.
Vielen Dank erstmal.

Ich lasse mir die Telekom Festnetz-Rechnung als ZIP-Datei (pdf + pkcs7)
per E-Mail zusenden. Das ist einfacher als im Kundencenter der Telekom
herunterzuladen.

mfg Volker
Marcel Logen
2024-09-12 09:36:31 UTC
Permalink
Post by Volker Delf
Post by Marcel Logen
Ich schaue mir das noch mal an. Zuerst muß ich aber
noch die aktuelle Rechnung (von heute) mit Signatur
aus dem Kundencenter der Telekom herunterladen.
Vielen Dank erstmal.
Wenn ich das richtig sehe, wird jetzt wohl als Zwischen-
zertifikat das

Telekom_Security_BusinessID_SMIME_CA_2023.pem

verwendet.

| $ openssl x509 -in Telekom_Security_BusinessID_SMIME_CA_2023.pem -issuer -subject -dates -noout
| issuer=C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
| subject=C = DE, O = Deutsche Telekom Security GmbH, CN = Telekom Security BusinessID SMIME CA 2023
| notBefore=Jun 20 09:21:45 2023 GMT
| notAfter=Jun 19 23:59:59 2033 GMT

Damit klappt es bei mir bei der September-Rechnung.
Die Gegenprobe mir der August-Rechnung konnte ich
leider noch nicht machen.

Das o. g. Zertifikat gibt es hier:
<https://www.telesec.de/de/root-programm/informationen-zu-ca-zertifikaten/intermediate-zertifikate>
(danach ins PEM-Format umwandeln)

Fingerprint (SHA1):
ed1f89f54b6953f05ee3ee76e53bcdf5a8c0e9bf

Versuche es doch einmal damit.

Marcel (Lines: 42)
--
╭─────╮ ╭─────────────╮ ╭───╮ ╭──╮ ╭──╮ ..67..
╭──╯ ╭──╯ ╰──────────╮ ╰────╮ ╭─╯ │ │ │ │ ╰─╮..67..
╰──╮ ╰────╮ ╭────╮ ╰──╮ ╭─╯ ╭─╯ ╭──╯ │ ╰──╮ ╭─╮ │ ╰─╮ ╭─
╭────╯ ╰──╯ ╰──────╯ ╰───╯ ╰────╯ ╰──╯ ╰───╯..62..╰──╯
Marcel Logen
2024-09-12 10:07:09 UTC
Permalink
Post by Marcel Logen
Damit klappt es bei mir bei der September-Rechnung.
| $ openssl version
| OpenSSL 3.0.14 4 Jun 2024 (Library: OpenSSL 3.0.14 4 Jun 2024)

| $ openssl cms -verify -binary -in 2024_09_rechnung_BKTO_sign_20240911.pkcs7 -content 2024_09_rechnung_BKTO_sign_20240911.pdf -inform der -CAfile Telekom_Security_BusinessID_SMIME_CA_2023.pem -out /dev/null
| CMS Verification successful

Marcel (Lines: 16)
--
╮ ╭───╮ ..37..╭───────────╮ ╭─────────╮
╰─────╮ │ ╰─╮ ╰──╮ ..49..╰─╯ ╭──────╯
╭────╯ ╭─╮ ╭─╮ ╭─╮ ╰─╮ │ ╭─╮ ╭─╮ │ ..54..│ ╭────╮ ╭──
╰───────╯ ╰───╯ ╰─────╯ ╰────╯ ╰─╯ ╰──╯ ╰─╯ ..54..╰─╯ ╰──╯
Marcel Logen
2024-09-12 17:26:57 UTC
Permalink
Post by Marcel Logen
Post by Marcel Logen
Damit klappt es bei mir bei der September-Rechnung.
Die August-Signatur konnte ich leider immer noch nicht aus dem
Kundencenter herunterladen. :-(
Post by Marcel Logen
| $ openssl version
| OpenSSL 3.0.14 4 Jun 2024 (Library: OpenSSL 3.0.14 4 Jun 2024)
| $ openssl cms -verify -binary -in 2024_09_rechnung_BKTO_sign_20240911.pkcs7 -content 2024_09_rechnung_BKTO_sign_20240911.pdf -inform der -CAfile Telekom_Security_BusinessID_SMIME_CA_2023.pem -out /dev/null
| CMS Verification successful
Weitere Befehle zur Verdeutlichung:

| $ cat T-TeleSec_GlobalRoot_Class_2.pem Telekom_Security_BusinessID_SMIME_CA_2023.pem > 202409cafile

| $ openssl cms -verify -binary -in 2024_09_rechnung_BKTO_sign_20240911.pkcs7 -inform DER -content 2024_09_rechnung_BKTO_sign_20240911.pdf -no-CAfile -no-CApath -no-CAstore -out /dev/null -x509_strict -check_ss_sig -CAfile 202409cafile
| CMS Verification successful

| $ openssl verify -verbose -show_chain -no-CAfile -no-CApath Telekom_Security_BusinessID_SMIME_CA_2023.pem
| Telekom_Security_BusinessID_SMIME_CA_2023.pem: OK
| Chain:
| depth=0: C = DE, O = Deutsche Telekom Security GmbH, CN = Telekom Security BusinessID SMIME CA 2023 (untrusted)
| depth=1: C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2

| $ openssl verify -verbose -show_chain -no-CAfile -no-CApath -no-CAstore Telekom_Security_BusinessID_SMIME_CA_2023.pem
| C = DE, O = Deutsche Telekom Security GmbH, CN = Telekom Security BusinessID SMIME CA 2023
| error 20 at 0 depth lookup: unable to get local issuer certificate
| error Telekom_Security_BusinessID_SMIME_CA_2023.pem: verification failed
| $

Marcel
--
Thu Sep 12 19:26:57 2024 CEST (1726162017)
pc-731
87 ikv0 949t
Lines: 40
Volker Delf
2024-09-13 10:13:04 UTC
Permalink
Post by Marcel Logen
Post by Marcel Logen
Damit klappt es bei mir bei der September-Rechnung.
| $ openssl version
| OpenSSL 3.0.14 4 Jun 2024 (Library: OpenSSL 3.0.14 4 Jun 2024)
| $ openssl cms -verify -binary -in 2024_09_rechnung_BKTO_sign_20240911.pkcs7 -content 2024_09_rechnung_BKTO_sign_20240911.pdf -inform der -CAfile Telekom_Security_BusinessID_SMIME_CA_2023.pem -out /dev/null
| CMS Verification successful
Besten Dank für den Link zum Zwischenzertifikat.

Damit klappt die Verification der Telekomrechnung mit OpenSSL auch unter
Windows.

Mich wundert nur, dass in deinem Beispiel für -CAfile nur das
Zwischenzertifikat angegeben ist.

In meiner Datei "2024_09CAfile.pem" sind sowohl das Stammtertifikat als
auch das Zwischenzertifikat enthalten:

T-TeleSec GlobalRoot Class 2
Gültig bis: Sonntag, 2. Oktober 2033 01:59:59

Telekom Security BusinessID SMIME CA 2023
Gültig bis: Montag, 20. Juni 2033 01:59:59

Damit dürfte die Verifikation bis 2033 laufen ;-)

Hier mein Protokoll:
| C:\OpenSSL-Win32\bin>openssl cms -verify -binary -in 2024_09rechnung_BKTO_sign.pkcs7 -content 2024_09rechnung_BKTO_sign.pdf -inform der -CAfile 2024_09CAfile.pem -out Rechnung.pdf
| Verification successful
| C:\OpenSSL-Win32\bin>

mfg Volker
Marcel Logen
2024-09-15 10:28:36 UTC
Permalink
Post by Volker Delf
Besten Dank für den Link zum Zwischenzertifikat.
Damit klappt die Verification der Telekomrechnung mit OpenSSL auch unter
Windows.
Gern. Freut mich.
Post by Volker Delf
Mich wundert nur, dass in deinem Beispiel für -CAfile nur das
Zwischenzertifikat angegeben ist.
Ich hatte ein wenig experimentiert, weil mir nicht klar war, ob nicht
auch der "trust store" (also die Zertifikate, die schon beim Betriebs-
system dabei sind (keine Ahnung, wie das bei Windows ist)) genutzt
wird (für das Root-Zertifikat).

In <news:***@pc-731.ybtra.de> hatte ich dazu einige Befeh-
le ausprobiert (mit einem Linux-System). Um die Zertifikatskette zu
prüfen/verifizieren, hatte ich den OpenSSL-Befehl "verify" benutzt.

Man kann die Nutzung des system-eigenen trust store wohl mit
"-no-CAfile", "-no-CApath" und (neuerdings auch?) mit "-no-CAstore"
abschalten.

<https://docs.openssl.org/master/man1/openssl-cms/>
und
<https://docs.openssl.org/master/man1/openssl-verification-options/#trusted-certificate-options>

Ganz sicher bin ich mir in dieser Angelegenheit aber noch nicht.
Post by Volker Delf
In meiner Datei "2024_09CAfile.pem" sind sowohl das Stammtertifikat als
So war es bei mir bisher auch.

Ich weiß aber nicht, was passiert, wenn dann z. B. das Root-Zer-
tifikat zurückgezogen wird (und möglicherweise aus dem system-
eigenen trust store entfernt würde).
Post by Volker Delf
T-TeleSec GlobalRoot Class 2
Gültig bis: Sonntag, 2. Oktober 2033 01:59:59
Telekom Security BusinessID SMIME CA 2023
Gültig bis: Montag, 20. Juni 2033 01:59:59
Damit dürfte die Verifikation bis 2033 laufen ;-)
Wenn nicht ein Zertifikat zurückgezogen wird.
Oder vielleicht - wie jetzt - ein anderes verwendet wird.
Post by Volker Delf
| C:\OpenSSL-Win32\bin>openssl cms -verify -binary -in 2024_09rechnung_BKTO_sign.pkcs7 -content 2024_09rechnung_BKTO_sign.pdf -inform der -CAfile 2024_09CAfile.pem -out Rechnung.pdf
| Verification successful
| C:\OpenSSL-Win32\bin>
Das "-out" lenke ich immer auf den "Papierkorb" (in Linux "/dev/null")
um, weil mir die Rechnung ja in der Datei "...BKTO_sign.pdf" schon vor-
liegt.

Marcel 6lgo (218648)
--
╭─╮ ╭─╮ ╭──────────╮ ╭──────────╮ ╭─╮
╭──╯ ╰────╯ ╰─╮ ╭─╮ ╰────────╮ ╰──╮ ╰──────╮ ╰──╮ ╭──╯ ╰──╮
│ ╰─╯ ╰──╮ ╭─╮ ╭─╯ ╭─╯ ╭─╮ ╭──╮ ╭─╯ ╰─╯ │ ╭─
│ ╰──╯ ╰─╯ ╰───╯ ╰──╯ ╰───╯ b38d52 ╰─╯
Volker Delf
2024-09-15 12:54:32 UTC
Permalink
Post by Marcel Logen
Ich hatte ein wenig experimentiert, weil mir nicht klar war, ob nicht
auch der "trust store" (also die Zertifikate, die schon beim Betriebs-
system dabei sind (keine Ahnung, wie das bei Windows ist)) genutzt
wird (für das Root-Zertifikat).
Das Stammzertifikat ist bereits im Zertifikatsspeicher von Windows.
Ohne das Stammzertifikat in der Datei "2024_09CAfile.pem" kann mit
meiner alten OpenSSL-Version unter Windows nicht verifiziert werden.
Post by Marcel Logen
Ich weiß aber nicht, was passiert, wenn dann z. B. das Root-Zer-
tifikat zurückgezogen wird (und möglicherweise aus dem system-
eigenen trust store entfernt würde).
Notfalls kann man ja die Signaturdatei (pkcs7) testen, um das aktuelle
Zwischenzertifikat und das zugehörige Stammzertifikat zu ermitteln:

| openssl pkcs7 -in 20XX_XXrechnung_BKTO_sign.pkcs7 -inform DER -noout -print_certs


mfg Volker
Marcel Logen
2024-09-15 17:09:26 UTC
Permalink
Post by Volker Delf
Post by Marcel Logen
Ich hatte ein wenig experimentiert, weil mir nicht klar war, ob nicht
auch der "trust store" (also die Zertifikate, die schon beim Betriebs-
system dabei sind (keine Ahnung, wie das bei Windows ist)) genutzt
wird (für das Root-Zertifikat).
Das Stammzertifikat ist bereits im Zertifikatsspeicher von Windows.
Ah, OK.
Post by Volker Delf
Ohne das Stammzertifikat in der Datei "2024_09CAfile.pem" kann mit
meiner alten OpenSSL-Version unter Windows nicht verifiziert werden.
LibreSSL auf diesem Rechner hier (Betriebssystem: OpenBSD) ver-
hält sich auch so.

Da gab es vermutlich in OpenSSL/3.0 eine kleine Änderung im Ver-
halten.
Post by Volker Delf
Post by Marcel Logen
Ich weiß aber nicht, was passiert, wenn dann z. B. das Root-Zer-
tifikat zurückgezogen wird (und möglicherweise aus dem system-
eigenen trust store entfernt würde).
Notfalls kann man ja die Signaturdatei (pkcs7) testen, um das aktuelle
| openssl pkcs7 -in 20XX_XXrechnung_BKTO_sign.pkcs7 -inform DER -noout -print_certs
Ja, genau. Damit hatte ich herausgefunden, um welches neue Inter-
mediate-Zertifikat es sich handelte.

Mir ist es immer noch nicht (jetzt sind es schon mehrere Tage!)
gelungen, die August-Signatur (Rechnung vom 12.08.2024) aus dem
Telekom-Kundencenter herunterzuladen.

Auf diesem PC hier hatte ich aber schon die August-Rechnung samt
Signatur vorliegen. Läßt sich aber nicht verifizieren.

Ich vermute, das Herunterladen der August-Signatur (und wohl auch
der noch älteren Signaturen) wird nie mehr funktionieren, da sie
- denke ich - 'on the fly' erzeugt werden (sollen), aber das pas-
sende Zertifikat auf den Telekom-Servern nicht mehr vorhanden ist.

Die September-Rechnung konnte ich aber hier mit LibreSSL verifi-
zieren. Juli geht auch (mit der hier lokal vorliegenden Signatur
und dem alten CAfile mit dem alten Zwischen- und dem Root-Zerti-
fikat).

Marcel 722r (231515)
--
╭───────╮ ╭──────────╮ ╭───╮ ╭─╮ ╭──────╮
╰──╮ ╰─╮ ╰──╮ ╭─╯ ╭─╮ ╭─╮ ╭─╮ │ │ │ ╰──╯ ╰──
──╮ ╭────╯ │ ╭─╯ ╭──╯ ╭───╯ ╰─╯ ╰──╯ │ │ ╰─╯
╰──╯ ╰───╯ ╰──────╯ ╰──╯ bfd944
Volker Delf
2024-09-16 12:37:48 UTC
Permalink
Post by Marcel Logen
Auf diesem PC hier hatte ich aber schon die August-Rechnung samt
Signatur vorliegen. Läßt sich aber nicht verifizieren.
Da ich mir die Telekomrechnung zusammen mit der Signatur als ZIP-Datei
per E-Mail zusenden lasse, habe ich mit der August- und
September-Rechnung keine Probleme.

Bedenken bezüglich der Sicherheit der E-Mail Kommunikation habe ich
eigentlich nicht.

OpenSSL verifiziert neben der Signatur auch die Zertifikatskette in der
lokalen Datei "2024_09CAfile.pem". Der Fingerabdruck der beiden
Zertifikate habe ich zuvor mit den im Webportal der Telekom vorliegenden
Angaben verglichen.

mfg Volker

Marcel Logen
2021-10-02 20:56:09 UTC
Permalink
Post by Marcel Logen
Ich benutze hier LibreSSL unter OpenBSD.
Idee: Vielleicht versuche ich es auch einmal mit Linux und OpenSSL.
*done*

Es kommt auch der "nested asn1 error" mit "Type=ECDSA_SIG".

OpenSSL/1.1.1k unter Debian/11

Marcel
--
╭──╮ ╭─────────╮ ╭───╮ ╭────╮ ╭──────╮
╭───╯ ╰─╮ ╰────╮ ╭─╯ ╰─╮ │ ╰──╮ │ │ ╭───╯ ╭───╮
╮ ╰──╮ ╭──╯ ╭───╯ ╰──╮ ╭────╯ │ ╭─╮ ╭────╮ ╭─╯ ╰──╯ │ ╭──╯ │
╰─────╯ ╰──────╯ ╰──╯ ╰─╯ ╰─╯ ╰──╯ ╰───╯2a1105╰
Loading...