S/MIME-Zertifikat der deutschen Rentenversicherung

[mabu]

Hallo.

Wir wurden von der Deutschen Rentenversicherung zum Thema "S/MIME-domänenverschlüsselte E-Mails" angeschrieben.

Dabei soll unter https://www.deutsche-rentenversicherung.de/DRV/DE/Service/Footer/CERT/cert.html das aktuell gültige Zertifikat der DRV liegen.

Dies habe ich in den NSP importiert und bekomme "unbekanntes Stammzertifikat" angezeigt. Des weiteren unterstützt es laut Anzeige im Partner cert-drv@drv-bund.de nicht die Verschlüsselung.

Liegt das daran, dass wir kein passendes Stammzertifikat dazu haben oder an was anderem im Zertifikat?

 

[ffischer]

Hallo,
ja hier ist die Kette etwas murks...
Hab das mal geprüft ... nach dem installieren von 3 weiteren klappts.


Eventuell reichen aber auch nur 
DRV_RootCA-2018A
DRV_Root_CA-2018aa

Anhang anzeigen 7

 

[mabu]

Klasse. Vielen Dank dafür.

Mit den beiden genannten sieht es dann auch gut aus.

Evtl. stehe ich gerade etwas auf dem Schlauch: über welchen Weg bist Du an die beiden Root-Zerts rangekommen?

 

[ffischer]

Hallo,
keine Ursache

Habe da so meine Erfahrungen gesammelt.
Das Org. Zert von der Webseite runtergeladen und geöffnet .. eigentlich haben die ja Abhängkeiten also eine Kette aber hier hat ein Zert ein anderes Zert augestellt.
Über das Zertifikat cert_509_SMIME_email_pub.cer konnte ich Eigenschaften prüfen und die Sperrlisten öffnen die warem per LDAP erreichbar.
Im LDAP dann die passenden Zerts exportiert.

Bei Allgemein findet man Ausgestellt für
und Ausgestellt von da war dann das nächste Zertifikat drin. DRV TM CA2018aa und so weiter => das oben aus dem LDAP

Grüße

 

[JanJäschke]

Tolle detektiv Arbeit ffischer =)

Und um so besser das sich das Problem damit erschlagen hat.

Das verhalten wird bei eigenen PKIs wie der der Deutschen Rentenversicherung leider immer so sein.
Um so schlimmer, das solche PKIs ihre komplette Zertifikatskette nicht öffentlich bereitstellen :/


Gruß
Jan

 

[ffischer]

@Jan

gerne . sowas ist nicht nur bei der DRV der fall auch das PKI Bayern hat solche hürden manchmal drin

 

[StefanCink]

Bei solchen Geschichten frage ich mich immer ernsthaft, ob die Architekten einer solchen PKI wissen, dass das P in PKI für "Public" steht......

 

[ffischer]

wohl war.
Ganz schlimm ist wenn man das PKI Adressbuch via LDAP ins Outlook einbinden muss,
dadurch wird Outlook zur schnecke ..

 

[SBW]

Hallo Jan,
Teile der Zertifikate sind selbstverständlich im Trust Center der DRV einseh- und abrufbar:
https://www.deutsche-rentenversicherung.de/Bund/DE/Ueber-uns/Trustcenter/trustcenter_node.html


Gruß,
Daniel

---

Hallo Stefan,
wenn du die Chance hast, dich mit einem IT Architekten der DRV zu reden, sprich ihn auf die Vielzahl von PKIs und deren Zweck an.

Die Idee aus technischer und organisatorischer Sicht ist meiner Meinung nach gar nicht mal so schlecht. Allerdings ist das Konzept der PKI nicht für den primären Einsatzzweck genutzt worden. Für Unternehmen, Behörden und Kunden, welche in unterschiedlichen Art und Weis mit der DRV zusammenarbeiten dürfen und müssen, bedeutet dies regelmäßig Mehraufwand und Nervennahrung.


Gruß,
Daniel

 

[mabu]

Ich muss noch mal dieses Thema aufgreifen.

Für die in meinem Ausgangsthread genannte URL wurde mir auf Nachfrage mitgeteilt, dass es für den gewünschten Zweck die falsche URL war. Schade.

Habe dann eine ZIP-Datei mit drei cer-Dateien erhalten (die hänge ich mir mal an). Habe damit nämlich auch ein Problem.

Die drei importiert (die beiden Root-CA scheinen die zu sein, die hier im Thread schon bereitgestellt worden sind). Und für das Zertifikat, "mit dem Sie die S/MIME-Verschlüsselung für die gesicherte Kommunikation mit unserem Hause aktivieren können." läuft unter VPSMailGateway.

Beigefügt Screenshot, wie es im NSP in der Zertifikatsverwaltung nun aussieht. "Unbekanntes Stammzertifikat" - es sieht für mich von der Kette her aber passend aus.

Somit kann ich im Partner drv-bund.de dieses Zertifikat auch nicht hochstufen (zumindest wird es mit "nicht zum Verschlüsseln" angezeigt).

Was übersehe ich hier?

 

[ffischer]

Hallo Martin,
also war bei mir gleich aber . könnte es lösen.
Ich habe folgendes noch gemacht ..

Im Explorer die Datei 2018a_root_ca.cer öffnen und Installieren,
nicht als Benutzer sondern Lokaler Computer und dann
Alle Zertifikate in folgendem Speicher ablegen => Vertrauenswürdige Stammzertifizierungsstellen

In der NSP Console einfach auf aktualisieren und schon
Anhang anzeigen 2

 

[mabu]

:blush:  heute wird es nun auch als gültig angezeigt.

Zum letzten Vorschlag: das hatte ich gestern vor meiner Frage auch schon getestet. Also auf dem NSP-Intranet-Server das Root-Zert importiert. Wird dort auch unter "vertrauenswürdige Stammzertifizierungsstellen" angezeigt. Aber gestern änderte sich nichts an der Anzeige. Das war das merkwürdige.

info von Net-at-Work in der Vergangenheit war meiner Ansicht nach: "nicht notwendig, die Zertifikate am Windows-Server zu installieren. Aufgrund Begrenzungen im Zertifikatsspeicher kann dies auch irgendwann zu Problemen führen"

Jetzt wird der VPSMailGateway aber als gültig angezeigt. Yippie.

 

[ffischer]

vielleicht äußert sich noch Net at Work dazu
warum das hier so seltsam ist.

Solang es erstmal läuft

 

[StefanCink]

Hallo zusammen,
die Aussage bezüglich des Imports von Stamm- und Zwischenzertifikaten ist auch nach wie vor korrekt. Wenn NoSpamProxy die Kettenprüfung durchführt, übergeben wir alle nötigen Zertifikate der Windows-Prüfroutine. Daher ist der Import in den Windows-Zertspeicher nicht nötig und führt im schlimmsten Fall zu den von ffischer bereits genannten Problemen.
Ich nehme die DRV-Zertifikate mal mit in unsere Testumgebung und halte euch auf dem Laufenden.
Gruß Stefan

 

[StefanCink]

Ich habe die Zertifikate allesamt in meiner Testumgebung auf den Desktop kopiert, über "Zertifikate importieren" en bloc importiert und das Verschlüsselungszertifikat wurde sofort als "Gültig" angezeigt. Anschließend konnte ich es auch zum Domänenzertifikat erfolgreich hochstufen.

Wenn der Status eines Zertifikats mal nicht wie erwartet sein sollte, empfehle ich eine ausgehende E-mail an die Adresse im Zertifikat, so dass es verwendet wird. Bei der Verwendung wird es erneut geprüft. Vielleicht hilft das schon weiter.
Gruß Stefan