"Open Keys" - Zentrale Quelle für SMIME-Zertifikate

Wer Mail "sicher" machen will, sollte E-Mails signieren und verschlüsseln. Allerdings benötigen Sie dazu selbst einen Schlüssel und den öffentlichen Schlüssel der Empfänger. Die erforderlichen Schlüssel können Sie natürlich von der Gegenseite erhalten oder Sie fragen einen der vielen "Keyserver". Aber dazu müssen Sie wissen, auf welchem Keyserver die Informationen liegen. Hier kommt "Open Keys" zum Einsatz, der die verschiedenen Keyserver zusammen bringt.

Transparenz:
Der Service hinter Open Keys wird kostenfrei von Net at Work bereit gestellt, mit der ich verbunden bin. Das Produkt "NoSpamProxy" unterstützt die Open Keys Services.
https://www.e-mail-verschluesselung.de/
https://www.nospamproxy.de/de/initiative-mittelstand-verschluesselt/
https://www.nospamproxy.de/wp-content/uploads/2017-10_PI_MittelstandVerschluesselt.pdf 

Letzter Stand:

Die Vorteile von "Open Keys"

Für die Verschlüsselung von E-Mails benötigen Sie den "öffentlichen Schlüssel" der Empfänger. Der Name "Öffentliche Schlüssel" können Sie mit ""Open Keys"" gleichsetzen. Der "Open Keys"-Service stellt ihnen die zu einer Mailadresse gehörenden Schlüssel bereit, sofern diese hinterlegt sind. "Open Keys" ist aber nicht "noch ein Schlüsselserver" sondern bündelt bekannte Schlüsselserver unter einer Anlaufstelle. Sie können in Outlook oder anderen Programmen eine Suche nach Schlüsseln einbinden und SMIME oder PGP (mit Zertifikaten) nutzen.

Der "Open Keys"-Service besorgt ihnen dann die Zertifikate aus seinem lokalen Speicher, in den jeder Anwender einfach sein Zertifikat hochladen kann. Damit die Vertrauenswürdigkeit gewahrt bleibt, werden aktuell nur Schlüssel von "vertrauenswürdigen Zertifizierungsstellen unterstützt." Damit entfällt auch der Bedarf die Zertifikate zu löschen, da diese dann über die CRL schon ungültig werden und das System kann alleine abgelaufene oder ungültige Zertifikate entfernen.

Zusätzlich unterstützt "Open Keys" weitere vorhandene Schüsselserver, von denen er Schlüssel besorgen und an sie weiter geben kann.

Der große Vorteil für Sie als Anwender aber auch für Hersteller von Verschlüsselungsgateways wie NoSpamProxy u.a. ist damit eine zentrale Anlaufstelle. Sie müssen nur eine Anbindung pflegen.

Erreichbarkeit

Der "Open Keys" Service ist über mehrere Wege erreichbar:

  • Per HTTPS unter https://OpenKeys.de/
    Sie können mit jedem beliebigen Browser nach einem Zertifikat anhand der Mailadresse suchen oder ihr eigenes Zertifikat hochladen
  • Über eine REST-API
    Durch einen einfachen HTTP-Get auf eine URL in der Form "https://api.Open Keys.de/api/certificate/{domain}/{localpart}/ erhalten Sie direkt das Zertifikat.
  • Per LDAP unter ldap://ldap.openKeys.de/
    So können Sie den "Open Keys"-Service einfach in Outlook, Thunderbird u.a. einsetzen

Eine Authentifizierung ist nicht erforderlich und "geheim" sind die dort hinterlegten Daten per Definition nicht. Es sind ja "nur" die öffentlichen Schlüssel. Natürlich gibt es Drosseln, damit Clients den Server nicht exzessiv missbrauchen können oder sogar per "Erraten" die Gültigkeit von Mailadressen prüfen. Die von OpenKey abgefragten Zertifikate werden im eigenen Cache vorgehalten, um die Abfragen an die Key-Server zu minimieren. Zertifikate im Store werden regelmäßig anhand der CRL und dem Ablaufdatum auf ihre Gültigkeit überprüft.

Wer macht schon mit?

"Open Keys" liefert natürlich alle Schlüssel aus, die Benutzer selbst hochgeladen haben. Voraussetzung ist nur, dass die Schlüssel von einer vertrauenswürdigen CA ausgestellt wurden. Aber natürlich können wir darauf warten, dass alle Anwender von Zertifikate den Weg zu "Open Keys" finden. Der individuelle Upload ist also eher etwas für Einzelpersonen, Piloten oder Tests. Probieren Sie es doch einfach aus. Verschiedene Zertifizierungsstellen erlauben ihnen kostenfreie SMIME-Zertifikate anzufordern.

Der Prozess dauert mit einem Browser in der Regel gerade mal wenige Minuten. Sie erhalten per Mail zur Installation des Zertifikats und können es dann in Outlook, per Internet Explorer oder eine MMC für Zertifikate auch als CER-Datei exportieren und hochladen.

