Questions Fréquemment Posées (FAQ) sur KeyTalk

Oui, KeyTalk peut gérer plusieurs AC. Aussi bien les AC privées, comme Microsoft Active Directory Certificate Server, que les AC publiques, comme GMO GlobalSign ou DigiCert QuoVadis.

Oui, KeyTalk développe des fonctionnalités et des intégrations en fonction de la demande des clients et du cas d’utilisation. Lorsqu’une intégration requise n’est pas encore prise en charge et qu’elle est techniquement faisable, vous pouvez rendre cette intégration possible en collaboration avec la Business Unit de KeyTalk. Cette intégration sera alors incorporée intégralement dans notre logiciel et sera donc également maintenue.

Oui, KeyTalk peut générer des clés privées avec une entropie suffisante, dans le cadre des Demandes de Signature de Certificat (CSR) générées de manière centralisée. Ces paires de clés asymétriques peuvent être stockées dans sa propre base de gestion chiffrée AES256 ou dans un Module de Sécurité Matérielle (HSM) lié. Dès qu’une paire de clés expire ou devient invalide, la plateforme KeyTalk régénérera cette paire de clés et le certificat associé, soit automatiquement, soit semi-automatiquement via un processus de workflow.

Notre définition des certificats X.509 à durée de vie courte : des certificats dont la validité ne dépasse pas le temps nécessaire à la mise à jour et à la distribution d’une Liste de Révocation de Certificats (LRC) actuelle à partir de leur émission. Travaillez-vous habituellement avec des LRC mises à jour quotidiennement ? Dans ce cas, les certificats à durée de vie courte seront valables 24 heures de moins. Les diffuseurs du Protocole de Statut des Certificats en Ligne (OCSP) sont théoriquement plus rapides que les LRC pour les mises à jour, mais en pratique, il faut généralement plus de temps que la durée moyenne de mise à jour d’une LRC pour établir la nécessité d’inclure un certificat dans un OCSP, jusqu’à son inclusion effective. Cela signifie que les OCSP ne sont généralement pas plus pratiques qu’une LRC pour les certificats X.509 à durée de vie courte.

Une identité numérique valide est prouvée par un certificat X.509, à travers plusieurs facteurs :

• La validité : Le certificat figure-t-il sur un pointeur de révocation tel que la LRC ou l’OCSP ? Le certificat n’a-t-il pas encore expiré en termes de date/heure maximale ?
• La chaîne d’AC est-elle approuvée par l’ordinateur qui souhaite valider l’identité numérique ? Cela nécessite que la racine AC émettrice soit approuvée, et que les AC intermédiaires puissent être validées ou soient connues et approuvées sur l’ordinateur qui souhaite valider l’identité numérique.
• Le nom de l’identité numérique apparaît-il non seulement dans le Nom Commun (CN) du certificat, mais aussi dans le Nom Alternatif du Sujet (SAN) du certificat ?
• L’identité nécessitant la validation peut-elle être utilisée pour l’authentification client, l’authentification serveur, ou les deux ?
• Le nom de l’identité numérique nécessitant la validation est-il validé et correspond-il à une entrée du Serveur de Noms de Domaine (DNS) ? Ou correspond-il à l’adresse e-mail accessible ?
• L’identité numérique nécessitant la validation possède-t-elle le certificat X.509 public, ainsi que la clé privée correspondante ?

Le système KeyTalk prend en charge tous ces facteurs d’identité numérique pour l’émission et la gestion des certificats. Cela nous permet de prouver l’identité d’une personne, d’un appareil mobile, d’un ordinateur, d’un serveur, d’un équipement réseau, et/ou d’un appareil Internet ou IoT.

Non, les applications serveur courantes telles que IIS, Apache, TomCat, NGINX ne nécessitent pas de redémarrage du serveur si le certificat SSL est remplacé par le client/app KeyTalk. Pour faire simple, les serveurs ne seront pas arrêtés avec ces applications et cela n’interférera donc pas avec le service.

Non, ce n’est pas obligatoire. KeyTalk peut également gérer des certificats dont la clé privée est générée sur le système cible ou sur un HSM.

Oui, la solution KeyTalk peut gérer les TPM, car ils peuvent être considérés comme une Carte à Puce Virtuelle (Virtual Smart Card, VSC). La plupart des TPM se trouvent dans les systèmes Windows où les VSC sont activés via Microsoft ou d’autres fournisseurs de logiciels.

Dans ce cas, le système KeyTalk envoie les métadonnées de la Demande de Signature de Certificat (CSR) au client/app KeyTalk, qui à son tour transmet ces données CSR au TPM/VSC.

La CSR est alors générée et transmise via le client/app KeyTalk au serveur KeyTalk, laissant la clé privée en toute sécurité sur le TPM.

Le serveur KeyTalk renvoie le certificat X.509 signé au client/app KeyTalk, qui à son tour délivre le certificat à la VSC.

Oui, la plateforme KeyTalk peut émettre des certificats et les clés privées associées à partir d’un (Q)TCSP connecté. Lorsque vous passez à un autre (Q)TCSP, vous liez ce nouveau (Q)TCSP à la plateforme KeyTalk et tous les nouveaux certificats sont émis directement via ce nouveau (Q)TCSP.

Vous pouvez même révoquer en une seule fois tous les certificats émis sous l’ancien (Q)TCSP, et cela dans le délai de traitement de la Liste de Révocation de Certificats (LRC) ou du Protocole de Statut des Certificats en Ligne (OCSP) remplacés automatiquement par des certificats émis sous le nouveau (Q)TCSP.

