KeyTalk häufig gestellte Fragen (FAQ)

Ja, KeyTalk kann mit mehreren CA’s umgehen. Sowohl private CA’s, wie Microsoft Active Directory Certificate Server, als auch öffentliche CA’s, wie GMO GlobalSign oder DigiCert QuoVadis.

Ja, KeyTalk entwickelt Funktionen und Integrationen auf der Grundlage von Kundenanforderungen und des Geschäftsmodells. Wenn eine erforderliche Integration noch nicht unterstützt wird und technisch nicht durchführbar ist, können Sie zusammen mit KeyTalk Business Unit eine erfolgreiche Integration ermöglichen. Diese Integration wird dann integral in unsere Software aufgenommen und somit auch gewartet.

Ja, KeyTalk kann private Schlüssel mit ausreichender Entropie als Teil von zentral generierten Certificate Signing Requests (CSRs) erzeugen. Diese asymmetrischen Schlüsselpaare können in einer eigenen AES256 verschlüsselten Verwaltungsdatenbank oder in einem verknüpften Hardware Security Module (HSM) gespeichert werden. Sobald ein Schlüsselpaar abläuft oder ungültig wird, generiert die KeyTalk Plattform dieses Schlüsselpaar und das zugehörige Zertifikat entweder automatisch oder halbautomatisch über ein Workflow-Prozess neu.

Unsere Definition von kurzlebigen X.509 Zertifikaten: Zertifikate, die ab dem Zeitpunkt der Ausstellung nicht länger gültig sind als die Zeit, die erforderlich ist, um eine aktuelle Zertifikatssperrliste (CRL) zu aktualisieren und zu verteilen. Arbeiten Sie normalerweise mit CRL’s, die einmal am Tag aktualisiert werden? Dann sind kurzlebige Zertifikate 24 Stunden kürzer gültig. Online Certificate Status Protocol (OCSP) Radiatoren sind theoretisch viel schneller als CRL’s zu aktualisieren, jedoch dauert es in der Praxis länger, die Notwendigkeit zu ermitteln, ein Zertifikat in eine OCSP aufzunehmen, bishin zur tatsächlichen Aufnahme eines Zertifikats in ein OCSP, als die durchschnittliche Zeit, um ein CRL zu aktualisieren. Somit sind OCSP’s meistens nicht praktischer als eine CRL, wenn es um kurzlebige X.509 Zertifikate geht.

KeyTalk kann einem auszustellenden Zertifikat eine beliebige Lebensdauer zuweisen, da die Ziel Zertifizierungsstelle dies unterstützt. Die kürzeste Gültigkeitsdauer, die KeyTalk einem Zertifikat zuweisen kann, beträgt 1 Sekunde.

Eine gültige digitale Identität wird anhand eines X.509 Zertifikats, durch eine Anzahl an Faktoren nachgewiesen:

• Die Gültigkeit: Befindet sich das Zertifikat auf einem Widerrufszeiger wie CRL oder OCSP? Ist das Zertifikat hinsichtlich des maximalen Datums/Uhrzeit noch nicht abgelaufen?)
• Wird die CA-Kette anhand des Computers, der die digitale Identiät validieren möchte, als vertrauenswürdig eingestuft? Dies setzt voraus, dass das ausstellende CA Root vertrauenswürdig ist, aber auch, dass die dazwischen liegenden Zwischenzertifizierungsstellen validiert werden können, oder auf dem Computer bekannt und vertrauenswürdig sind, der die digitale Identiät validieren möchte.
• Steht der Name der digitalen Identiät nicht nur im Common Name (CN) des Zertifikats, sondern auch im Subject Alternative Name (SAN) des Zertifikates?
• Kann die zu validierende Identiät für Client-Authentifizierung, Serverauthentifizierung, oder vielleicht beides verwendet werden?
• Entspricht der Name der zu überprüfenden digitalen Identität einem Domain Name Server (DNS) Eintrag? Oder stimmt sie mit der E-Mail-Adresse überein, auf die zugegriffen wird?
• Verfügt die zu validierende digitale Identität nicht nur über das öffentliche X.509 Zertifikat, sondern vor allem auch über den zugehörigen privaten Schlüssel ?

Das KeyTalk-System befasst sich mit all diesen Faktoren der digitalen Identität für die Ausstellung und Verwaltung von Zertifikaten. Damit machen wir es möglich, die Identität von einer Person, eines Mobilgeräts, eines Computers, eines Servers, eines Netzwerkgerätes und/oder eines Internet of Things (IoT) Geräts nachzuweisen.

