Yes, KeyTalk can handle multiple CAs. Both private CAs, such as Microsoft Active Directory Certificate Server, as well as public CAs, such as GMO GlobalSign or DigiCert QuoVadis.
Yes, KeyTalk develops functionality and integrations based on customer demand and the business case. When a required integration is not yet supported and is technically feasible, you can make a successful integration possible together with KeyTalk Business Unit. This integration will then be integrally incorporated into our software and thus also be maintained.
Yes, KeyTalk can generate private keys with sufficient entropy, as part of the centrally generated Certificate Signing Requests (CSRs). These asymmetric key pairs can be stored in its own AES256 encrypted management database or in a linked Hardware Security Module (HSM). As soon as a key pair expires or becomes invalid, the KeyTalk platform will regenerate this key pair and the associated certificate, either automatically or semi-automatically through a workflow process.
Our definition of short-lived X.509 certificates: certificates that do not last longer than the time it takes for a current Certificate Revocation List (CRL) to be updated and distributed from the moment they are issued. Do you normally work with CRLs that are updated once a day? Then, short-lived certificates are valid 24 hours shorter. Online Certificate Status Protocol (OCSP) radiators are theoretically much faster than CRLs to update, but in practice, it usually takes longer than the average time to update a CRL to establish the necessity of including a certificate in an OCSP up to and including the actual inclusion of a certificate in an OCSP. This means that OCSPs are usually no more practical than a CRL when it comes to short-lived X.509 certificates.
KeyTalk can assign any lifespan to a certificate to be issued, as the target Certificate Authority supports this. The shortest validity that KeyTalk can assign to a certificate is 1 second.
A valid digital identity is proven by an X.509 certificate, through several factors:
The validity: Is the certificate on a revocation pointer such as CRL or OCSP? Has the certificate not yet expired in terms of maximum date/time?
Is the CA chain trusted by the computer that wants to validate the digital identity? This requires that the issuing CA Root is trusted, and also the intermediate CAs can be validated or are known and trusted on the computer that wants to validate the digital identity.
Does the name of the digital identity not only appear in the Common Name (CN) of the certificate, but also in the Subject Alternative Name (SAN) of the certificate?
Can the identity requiring validation be used for client authentication, server authentication, or both?
Does the name of the digital identity requiring validation be validated and correspond to a Domain Name Server (DNS) entry? Or does it match the email address being accessed?
Does the digital identity requiring validation have the public X.509 certificate, as well as the corresponding private key?
The KeyTalk system deals with all these factors of digital identity for the issuance and management of certificates. This enables us to prove the identity of a person, mobile device, computer, server, network device, and/or Internet or Things (IoT) device.
No, common server applications such as IIS, Apache, TomCat, NGINX do not require server reboot if the SSL certificate is replaced by the KeyTalk client/app. To put simply, the servers will not go down with these applications and therefore will not interfere with the service.
No, you don’t have to do this. KeyTalk can also handle certificates whose private key is generated on the target system or on an HSM.
Yes, the KeyTalk solution can handle TPMs, as they can be regarded as a Virtual Smart Card (VSC). Most TPMs can be found in Windows systems where VSCs are activated via Microsoft or other software vendors.
In this case, the KeyTalk system will send the Certificate Signing Request (CSR) metadata to the KeyTalk client/app, which in turn, will transfer this CSR data to the TPM/VSC.
The CSR is then generated and passed on via the KeyTalk client/app to the KeyTalk server, leaving the private key safely on the TPM.
The KeyTalk server sends the signed X.509 certificate back to the KeyTalk client/app, which in turn, issues the certificate to the VSC.
Yes, the KeyTalk platform can issue certificates and associated private keys from a linked (Q)TCSP. When you switch to another (Q)TCSP, you will link this new (Q)TCSP to the KeyTalk platform and all the new certificates are issued directly via this new (Q)TCSP.
You can even revoke all certificates issued under the old (Q)TCSP at once, and within the processing time of the Certificate Revocation List (CRL) or Online Certificate Status Protocol (OSCP) automatically replaced by certificates issued under the new (Q)TCSP.
Yes, via the KeyTalk Smart Certificate Security Scanner. You can have the network on all gates scanned for IP, IP-range and Fully Qualified Domain name(s) to identify the used certificates.
If you install the KeyTalk Smart Certificate Security Scanner proxy app you can also perform a deeper scan on any server. This way, you will locate certificates that are not necessarily tied to a TCP port.
Yes, the KeyTalk platform can publish valid S/MIME certificates issued by default in both the Active Directory and Azure Active Directory and (Open)LDAP.
The certificate is stored in the usual AD/LDAP attributes: UserCertificate and AltSecurityIdentities.
Do you wish to use an Enterprise LDAP S/MIME address book / key server for public purposes? This is supplied as a separate virtual server in the KeyTalk platform.
Yes. Although Microsoft often states that this is not possible, this automatic configuration has been possible for years via the KeyTalk client/app. Without further human interaction, with common SHA256 and AES256 settings.
The KeyTalk client/app can automatically set any LDAP address book to Outlook for Windows, even if your LDAP address book uses custom search settings.
Other email clients, assuming they support LDAP address books, can be set up manually based on clear written instructions.
Yes, all KeyTalk virtual appliances of our core solution can run HA. You need a Load Balancer for this. You can also easily set up HA by following our Admin manual step by step.
Yes, the KeyTalk platform supports SNI. On the KeyTalk client/app for each server hosted site, you set the desired certificate template link, authentication and required bind IP, after which the KeyTalk platform will automatically manage each SNI/SSL certificate.
KeyTalk supports the so-called “certificate and private key roll-over”.
To put simply, this means that KeyTalk can reissue a certificate and key to an end user’s device, as long as the authentication is positive. The condition is that the private key can be retrieved somewhere (HSM, own KeyTalk encrypted database, another key management system).
There may be several reasons as to why S/MIME does not work for an end-user. These are the most common:
S/MIME is not set for the email client. The email client must be configured to use S/MIME certificates for digital signing and/or encryption of e-mails to be sent. Validate whether the settings of the email client for using S/MIME are correct.
From the recipient of the encrypted email, no valid and trusted S/MIME certificate is known. Most mail clients use the Active Directory or Azure Active Directory as an address book in which the public S/MIME certificates are published. If a valid and trusted certificate is not in the (Azure) Active Directory, and the mail client does not know the S/MIME certificate of the recipient as a locally stored address book mail address, then it will not be possible to send an encrypted email (but a digitally signed email).
As an extra option, some email clients can also set a so-called “LDAP Key Server” or “LDAP S/MIME address book” to store and search for S/MIME certificates belonging to known email addresses. KeyTalk supplies this LDAP S/MIME address book as part of its KeyTalk solution.
To digitally sign, a hashing algorithm will often have to be set up in the email client. SHA1 is often a standard but has not been trusted by recipients since 2007. Ensure that the set hashing algorithm for digital signing is a ‘modern’ algorithm, such as SHA256. When using an outdated algorithm, the e-mail is often sent, but the recipient will not be able to open the message or receive a warning. In some cases, a received email with an outdated algorithm will be rejected.
To enable the encryption of an email, an encryption algorithm will often have to be set up in the email client. Ensure that the encryption algorithm is a ‘modern’ algorithm, such as AES256. When using an outdated algorithm, the e-mail is often sent, but the recipient will not be able to open the message or receive a warning. In some cases, a received email with an outdated algorithm will be rejected.
Does S/MIME work via an email client on a desktop or laptop, but not on iOS or Android icm Exchange Online or Outlook Web Access (OWA)? Then, additional settings are required. We refer you to this:
