Ja, KeyTalk kan met meerdere CAs overweg. Zowel private CAs, zoals Microsoft Active Directory Certificate Server, als ook publieke CAs, zoals GMO GlobalSign of DigiCert QuoVadis.
Ja, KeyTalk ontwikkelt functionaliteit en integraties op basis van klantvraag en business-case. Wanneer een benodigde integratie nog niet ondersteund wordt en technisch haalbaar is, kun je samen met KeyTalk Business Unit een succesvolle integratie mogelijk maken. Deze integratie zal vervolgens integraal worden opgenomen in onze software en zo ook worden onderhouden.
Ja, KeyTalk kan private sleutels genereren met voldoende entropie, als onderdeel van centraal gegenereerde Certificate Signing Requests (CSRs). Deze asymmetrische sleutelparen kunnen opgeslagen worden in haar eigen AES256 versleutelde beheerdatabase of in een gekoppelde Hardware Security Module (HSM). Zodra een sleutelpaar administratief verloopt of ongeldig wordt, zal het KeyTalk platform dit sleutelpaar en bijbehorend certificaat hergeneren, automatisch danwel semi-automatisch via een workflowproces.
Onze definitie van kortlevende X.509 certificaten: certificaten die vanaf het moment van uitgifte niet langer geldig zijn dan de tijd die een gangbare Certificate Revocation List (CRL) nodig heeft om bijgewerkt en verspreid te worden. Werkt u normaliter met CRLs die eens per dag worden bijgewerkt? Dan zijn kortlevende certificaten 24 uur korter geldig. Online Certificate Status Protocol (OCSP) radiators zijn weliswaar theoretisch veel sneller dan CRLs om te updaten, maar in de praktijk duurt het vaststellen van noodzaak tot opname van een certificaat in een OCSP tot en met het daadwerkelijk opnemen van een certificaat in een OCSP meestal langer dan de gemiddelde tijd om een CRL bij te werken. Daarmee zijn OCSPs meestal niet praktischer dan een CRL als het op kortlevende X.509 certificaten aan komt.
KeyTalk kan elke levensduur toekennen aan een uit te geven certificaat, vermits de doel Certificaat Autoriteit dit ondersteunt. De kortste geldigheid die KeyTalk een certificaat kan toekennen is 1 seconde.
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.
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.
Nee, dit hoeft zeker niet. KeyTalk kan ook overweg met certificaten waarvan de private sleutel op het doelsysteem of op een HSM wordt gegenereerd.
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.
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.
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.
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.
Ja. Hoewel Microsoft veelal stelt 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.
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.
Ja, alle KeyTalk virtuele appliances van onze core oplossing kunnen HA draaien. Hiervoor heb je een Load Balancer nodig. Je kunt HA verder eenvoudig instellen door onze Admin handleiding stap voor stap te volgen.
Ja, het KeyTalk platform ondersteunt SNI. Hierbij stelt u op de KeyTalk client/app per server hosted site de gewenste certificate template koppeling, authenticatie en benodigde bind IP in, waarna het KeyTalk platform elk SNI/SSL certificate automatisch zal beheren.
KeyTalk ondersteunt zogenaamde “certificaat en private sleutel roll-over”.
Kortweg betekent dit dat KeyTalk een certificaat en sleutel opnieuw kan uitgeven aan een device van een eindgebruiker, zolang de authenticatie positief is. Voorwaarde is dat de private sleutel ergens opgehaald kan worden (HSM, eigen KeyTalk versleutelde database, een ander key-management systeem).
Er kunnen meerdere redenen zijn waarom S/MIME niet werkt voor een eindgebruiker. Dit zijn de meest voorkomende:
S/MIME is niet ingesteld voor de email client. De email client moet ingesteld zijn om S/MIME certificaten te kunnen gebruiken voor digitaal signeren en/of versleutelen van te verzenden e-mails. Valideer of de instellingen van de email client voor het gebruik van S/MIME correct zijn.
Van de ontvanger van de te versleutelen email, is geen geldig en vertrouwd S/MIME certificaat bekend. De meeste mail clients maken gebruik van de Active Directory of Azure Active Directory als adresboek waar ook de publieke S/MIME certificaten in staan gepubliceerd. Als een geldig en vertrouwd certificaat niet in de (Azure) Active Directory staat, en de mail client kent het S/MIME certificaat van de ontvanger ook niet als een lokaal opgeslagen adres boek mailadres, dan zal er geen versleutelde email verstuurd kunnen worden (wel een digitaal ondertekende email).
Als extra optie kunnen sommige email clients ook een zogenaamde “LDAP Key Server” of “LDAP S/MIME adres boek” instellen om S/MIME certificaten behorend bij bekende email adressen in op te kunnen slaan en ook in op te zoeken. KeyTalk levert deze LDAP S/MIME adres boek als onderdeel van haar KeyTalk oplossing.
Om digitaal te ondertekenen zal vaak een hashing algoritme ingesteld moeten worden in de email client. SHA1 is vaak een standaard, maar wordt sinds 2007 niet meer vertrouwd door ontvangers. Zorg er voor dat het ingestelde hashing algoritme voor digitaal ondertekenen een ‘modern’ algoritme is, zoals bijvoorbeeld SHA256. Bij gebruik van een verouderd algoritme wordt de e-mail vaak wel verstuurd, maar zal de ontvanger het bericht niet kunnen openen of een waarschuwing krijgen. In sommige gevallen zal een ontvangen e-mail met een verouderd algoritme worden afgewezen.
Om versleuteling van een e-mail mogelijk te maken zal vaak een versleutel algoritme ingesteld moeten worden in de email client. Zorg ervoor dat het ingestelde encryptie algoritme voor versleuteling een ‘modern’ algoritme is, zoals bijvoorbeeld AES256. Bij gebruik van een verouderd algoritme wordt de e-mail vaak wel verstuurd, maar zal de ontvanger het bericht niet kunnen openen of een waarschuwing krijgen. In sommige gevallen zal een ontvangen e-mail met een verouderd algoritme worden afgewezen.
Werkt S/MIME wél via een email client op een desktop of een laptop, maar niet op iOS of Android icm Exchange Online of Outlook Web Access (OWA)? Dan zijn er additionele instellingen nodig. We verwijzen u hiervoor naar:
