Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Telekom-Rechnung, Signatur pruefen mit "openssl"

193 views
Skip to first unread message

Marcel Logen

unread,
Oct 17, 2020, 1:49:16 PM10/17/20
to
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

unread,
Oct 17, 2020, 2:25:35 PM10/17/20
to
On Saturday, October 17, 2020 at 7:49:16 PM UTC+2, Marcel Logen wrote:
> 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.

[...]

> 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

unread,
Oct 17, 2020, 3:03:32 PM10/17/20
to
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

unread,
Oct 17, 2020, 5:47:20 PM10/17/20
to
Stefan Claas in de.comp.security.misc:

>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

unread,
Oct 17, 2020, 6:20:30 PM10/17/20
to
Marcel Logen wrote:

> Stefan Claas in de.comp.security.misc:
>
> >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.

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.

> 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

unread,
Oct 17, 2020, 6:57:50 PM10/17/20
to
Stefan Claas in de.comp.security.misc:

>Marcel Logen wrote:

>> 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ß.

> 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).

>> 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
--
╮ ╭─╮ ╭───╮ ╭─────╮ ╭──────────╮ ╭──────╮ ╭────╮ ╭────╮
╰──╮ ╭─╯ ╰───╯ │ ╭─────╯ ╭──╯ │ ╰──╯ ╰──╯ ╭─╯ ╰─╮ ╰─
╰─╯ ╭──╯ │ ╭─────╯ ╭─╯ ╭───╯ ╭─╯
╰────╯ ╰────────╯ ╰────────╯

Yamn Remailer

unread,
Oct 19, 2020, 3:09:15 PM10/19/20
to
Christian @Soemtron wrote:

> Marcel Logen <33320000...@ybtra.de> schrieb:
>
> > | 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

unread,
Oct 19, 2020, 4:36:49 PM10/19/20
to
Christian @Soemtron in de.comp.security.misc:

>Marcel Logen <33320000...@ybtra.de> schrieb:

>> | 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

> solange es gängige Open
>Source-Tools gibt, die den Zweck erfüllen.

Gibt es die?

>> 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
--
╭────────╮ ╭────────╮ ╭─────╮ ╭─╮ ╭────╮ ╭───╮
╯ │ ╰──────╮ ╰───╯ ╰─╯ ╰─╯ ╰──────────╯ ╰──╮
╭─╯ ╭─╮ ╭─╮ ╭─╮ ╭──╯ ╰─
╰───╯ ╰───╯ ╰─╯ ╰──╯

Yamn Remailer

unread,
Oct 19, 2020, 5:24:18 PM10/19/20
to
Christian @Soemtron wrote:

> Marcel Logen <33320000...@ybtra.de> schrieb:
>
> > | SecCommerce unter www.seccommerce.de. Die Signaturprüfung
> > | mit dem SecSigner kann direkt online erfolgen.
>
> Finde ich generell wenig erstrebenswert: eigene Dokumente $irgendwohin

Yamn Remailer

unread,
Oct 20, 2020, 5:04:40 PM10/20/20
to
Marcel Logen in de.comp.security.misc:

> Christian @Soemtron in de.comp.security.misc:
>
> >Marcel Logen <33320000...@ybtra.de> schrieb:
>
> >> | 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
>
> > 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

unread,
Oct 22, 2020, 6:52:30 PM10/22/20
to
Yamn Remailer in de.comp.security.misc:

>Marcel Logen in de.comp.security.misc:
>> Christian @Soemtron in de.comp.security.misc:

>> >Finde ich generell wenig erstrebenswert: eigene Dokumente $irgendwohin
>> >hochzuladen. Oder proprietäre Software zu nutzen,
>>
>> ACK
>>
>> > 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

unread,
Oct 22, 2020, 7:06:25 PM10/22/20
to
Marcel Logen in de.comp.security.misc:

[signver]
>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

unread,
Oct 23, 2020, 10:40:15 AM10/23/20
to
Marcel Logen in de.comp.security.misc:

[...]

>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
[...]
>| 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

unread,
Oct 23, 2020, 11:19:05 AM10/23/20
to
Marcel Logen in de.comp.security.misc:

>[...]
>>| 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 ...

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

unread,
Oct 23, 2020, 11:36:51 AM10/23/20
to
Marcel Logen in de.comp.security.misc:

>| 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
--
╭──────╮ ╭───╮ ╭─────────╮ ╭──╮ ╭─────╮ ╭─╮
╭──────────╯ ╭───╯ │ │ │ ╭──────╯ ╭──────╮ │ ╰─╯ ╭──╯ │ │
╯ ╭──────────╯ ╭─╮ │ ╰───╯ ╰─╮ ╰─╮ ╰─╯ ╭────╯ ╭───╯ ╰─╮
╰─────────────╯ ╰──╯ ╰────────╯ ╰──────╯ ╰─╮

Marcel Logen

unread,
Mar 29, 2021, 6:23:45 AM3/29/21
to
Volker Delf in de.comp.security.misc:

>Marcel Logen schrieb:

>>Eine Websuche führte mich zu folgendem Dokument:
>>
>><https://www.telekom.de/hilfe/rechnung/rechnung-erhalten/digital-signierte-rechnung>
>>
>[...]
>>
>>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.
>>
>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.

>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

unread,
Mar 29, 2021, 6:39:38 AM3/29/21
to
Marcel Logen in de.comp.security.misc:

>Volker Delf in de.comp.security.misc:

>>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

unread,
Sep 27, 2021, 5:53:56 PM9/27/21
to
Marcel Logen am 29.03.2021 in de.comp.security.misc:

>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.

[...]

>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

unread,
Sep 28, 2021, 10:38:56 AM9/28/21
to
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

unread,
Sep 28, 2021, 5:57:34 PM9/28/21
to
Stefan Claas in de.comp.security.misc:

>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

unread,
Sep 29, 2021, 5:33:14 AM9/29/21
to
On Tuesday, September 28, 2021 at 11:57:34 PM UTC+2, Marcel Logen wrote:
> Stefan Claas in de.comp.security.misc:
> >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

unread,
Sep 29, 2021, 5:41:16 AM9/29/21
to
On Wednesday, September 29, 2021 at 11:33:14 AM UTC+2, Stefan Claas wrote:

> <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

Eike Rathke

unread,
Sep 29, 2021, 6:47:23 PM9/29/21
to
* Marcel Logen, 2021-09-28 21:57 UTC:
> Stefan Claas in de.comp.security.misc:
>><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

unread,
Sep 30, 2021, 6:40:28 AM9/30/21
to
Eike Rathke in de.comp.security.misc:

>* Marcel Logen, 2021-09-28 21:57 UTC:

>> 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>

>man 1ssl pkcs7
>man 1ssl smime

Ich benutze hier LibreSSL unter OpenBSD.

Idee: Vielleicht versuche ich es auch einmal mit Linux und OpenSSL.

>Zertifikat ausgeben:
>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$

>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.

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 ╰──────────╯ ╰──╯ ╰───────╯ ╰───

Marcel Logen

unread,
Sep 30, 2021, 6:47:44 AM9/30/21
to
Stefan Claas in de.comp.security.misc:
| 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

unread,
Sep 30, 2021, 9:23:50 AM9/30/21
to
On Thursday, September 30, 2021 at 12:47:44 PM UTC+2, Marcel Logen wrote:
> Stefan Claas in de.comp.security.misc:
> >On Wednesday, September 29, 2021 at 11:33:14 AM UTC+2, Stefan Claas wrote:
>
> >> <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

unread,
Sep 30, 2021, 9:53:35 AM9/30/21
to
Stefan Claas in de.comp.security.misc:

>On Thursday, September 30, 2021 at 12:47:44 PM UTC+2, Marcel Logen wrote:

>> 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.)

>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

unread,
Sep 30, 2021, 6:37:53 PM9/30/21
to
* Stefan Claas, 2021-09-30 13:23 UTC:
> 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 Rathke