Aber es gibt jede Menge LDAP-Server, die heute schon Schlüssel von Firmen bereit stellen. Nur welcher Anwender will all diese Server in seinem Outlook Client einrichten. Aktuell nutzt "Open Keys" folgende Server im Hintergrund um weitere Schlüssel zu erhalten. Da sind durchaus seriöse Namen wie die Bundesdruckerei und SwissSign dabei.

ldap://dir.ebca.de
ldap://directory.d-trust.de
ldap://directory.swisssign.net
ldap://directory.verisign.com
ldap://ldap.fraunhofer.de
ldap://ldap.pca.dfn.de
ldap://ldap.sbca.telesec.de
ldap://ldap.volksverschluesselung.de
ldap://x500.bund.de

Diese Server werden ihnen vermutlich noch nicht viel sagen aber diverse große Firmen, die öffentliche SMIME-Zertifikate nutzen, lassen diese Information durch die entsprechende Zertifizierungsstelle (D-Trust, Swisssign, Verisign, Telesec) veröffentlichen. dazu gehören namhafte Firmen wie Siemens, EON, Bayernwerk, VVK und viele mehr. Eine vollständige Liste aller Mailadressen wäre natürlich ein gefundenes Fressen für Spammer. Aber wenn Sie eine konkrete Mailadresse wissen, dann prüfen Sie diese einfach per Browser auf https://Open Keys.de. Über den KeyServer von EBCA sind Zertifikate für Mailadressen von den Firmen erreichbar, die auf https://www.ebca.de/fileadmin/docs/ebca_filterlist.txt gelistet sind.

Umgekehrt wird es nach und nach immer mehr Produkte geben, die z.B. ihre Schlüssel auch automatisch bei "Open Keys" veröffentlichen können. NoSpamProxy gehört z.B. ebenfalls dazu.

LDAP in Outlook

Sie können es sofort ausprobieren. Sie nutzen z.B. Outlook und addieren in den Konteneinstellungen einfach einen LDAP-Service

Im nächsten Dialog müssen sie einfach nur den Namen des Servers (ldap."Open Keys".de) eintragen. Alle anderen Einstellungen "passen" schon. Eine Anmeldung ist nicht erforderlich und per Default wird der Server auf Port 389 angesprochen.

Wenn Sie in einem Firmennetzwerk oder eine Firewall sind, muss der Port natürlich erreichbar sein. Firmen sind aber in der Regel mit einem entsprechenden Verschlüsselungsgateway besser bedient, so dass die Anwender sich gar nicht erst um die Verschlüsselung und Signierung kümmern müssen. Da die Kommunikation auch ohne SSL möglich ist, sehen Sie in Wireshark schön die Suche:

Outlook sucht also nach dem String in verschiedenen Feldern und addiert immer selbst noch ein "*" am Ende. Wird der Eintrag gefunden, dann wird er auch durch Outlook angezeigt.

REST-API Zugriff

Die Stärke von Open Key ist eine offene API, mit der nicht nur Zertifikate erhalten werden sondern auch bereitgestellt werden können. Neben dem LDAP-Zugriff, für den der anfragende Client natürlich den "Open Keys" Server erreichen muss. (-> Stichwort Firewall, IP-Routing) gibt es eine REST-API. Durch die Verwendung von HTTPS ist dieser Zugriff auch problemlos über Proxy-Server möglich.

Die einfachste Version ist die Eingabe einer Adresse nach dem Schema "https://api."Open Keys".de/api/certificate/<domain>/<localpart>/". Für meine Mailadresse wäre das dann

Sofern es für meine Mailadresse ein Zertifikat gibt, wird "Open Keys" ihnen diese direkt zum Download anbieten. Das ganze geht natürlich auch per PowerShell

Invoke-WebRequest `
   -uri https://api."Open Keys".de/api/certificate/carius.de/frank/ `
   -OutFile c:\temp\fc.cer

Die möglichen Rückgabecodes sind:

  • Exception: no connection
    Prüfen Sie, dass DNS-Auflösungen, Proxy-Einstellungen und Firewalls den Zugriff auf die URL erlauben und sie "online" sind.
  • 200 OK
    Das Zertifikat zur Mailadresse wurde gefunden und wird ausgeliefert
  • 401 ACCESS DENIED
    Der Fehler kommt in der Regel nicht von "Open Keys", da "Open Keys" gar keine Authentifizierung erwartet oder unterstützt. Dieser Fehler kommt meist durch einen HTTP-Proxy zustande, der eine Anmeldung zum Zugriff auf das Internet benötigt.
  • 404 NOT FOUND
    Es wurde kein Zertifikat für die angegebene Mailadresse gefunden
  • 409 Duplicate
    Es ist möglich für eine Mailadresse mehrere Zertifikate hoch zu laden. Dann bekommt man diese Fehler und die Metadaten enthalten beide

    Zertifikate.

  • 429 Throttling
    Sie haben zu viele Anfragen in zu kurzer Zeit gestellt und werden "gedrosselt". Sie sollten mindestens 1 Sekunde Pause zwischen jeder Anfrage einlegen.

Wenn sie als Content-Type ein "application/json" senden, dann erhalten Sie eine JSON-Antwort mit weiteren Informationen. Auch hier wieder ein PowerShell-Beispiel

$smimecert=Invoke-restMethod `
   -uri https://api.openkeys.de/api/certificate/carius.de/frank/ `
   -headers @{"Accept"="application/json"}

$smimecert

name :
emailAddress : frank@carius.de
validFrom    : 2017-10-06T00:00:00+00:00
validTo      : 2018-10-06T23:59:59+00:00
issuer       : COMODO CA Limited
organization :
thumbprint   : 846839AFC17DC5B62CF8F09626F3A9897F4B9377

Über die gleiche API können auch Zertifikate hochgeladen werden. Dazu ist ein PUT mit einer JSON-Payload erforderlich. Die URL zum Hochladen ist PUT https://api.openkeys.de/api/certificate/publish. Der Payload muss dann wie folgt aussehen.

{
   fullName: "Vorname Nachname",
   serializedCertificate: "base64encodedcertificate",
   overwrite: true
}

Mit der Option "overwrite=true" wird ein bestehendes Zertifikat überschrieben, wenn das neu eingereichte Zertifikat gültig ist. Wenn es schon ein Zertifikat gibt und Overwrite nicht gesetzt ist, dann bekommen Sie einen Fehler 429 und in der JSON Antwort finden Sie die Details. Auf jeden Fall wird auf dem "Open Keys"-Service immer nur genau ein Zertifikat pro Mailadresse gespeichert.

Tools

"Open Keys" ist eine pfiffige Lösung um das Handling der Zertifikatsverteilung deutlich zu vereinfachen. Aber mit einigen kleinen Tools und Skripten könnte man für Anwender und Administratoren die Nutzung noch deutlich verbessern. Ich habe hier erst mal meine Ideen gesammelt. Technisch sind alle Tools per PowerShell umsetzbar und ich bin sicher, dass ich früher oder später die entsprechenden Skripte auch hier veröffentlichen kann.

  • Lokal Export
    Wenn ich als "normaler Anwender" ein Zertifikat z.B. von Comodo bekomme, dann ist die Installation recht schnell erfolgt. Die meisten Privatanwender werden aber schon daran scheitern, das gerade erhaltene Zertifikat korrekt zu exportieren und als CER-Datei hochzuladen. Das könnte ein kleines Tool alleine machen, welches lokal alle gültigen Zertifikate liest und per REST-API an den "Open Keys" Service sendet.
  • AD-Export
    In Firmennetzwerken können Anwender direkt aus Outlook den zertifizierten Public Key direkt an ihr Benutzerobjekt im AD senden. Damit können alle anderen Anwender diese Information zum Verschlüsseln nutzen. Genauso könnte ein Skript alle Zertifikate aus dem Active Directory auslesen und zu "Open Keys" exportieren.
  • Personal Kontakt-Updater
    In der Regenrichtung fände ich es durchaus charmant, wenn ein Skript meine Outlook Kontakt durchgeht und zu jeder Mailadresse einmal prüft, ob es zu der Mailadresse bei "Open Keys" ein Zertifikat gibt. Wenn ja, könnte da Skript dieses Zertifikat einfach an den Kontakt addieren.
  • Firmen Kontakt-Updater
    Für viele Postfächer könnte ein Skript z.B. per EWS Impersonation die Kontakte aller Postfächer durchscannen und um die entsprechenden Zertifikate bereichern.

Einschätzung

Ich mag den Ansatz von "Open Keys", dass es eine Anlaufstelle für Zertifikate gibt und eine sehr einfache API besteht. Natürlich muss niemand "Open Keys" nutzen, wenn er denn selbst die verschiedenen per LDAP erreichbaren Keyserver pflegt. Aber alles ist besser als gar keine Zertifikatsverteilung. Es gibt ja verschiedene andere Ansätze z.B. per SMIMEA - Type53 die Zertifikate per DNS zu verteilen. Dazu ist aber DNSSEC erforderlich, damit in der DNS-Antwort das Zertifikat nicht ersetzt wird. Die Pflege der Zertifikate ist hier auch noch eine Herausforderung.

Ich habe vor einigen Jahren schon einen Ansatz auf Zertifikate per HTTP skizziert. Auch ein Keyserver könnte durch die Firma selbst bereit gestellt werden. Es müsste nur einen Standard geben, wie diese Service einfach zu finden ist. Das könnte ja auch ein DNS-Eintrag analog zu SPF und DMARC sein, der als TXT-Record die URL zum Abruf von Zertifikaten veröffentlicht, z.B.

msxfaq.de  TXT  "v=openkeys1 url=https://openkeys.de/api/certificate/%domain%/%localpart%/"

Dann könnten insbesondere Gateways aber auch Clients dezentral oder eben auch wieder auf dem "Open Keys" Service nach Zertifikaten suchen.

Weitere Links