Nein, gängige Serveranwendungen wie IIS, Apache, TomCat, NGINX erfordern keinen Neustart des Servers, wenn das SSL-Zertifikat durch den KeyTalk Client/ die KeyTalk App ersetzt wird. Kurz gesagt, die Server werden mit diesen Anwendungen nicht ausfallen und somit den Dienst nicht stören.

Nein, das ist sicher nicht notwendig. KeyTalk kann auch Zertifikate verarbeiten, deren privater Schlüssel auf dem Zielsystem oder auf einem HSM generiert wird.

Ja, die KeyTalk Lösung kann mit TPM’s umgehen, da sie als Virtual Smart Card (VSC) verwendet werden können. Die meisten TPM’s sehen wir in Windowssystemen, wo VSC’s über Microsoft oder andere Softwareanbieter aktiviert werden.

Das KeyTalk System sendet in diesem Fall die Certificate Signing Request (CSR) Metadaten an den KeyTalk Client/ die KeyTalk App, der diese CSR Daten an das TPM/VSC weiterleitet.

Die CSR wird dann generiert und über den KeyTalk Client/ die KeyTalk App an den KeyTalk Server weitergeleitet, wobei der private Schlüssel sicher auf dem TPM zurückbleibt.

Der KeyTalk Server versendet das signierte X.509 Zertifikat zurück an den KeyTalk Client/ die KeyTalk App, die das Zertifikat an den VSC ausstellt.

Ja, die KeyTalk Plattform kann Zertifikate und dazugehörige private Schlüssel von einem verknüpften (Q)TCSP ausstellen. Wenn Sie zu einer anderen (Q)TCSP wechseln, verknüpfen Sie diesen neuen (Q)TCSP mit der KeyTalk Plattform und alle neuen Zertifikate werden direkt über diesen neuen (Q)TCSP ausgestellt.

Sie Können sogar alle unter dem alten (Q)TCSP ausgestellten Zertifikate auf einmal widerrufen und innerhalb der Bearbeitungszeit der Zertifikatssperrliste (CRL) oder Online Certificate Status Protocol (OSCP) automatisch durch Zertifikate ersetzen, die unter dem neuen (Q)TCSP ausgestellt werden.

Ja, über den KeyTalk Smart Certificate Security Scanner. Sie können das Netzwerk auf allen Ports nach IP, IP-Bereich und vollständig qualifizierten Domänenamen durchsuchen lassen, um verwendete Zertifikate abzubilden.

Wenn Sie die Proxy-App KeyTalk Smart Certificate Security Scanner installieren, können Sie auch auf jedem Server einen genaueren Scan durchführen. Auf diese Weise können Sie Zertifikate finden, die nicht unbedingt an einen TCP-Port gebunden sind.

Ja, die KeyTalk Plattform kann gültige S/MIME Zertifikate veröffentlichen, die standardmäßig sowohl in Active Directory als auch in Azure Active Directory und (Open)LDAP ausgestellt werden.

Hierbei wird das Zertifikat in den üblichen AD/LDAP Attributen gespeichert: UserCertificate und AltSecurityIdentities.

Möchten Sie für öffentliche Zwecke ein Enterprise LDAP S/MIME Adessbuch / Schlüsselserver verwenden? Dies wird als separater virtueller Server in der KeyTalk Plattform bereitgestellt.

Ja. Obwohl Microsoft häufig angibt, dass dies nicht möglich ist, ist diese automatische Konfiguration schon seit Jahren über den KeyTalk Client/ die KeyTalk App möglich. Ohne weitere menschliche Interaktion, mit aktuellen SHA256 und AES256 Einstellungen.

Der KeyTalk Client/ die KeyTalk App kann jedes LDAP Adressbuch automatisch auf Outlook für Windows einstellen, sogar wenn Ihr LDAP Adressbuch Gebrauch von einer “benutzerdefinierten Sucheinstellung” macht.

Andere E-Mail Clients können, sofern sie die LDAP Adressbücher unterstützen, anhand einer klaren schriftlichen Anweisung manuell eingestellt werden.

Ja, alle virtuellen KeyTalk Appliances unserer Kernlösung können HA ausführen. Dazu benötigen Sie einen Load Balancer. Sie können HA auch einfach einstellen, indem Sie unserem Administrator-Handbuch Schritt für Schritt folgen.

