News according to KeyTalk

Microsoft Certificate Services & MDM Support


KeyTalk’s ongoing feature development: Microsoft Certificate Services support

 Many companies already have Microsoft AD CS.

Thus far KeyTalk supported a private PKI under MS AD CS by means of the CA-tree being generated under the root of the existing Microsoft CS CA.

 KeyTalk now not only supports a KeyTalk private CA, but also allows certificate signing requests (network domain-independent) directly against a customer’s Microsoft CS CA using Microsoft’s native available Network Device Enrollment Service (NDES)

So should your company have multiple network domains with multiple Microsoft CS CAs you can control certificate requests and enrollment for all of them with the KeyTalk solution.


 KeyTalk’s ongoing feature development: MDM support

 MDM solutions are often widely implemented in larger companies. So these companies already have a way to push apps and remote install certificates.

However these MDM solutions needs to be populated with certificates and key-pairs before they can distribute them to the end-points under their control


By integrating popular MDM solution APIs into KeyTalk, these customers can easily live fetch certificates and keys from any KeyTalk supported CA-source (such as internal private Microsoft CS CA) for distribution to your MDM controlled end-points.




Read More →
23 May 2018 Comment

I-o-T Server and clientless Network equipment support: SSH SCEP CMPv2 EST


KeyTalk’s ongoing feature development: I-o-T  Server and clientless Network equipment support: SSH SCEP CMPv2 EST


KeyTalk traditionally relies on a client component which communicates using a REST-API over TLS.

While the use of this REST-API fits with most customer environments, our partners and existing customers have continued to ask us to expand our product compatibility beyond the traditionally supported devices preferably clientless.


Clientless works best if there is no active human interaction required, ie devices such as network equipment, servers and IoT devices.

Of course all taking into account available and widely adopted standards


KeyTalk has started the development of support for SCEP (Simple Certificate Enrollment Protocol) and its modern counterpart EST as well as CMPv2

Devices which support these standards can natively and without any client need, securely connect over a KeyTalk network proxy, which in turn uses the secure REST-API over TLS connection to the KeyTalk solution.

This way older standards such as SCEP can still be offered securely.


Last but not least SSH support has been placed on our roadmap.

Any device which allows for an SSH connection can have it’s SSH account details optionally managed, whereby KeyTalk can change the SSH account credentials periodically (and keeps a historic track record).

Based on this SSH connection KeyTalk can additionally launch an Open Source script (under full control of the Admin) to replace the device’s client/server-certificate and key-pair when needed.




Read More →
08 May 2018 Comment

Seamless S/MIME support for easy to use email encryption


KeyTalk’s ongoing feature development: LDAP product and LDAP & AD support for S/MIME email address book  

 When it comes to email encryption, most companies choose S/MIME certificate based email encryption.

In order to use S/MIME based email encryption, you yourself must not only have a valid trusted certificate and key-pair, but you must also have the public key of the certificate of the recipient(s) you wish to send an encrypted email to.

But how do you obtain the most recent public certificate details of someone?

Sure you can have the recipient(s) mail you a digitally signed email and that works just fine, but this is not a sustainable model when you need to send encrypted email to potentially hundreds if not thousands of people whose certificate all expire on a different date. 

 KeyTalk by default supports the writing of S/MIME details to a used LDAP or Active Directory ensuring that your staff have directly access to the most up-to-date public certificate details within your organization.

Additionally KeyTalk can optionally write these same certificate and email address details (so public information only) to an external LDAP solution.

The external LDAP can then function as a public email address-book, which can easily be configured in commonly used email clients such as Outlook, Thunderbird and Evolution.

 If you are unfamiliar with setting up your own LDAP for public address-book purposes, KeyTalk can even provide an out-of-the-box OpenLDAP based solution without additional licensing cost.


 KeyTalk’s e-mail client automated configuration

 Most Operating Systems have a default location to install an email encryption certificate and key-pair which KeyTalk does in a seamless manner within the constraints of the Operating System.

However that typically does not suffice to enable the user to actually make use of the S/MIME certificate.

Applications often need to be configured to make use of such an S/MIME certificate.

 KeyTalk development is focused on tearing down this last hurdle to provide your end-user a proper seamless experience.

No matter the CA-source of your S/MIME certificate, KeyTalk will verify if it meets all S/MIME requirements, check if the account actually exists in commonly used email clients and configure the email client for email encryption usage.

Support initially focusses on Windows with Outlook, Mac with Mail and Outlook, and Linux with Thunderbird and Evolution.

When an external LDAP based email address-book is used to publish the public certificate details KeyTalk will even configure that LDAP server address as an address-book for these email clients.


Read More →
24 April 2018 Comment

KeyTalk’s ongoing feature development


KeyTalk’s ongoing feature development: Historic key-roll-over, key-escrow, supporting S/MIME, Bitlocker and other applications. 

 When you want to encrypt data using certificates and their accompanying a-symmetric key-pairs, it’s highly likely you will want to be able to re-enroll these certificates and key-pairs in a secure manner.

Reasons for this need often entails:

  • a user having multiple devices and thus having a need to use the same certificate and key-pair on each device to properly make use of email encryption (S/MIME)
  • a company enforcing bitlocker encryption and having a need to access the user specific backdoor certificate based key to each uniquely encrypted corporate drive, in order to be able to decrypt the corporate drive when the legal need arises
  • custom applications requiring the originally issued seed certificate and key to derive the applicable encryption key across multiple devices for the same user


Using KeyTalk’s key-roll over will be enabled in 3 different modes for each user-group defined within the KeyTalk solution:

  • AES 256 bit encrypted, with a function allowing the Admin to make use of a 4-eye principle authorization, triggering AES decryption for that particular private-key during a small windows of opportunity
  • Client side PFX encrypted, using a user’s unique set passphrase, unknown to the KeyTalk system, and additionally stored in KeyTalk’s key-roll over database in AES 256 format
  • Delegated to one or more target (external) third party key-roll over systems


KeyTalk can even store your historic issued certificates and keys following the above described principles.

As a result, key-roll-over and key-escrow become a secure reality. Providing the company much needed core-functionality, alleviating it’s IT support desk while still complying with eIDAS requirement and GDPR legislation.


Read More →
30 March 2018 Comment

Popular blogs

I wanna be first to know...

"The News according to KeyTalk" is a blog about IT security solutions such as strong authentication and secure data-in-motion protection. We'll blog about short lived certficates, PKI, Internet of Things and more.