Oui, via le KeyTalk Smart Certificate Security Scanner. Vous pouvez faire scanner le réseau à toutes les passerelles pour des adresses IP, plages d’IP et noms de domaine pleinement qualifiés (FQDN) afin d’identifier les certificats utilisés.

Si vous installez l’application proxy KeyTalk Smart Certificate Security Scanner, vous pouvez également effectuer une analyse approfondie sur n’importe quel serveur. Ainsi, vous localiserez des certificats qui ne sont pas nécessairement liés à un port TCP.

Oui, la plateforme KeyTalk peut publier par défaut les certificats S/MIME valides dans l’Active Directory, Azure Active Directory et (Open)LDAP.

Le certificat est stocké dans les attributs AD/LDAP usuels : UserCertificate et AltSecurityIdentities.

Souhaitez-vous utiliser un annuaire LDAP d’entreprise S/MIME / serveur de clés à des fins publiques ? Celui-ci est fourni comme serveur virtuel séparé dans la plateforme KeyTalk.

Oui. Bien que Microsoft affirme souvent que ce n’est pas possible, cette configuration automatique est possible depuis plusieurs années via le client/app KeyTalk. Sans intervention humaine supplémentaire, avec des paramètres courants SHA256 et AES256.

Le client/app KeyTalk peut automatiquement configurer n’importe quel annuaire LDAP dans Outlook pour Windows, même si votre annuaire LDAP utilise des paramètres de recherche personnalisés.

D’autres clients mail, à condition qu’ils prennent en charge les annuaires LDAP, peuvent être configurés manuellement à partir d’instructions écrites claires.

Oui, toutes les appliances virtuelles KeyTalk de notre solution principale peuvent fonctionner en HA. Vous aurez besoin d’un équilibreur de charge (Load Balancer) pour cela. Vous pouvez également configurer facilement la HA en suivant notre manuel d’administration étape par étape.

Oui, la plateforme KeyTalk prend en charge le SNI. Sur le client/app KeyTalk, pour chaque site hébergé sur le serveur, vous définissez le lien de modèle de certificat souhaité, l’authentification et l’IP de liaison requise, après quoi la plateforme KeyTalk gérera automatiquement chaque certificat SNI/SSL.

KeyTalk prend en charge ce que l’on appelle le « renouvellement du certificat et de la clé privée ».

Pour faire simple, cela signifie que KeyTalk peut réémettre un certificat et une clé à l’appareil d’un utilisateur final, tant que l’authentification est positive. La condition est que la clé privée puisse être récupérée quelque part (HSM, propre base de données chiffrée KeyTalk, autre système de gestion des clés).

Plusieurs raisons peuvent expliquer pourquoi S/MIME ne fonctionne pas pour un utilisateur final. Voici les causes les plus courantes :

• S/MIME n’est pas configuré dans le client mail. Le client mail doit être configuré pour utiliser les certificats S/MIME pour la signature numérique et/ou le chiffrement des emails à envoyer. Vérifiez que les paramètres du client mail pour l’utilisation de S/MIME sont corrects.
• Du côté du destinataire de l’email chiffré, aucun certificat S/MIME valide et approuvé n’est connu. La plupart des clients mail utilisent l’Active Directory ou Azure Active Directory comme annuaire, où les certificats publics S/MIME sont publiés. Si un certificat valide et approuvé ne figure pas dans l’Active Directory (ou Azure AD), et que le client mail ne connaît pas le certificat S/MIME du destinataire par une entrée locale dans son carnet d’adresses, l’envoi d’un email chiffré sera impossible (mais l’envoi d’un email signé numériquement le sera).

En option, certains clients mail peuvent configurer un « serveur de clés LDAP » ou un « annuaire LDAP S/MIME » pour stocker et rechercher des certificats S/MIME associés aux adresses email connues. KeyTalk fournit cet annuaire LDAP S/MIME avec sa solution KeyTalk.

• Pour la signature numérique, un algorithme de hachage doit souvent être configuré dans le client mail. Le SHA1 est fréquemment utilisé, mais n’est plus fiable depuis 2007 aux yeux des destinataires. Assurez-vous que l’algorithme de hachage choisi est « moderne », par exemple SHA256. Avec un algorithme obsolète, l’email sera souvent envoyé, mais le destinataire ne pourra pas ouvrir le message ou recevra un avertissement. Parfois, un email reçu avec un algorithme obsolète sera rejeté.
• Pour activer le chiffrement d’un email, un algorithme de chiffrement doit souvent être défini dans le client mail. Assurez-vous que cet algorithme est « moderne », comme AES256. Sinon, l’email est souvent envoyé, mais le destinataire ne pourra pas ouvrir le message ou recevra un avertissement, voire le rejetera.
• S/MIME fonctionne-t-il sur un client mail desktop ou laptop, mais pas sur iOS ou Android avec Exchange Online ou Outlook Web Access (OWA) ? Dans ce cas, des réglages supplémentaires sont nécessaires. Nous vous renvoyons vers ces liens officiels Microsoft :
  • 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

Comment configurer Office 365 Exchange Online pour faire confiance à S/MIME et activer le chiffrement et la signature numérique des emails ?

La réponse à cette question est assez technique. KeyTalk a mis à disposition un document qui peut servir de guide pour vous aider à configurer Exchange Online. Ce document est intitulé : “Anything You Ever Wanted To Know About SMIME Email Encryption and Digital Signing Configurations, But Were Afraid To Ask“.