Ja, die KeyTalk Plattform unterstützt SNI. Hiermit stellen Sie auf dem KeyTalk Client/ der KeyTalk App per Server gehostete Site die gewünschte Zertifikatsvorlagen-Link, Authentifizierung und die benötigte Bindungs-IP ein, woraufhin die KeyTalk Plattform jedes SNI/SSL Zertifikat automatisch verwalten soll.

KeyTalk unterstützt so genannte “certificaat en private sleutel roll-over”.

Kurz gesagt bedeutet das, dass KeyTalk ein Zertifikat und einen Schlüssel an ein Gerät von einem Endbenutzer erneut ausstellen kann, solange die Authentifizierung positiv ist. Voraussetzung ist, dass der private Schlüssel irgendwo abgerufen werden kann (HSM, eigene verschlüsselte KeyTalk Datenbank, ein anderes Schlüsselverwaltungssystem).

Es kann mehrere Gründe geben, warum S/MIME für einen Endbenutzer nicht funktioniert. Dies sind die häufigsten:

• S/MIME ist für den E-Mail Client nicht eingestellt. Der E-Mail Client muss so eingestellt sein, um S/MIME Zertifikate für digitale Siganturen und/oder Verschlüsselung der zu versendenden E-Mails zu verwenden. Überprüfe, ob die Einstellungen des E-Mail Clients für die Verwendung von S/MIME korrekt sind.
• Es ist kein gültiges und vertrauenswürdiges S/MIME Zertifikat von dem Empfänger der zu verschlüsselnden E-Mail bekannt. Die meisten E-Mail Clients verwenden das Active Directory oder Azure Active Directory als Adressbuch, in dem auch die öffentlichen S/MIME Zertifikate veröffentlicht werden. Wenn sich kein gültiges und vertrauenswürdiges Zertifikat im (Azure) Active Directory befindet und der E-Mail Client das S/MIME Zertifikat des Empfängers nicht als lokal gespeichertes Adressbuch Mailadresse kennt, dann kann keine verschlüsselte E-Mail versendet werden (sondern eine digital Signierte E-Mail).

Als zusätzliche Option können einige E-Mail Clients auch einen sogenannten “LDAP Key Server” oder “LDAP S/MIME Adressbuch” einrichten, um S/MIME Zertifikate, die zu bekannten E-Mail Adressen gehören, zu speichern und zu suchen. KeyTalk liefert dieses LDAP S/MIME Adressbuch als Teil seiner KeyTalk Lösung.

• Um digital zu signieren, muss oft ein Hashing-Algorithmus im E-Mail Client eingerichtet werden. SHA1 ist oft ein Standard, wird aber seit 2007 von Empfängern nicht mehr als vertrauenswürdig angesehen. Sorg dafür, dass der eingestellte Hashing-Algorithmus für die digitale Signatur ein “moderner” Algorithmus ist, wie zum Beispiel SHA256. Beim Verwenden eines veralteten Algorithmus wird die E-Mail häufig versendet, aber der Empfänger kann die Nachricht nicht öffnen oder eine Warnung erhalten. In einigen Fällen wird eine mit einem veralteten Algorithmus empfangene E-Mail abgelehnt.
• Um die Verschlüsselung von einer E-Mail zu ermöglichen, muss im E-Mail Client häufig ein Verschlüsselungsalgorithmus eingestellt werden. Sorg dafür, dass der eingestellte Verschlüsselungsalgorithmus für die Verschlüsselung ein “moderner” Algorithmus ist, wie zum Beispiel AES256. Beim Verwenden eines veralteten Algorithmus wird die E-Mail häufig versendet, aber der Empfänger kann die Nachricht nicht öffnen oder eine Warnung erhalten. In einigen Fällen wird eine mit einem veralteten Algorithmus empfangene E-Mail abgelehnt.
• Arbeitet S/MIME über ein E-Mail Client auf einem Desktop oder einem Laptop, aber nicht auf iOS oder Android icm Exchange Online oder Outlook Web Access (OWA)? Dann sind zusätzliche Einstellungen erforderlich. Wir verweisen Sie auf:
  • I) https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/outlook-for-ios-and-android/sensitive-labeling-and-protection-outlook-for-ios-android
  • II) https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/s-mime-for-message-signing-and-encryption

Die Antwort auf diese Frage ist ziemlich technisch. KeyTalk hat ein Dokument zur Verfügung gestellt, das als Leitfaden für die Konfiguration von Exchange Online verwendet werden kann. Das Dokument (auf English) finden Sie hier: Alles, was Sie schon immer über SMIME E-Mail-Verschlüsselung und DigitaleSignierenung Konfigurationen wissen wollten, aber Angst hatten zu fragen