unread,
Sep 30, 2021, 6:37:53 PM9/30/21
to
* Marcel Logen, 2021-09-30 10:40 UTC:
> Eike Rathke in de.comp.security.misc:
>>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>

Oh, das war mir nicht bekannt, ok, das dreht auf der Stelle im Kreis.


>| 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..


>>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.

> 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:

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?

Marcel Logen

unread,
Sep 30, 2021, 7:28:11 PM9/30/21
to
Eike Rathke in de.comp.security.misc:

>* Marcel Logen, 2021-09-30 10:40 UTC:

>> 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.

>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.

>> 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:
>
>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.

> 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".

>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

unread,
Sep 30, 2021, 7:53:49 PM9/30/21
to
Marcel Logen in de.comp.security.misc:

>Eike Rathke in de.comp.security.misc:

>>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

unread,
Oct 2, 2021, 4:56:10 PM10/2/21
to
Marcel Logen in de.comp.security.misc:

>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╰

Marcel Logen

unread,
Oct 2, 2021, 5:11:09 PM10/2/21
to
Marcel Logen in de.comp.security.misc:

>Stefan Claas in de.comp.security.misc:
>>On Wednesday, September 29, 2021 at 11:33:14 AM UTC+2, Stefan Claas wrote:

>>> <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.
[...]
>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

unread,
Oct 3, 2021, 5:26:03 AM10/3/21
to
On Saturday, October 2, 2021 at 11:11:09 PM UTC+2, Marcel Logen wrote:
> Marcel Logen in de.comp.security.misc:
> >Stefan Claas in de.comp.security.misc:
> >>On Wednesday, September 29, 2021 at 11:33:14 AM UTC+2, Stefan Claas wrote:
>
> >>> <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.
> [...]
> >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

unread,
Oct 3, 2021, 5:36:11 AM10/3/21
to
On Sunday, October 3, 2021 at 11:26:03 AM UTC+2, Stefan Claas wrote:

> 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

Marcel Logen

unread,
Oct 11, 2021, 1:27:45 PM10/11/21
to
Marcel Logen in de.comp.security.misc:

>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$

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.

>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

unread,
Oct 11, 2021, 2:00:22 PM10/11/21
to
Marcel Logen in de.comp.security.misc:

>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$

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

unread,
Oct 11, 2021, 5:51:06 PM10/11/21
to
Marcel Logen in de.comp.security.misc:

>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$

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╰─────╯ ╰────╯

Juergen Ilse

unread,
Oct 13, 2021, 8:34:49 AM10/13/21
to
Hallo,

Volker Delf <nop...@ist.invalid> wrote:
> Marcel Logen schrieb:
>
>>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$
>>
> Meine Anerkennung :-)
>
> Funktioniert auch unter Windows, wenn in eine Dati (dummy.txt)
> umgeleitet wird, deren Inhalt mir nichts sagt.
>>
>>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 (jue...@usenet-verwaltung.de)

Marcel Logen

unread,
Oct 13, 2021, 11:27:31 AM10/13/21
to
Volker Delf in de.comp.security.misc:

>Marcel Logen schrieb:

>>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$
>>
>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.

>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.

>>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=rechnun...@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$

>>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

Marcel Logen

unread,
Oct 13, 2021, 11:37:11 AM10/13/21
to
Juergen Ilse in de.comp.security.misc:

>Volker Delf <nop...@ist.invalid> wrote:
>> Marcel Logen schrieb:

>>>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=rechnun...@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 ╰─╯ ╰────

Stefan Claas

unread,
Oct 13, 2021, 2:34:34 PM10/13/21
to
On Wednesday, October 13, 2021 at 5:27:31 PM UTC+2, Marcel Logen wrote:

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

Gibt's doch.

Grüße
Stefan

Marcel Logen

unread,
Oct 13, 2021, 3:40:50 PM10/13/21
to
Stefan Claas in de.comp.security.misc:
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 ╰───────╯ ╰───
0 new messages