KeyTalk Veelgestelde vragen (FAQ)
Kan KeyTalk certificaten van meerdere certificeringsinstanties (CA's) verwerken?
Ja, KeyTalk kan meerdere CA’s aan. Zowel private CA’s, zoals Microsoft Active Directory Certificate Server, als publieke CA’s, zoals GMO GlobalSign of DigiCert QuoVadis.
Ik wil een Certificate Authority gebruiken, maar KeyTalk lijkt dit niet te ondersteunen! Is dit wel mogelijk?
Kan KeyTalk asymmetrische publieke/private cryptosleutels beheren?
Ondersteunt KeyTalk kortstondige X.509-certificaten?
Onze definitie van X.509-certificaten met een korte levensduur: certificaten die niet langer meegaan dan de tijd die nodig is om een huidige Certificate Revocation List (CRL) bij te werken en te verspreiden vanaf het moment dat ze zijn uitgegeven. Werkt u normaal gesproken met CRL’s die één keer per dag worden bijgewerkt? Dan zijn certificaten met een korte levensduur 24 uur korter geldig. Online Certificate Status Protocol (OCSP) radiatoren zijn theoretisch veel sneller te updaten dan CRL’s, maar in de praktijk duurt het meestal langer dan de gemiddelde tijd om een CRL te updaten om de noodzaak van het opnemen van een certificaat in een OCSP vast te stellen tot en met het daadwerkelijk opnemen van een certificaat in een OCSP. Dit betekent dat OCSP’s meestal niet praktischer zijn dan een CRL als het gaat om X.509-certificaten met een korte levensduur.
KeyTalk kan een willekeurige geldigheidsduur toekennen aan een uit te geven certificaat, als de doelcertificaatautoriteit dit ondersteunt. De kortste geldigheid die KeyTalk aan een certificaat kan toekennen is 1 seconde.
Bewijzen certificaten uitgegeven via het KeyTalk Certificaat Management systeem een digitale identiteit van een persoon of machine?
Een geldige digitale identiteit wordt bewezen door een X.509 certificaat, door een aantal factoren:
- De geldigheid: Staat het certificaat op een revocation pointer zoals CRL of OCSP? Is het certificaat nog niet verlopen qua maximale datum/tijd?
- Wordt de CA-keten vertrouwd door de computer die de digitale identiteit wil valideren? Dit vereist dat de uitgevende CA Root vertrouwd wordt, maar ook dat de tussenliggende Intermediate CAs gevalideerd kunnen worden of bekend en vertrouwd zijn op de computer die de digitale identiteit wil valideren.
- Staat de naam van de digitale identiteit niet alleen in de Common Name (CN) van het certificaat, maar ook in de Subject Alternative Name (SAN) van het certificaat?
- Mag de te valideren identiteit gebruikt worden voor client authenticatie, server authenticatie, of wellicht beide?
- Komt de naam van de te valideren digitale identiteit overeen met een Domain Name Server (DNS) entry? Of komt deze overeen met het emailadres dat wordt benaderd?
- Beschikt de te valideren digitale identiteit niet alleen over het publieke X.509 certificaat, maar vooral ook over de bijbehorende private sleutel?
Het KeyTalk systeem houdt zich bezig met al deze factoren van de digitale identiteit voor de uitgifte en beheer van certificaten. Daarmee maken we het mogelijk de identiteit van een persoon, mobiel apparaat, computer, server, netwerkapparaat, en/of Internet of Things (IoT) device te kunnen bewijzen.
Als een door KeyTalk uitgegeven certificaat (en private sleutel) door de KeyTalk client/app wordt geïnstalleerd, moet mijn server dan opnieuw opgestart worden?
Nee, gangbare serverapplicaties zoals IIS, Apache, TomCat, NGINX, vereisen geen reboot van de server als het SSL-certificaat wordt vervangen door de KeyTalk client/app. Kortom, de servers zullen bij deze applicaties niet down gaan en de dienstverlening dus niet verstoren.
Moet het KeyTalk platform altijd de private sleutel maken en beheren?
Nee, dit hoeft zeker niet. KeyTalk kan ook overweg met certificaten waarvan de private sleutel op het doelsysteem of op een HSM wordt gegenereerd.
Kan de KeyTalk oplossing overweg met een beschikbare Trusted Platform Module (TPM) voor het genereren/opslaan van een private sleutel?
Ja de KeyTalk oplossing kan met TPMs overweg, vermits deze aangesproken kunnen worden als een Virtuele Smart Card (VSC). De meeste TPMs zien we in Windowssystemen waar VSCs via Microsoft of andere software vendoren op geactiveerd zijn.
Het KeyTalk systeem zal in dit geval de Certificate Signing Request (CSR) metadata sturen aan de KeyTalk client/app, die deze CSR data doorgeeft aan de TPM/VSC.
De CSR wordt daarna gegenereerd en doorgegeven via de KeyTalk client/app aan de KeyTalk server, waarbij de private sleutel veilig achterblijft op de TPM.
De KeyTalk server stuurt het gesigneerde X.509 certificaat terug naar de KeyTalk client/app, die het certificaat afgeeft aan de VSC.
Kan KeyTalk (Qualified) (Trusted) Certificate Service Provider ((Q)TCSP)-onafhankelijk werken?
Ja, het KeyTalk platform kan certificaten en bijbehorende private sleutels uitgeven van een gekoppelde (Q)TCSP. Wanneer je overstapt naar een andere (Q)TCSP, koppel je deze nieuwe (Q)TCSP in het KeyTalk platform en alle nieuwe certificaten worden direct uitgegeven via deze nieuwe (Q)TCSP.
Je kunt zelfs in één keer alle certificaten uitgegeven onder de oude (Q)TCSP intrekken, en binnen de verwerktijd van de Certificate Revocation List (CRL) of Online Certificate Status Protocol (OSCP) automatisch laten vervangen door certificaten uitgegeven onder de nieuwe (Q)TCSP.
Kan KeyTalk ook de certificaten in mijn netwerk vinden?
Ja, via de KeyTalk Smart Certificate Security Scanner. Je kunt het netwerk op alle poorten laten scannen op IP, IP-range en Fully Qualified Domainname(s) om gebruikte certificaten in kaart te brengen
Als je de KeyTalk Smart Certificate Security Scanner proxy app installeert kun je ook een diepere scan uitvoeren op elke server. Zo vind je certificaten die niet-noodzakelijkerwijs aan een TCP port zijn gebonden.
Kan het KeyTalk platform mijn uitgegeven emailencryptie en digitale handtekening (S/MIME) certificaten publiceren?
Ja, het KeyTalk platform kan standaard uitgegeven geldige S/MIME certificaten publiceren in zowel Active Directory als Azure Active Directory en (Open)LDAP.
Hierbij wordt het certificaat in de gangbare AD/LDAP attributen opgeslagen: UserCertificate en AltSecurityIdentities.
Wil je voor publieke doeleinden een Enterprise LDAP S/MIME adresboek / key server inzetten? Dit wordt als separate virtuele server meegeleverd in het KeyTalk platform.
S/MIME email encryptie en certificaten voor digitale ondertekening moeten op Outlook voor Windows geconfigureerd worden. Kan KeyTalk hierin ondersteunen?
Ja. Hoewel Microsoft vaak aangeeft dat dit niet mogelijk is, is deze automatische configuratie al jaren mogelijk via de KeyTalk-client/app. Zonder verdere menselijke interactie, met gangbare SHA256- en AES256-instellingen.
Als een S/MIME mail encryptie en digitaal onderteken certificaat in een publiek LDAP adres boek wordt gepubliceerd, hoe kan deze dan worden gebruikt met gangbare email clients?
De KeyTalk client/app kan elk LDAP adresboek automatisch instellen op Outlook voor Windows, zelfs als uw LDAP adresboek gebruik maakt van een “custom search” instelling.
Andere email clients kunnen, ervan uitgaande dat ze LDAP adres boeken ondersteunen, handmatig worden ingesteld op basis van een heldere schriftelijke instructie.
Kan ik het KeyTalk platform High Available (HA) / redundant draaien?
Ja, alle KeyTalk virtuele apparaten van onze kernoplossing kunnen HA draaien. Hiervoor heb je een Load Balancer nodig. Je kunt HA ook eenvoudig instellen door stap voor stap onze beheerhandleiding te volgen.
Mijn server draait Server Name Indication (SNI). Wordt dit door KeyTalk ondersteunt qua certificaatbeheer en automatische uitrol/installatie?
Ja, het KeyTalk-platform ondersteunt SNI. Op de KeyTalk client/app voor elke server hosted site stel je de gewenste certificaatsjabloonkoppeling, authenticatie en vereiste bind-IP in, waarna het KeyTalk-platform automatisch elk SNI/SSL-certificaat beheert.
Mijn gebruikers hebben meerdere apparaten waar ze e-mail op lezen. Hoe zorgt KeyTalk ervoor dat hetzelfde geldige S/MIME certificaat en private sleutel op alle apparaten van deze gebruikers terecht komt?
KeyTalk ondersteunt de zogenaamde “certificaat en private sleutel roll-over”.
Eenvoudig gezegd betekent dit dat KeyTalk een certificaat en sleutel opnieuw kan uitgeven aan het apparaat van een eindgebruiker, zolang de authenticatie positief is. De voorwaarde is dat de privésleutel ergens kan worden opgehaald (HSM, eigen versleutelde KeyTalk-database, een ander sleutelbeheersysteem).
KeyTalk geeft geldige S/MIME certificaten uit aan mijn eindgebruikers, maar S/MIME werkt niet in mijn omgeving. Hoe komt dat?
Er kunnen verschillende redenen zijn waarom S/MIME niet werkt voor een eindgebruiker. Dit zijn de meest voorkomende:
- S/MIME is niet ingesteld voor de e-mailclient. De e-mailclient moet geconfigureerd zijn om S/MIME-certificaten te gebruiken voor digitale ondertekening en/of versleuteling van te verzenden e-mails. Controleer of de instellingen van de e-mailclient voor het gebruik van S/MIME correct zijn.
- Van de ontvanger van de versleutelde e-mail is geen geldig en vertrouwd S/MIME-certificaat bekend. De meeste mailclients gebruiken de Active Directory of Azure Active Directory als adresboek waarin de openbare S/MIME-certificaten worden gepubliceerd. Als er geen geldig en vertrouwd certificaat in de (Azure) Active Directory staat, en de mailclient kent het S/MIME-certificaat van de ontvanger niet als een lokaal opgeslagen mailadres in het adresboek, dan is het niet mogelijk om een versleutelde e-mail te versturen (maar wel een digitaal ondertekende e-mail).
Als extra optie kunnen sommige e-mailclients ook een zogenaamde “LDAP Key Server” of “LDAP S/MIME-adresboek” instellen voor het opslaan en zoeken naar S/MIME-certificaten die bij bekende e-mailadressen horen. KeyTalk levert dit LDAP S/MIME-adresboek als onderdeel van de KeyTalk-oplossing.
- Om digitaal te ondertekenen moet vaak een hashing-algoritme worden ingesteld in de e-mailclient. SHA1 is vaak een standaard, maar wordt sinds 2007 niet meer vertrouwd door ontvangers. Zorg ervoor dat het ingestelde hashing-algoritme voor digitaal ondertekenen een ‘modern’ algoritme is, zoals SHA256. Als je een verouderd algoritme gebruikt, wordt de e-mail vaak wel verzonden, maar kan de ontvanger het bericht niet openen of krijgt hij geen waarschuwing. In sommige gevallen wordt een ontvangen e-mail met een verouderd algoritme geweigerd.
- Om de versleuteling van een e-mail mogelijk te maken, moet vaak een versleutelingsalgoritme worden ingesteld in de e-mailclient. Zorg ervoor dat het versleutelingsalgoritme een ‘modern’ algoritme is, zoals AES256. Bij gebruik van een verouderd algoritme wordt de e-mail vaak wel verzonden, maar kan de ontvanger het bericht niet openen of een waarschuwing ontvangen. In sommige gevallen wordt een ontvangen e-mail met een verouderd algoritme geweigerd.
- Werkt S/MIME wel via een e-mailclient op een desktop of laptop, maar niet op iOS of Android icm Exchange Online of Outlook Web Access (OWA)? Dan zijn er extra instellingen nodig. We verwijzen je hiernaar:
Hoe kan ik Office 365 Exchange Online configureren voor het gebruik van S/MIME digitale email handtekeningen en encryptie?
Het antwoord op deze vraag is vrij technisch. KeyTalk heeft een document beschikbaar gesteld dat gebruikt kan worden als leidraad bij het configureren van Exchange Online. Het document is hier te vinden: Alles wat je ooit wilde weten over SMIME Email Encryption en Digital Signing configuraties, maar niet durfde te vragen.
