Questions Fréquemment Posées (FAQ) sur KeyTalk
KeyTalk peut-il gérer des certificats provenant de plusieurs autorités de certification (AC) ?
Oui, KeyTalk peut gérer plusieurs autorités de certification. Il peut s’agir d’autorités de certification privées, telles que le serveur de certificats Microsoft Active Directory, ou d’autorités de certification publiques, telles que GMO GlobalSign ou DigiCert QuoVadis.
Je souhaite utiliser une autorité de certification, mais KeyTalk ne semble pas la prendre en charge ! Est-ce possible ?
KeyTalk peut-il gérer des clés cryptographiques asymétriques publiques/privées ?
KeyTalk prend-il en charge les certificats X.509 de courte durée ?
Notre définition des certificats X.509 à courte durée de vie : les certificats qui ne durent pas plus longtemps que le temps nécessaire à la mise à jour et à la distribution d’une liste de révocation de certificats (CRL) à partir du moment où ils ont été émis. Vous travaillez normalement avec des CRL qui sont mises à jour une fois par jour ? Dans ce cas, les certificats à durée de vie courte sont valables 24 heures de moins. Les radiateurs OCSP (Online Certificate Status Protocol) sont théoriquement beaucoup plus rapides à mettre à jour que les CRL, mais dans la pratique, il faut généralement plus de temps que le temps moyen de mise à jour d’une CRL pour établir la nécessité d’inclure un certificat dans un OCSP, jusqu’à l’inclusion effective d’un certificat dans un OCSP. Cela signifie que les OCSP ne sont généralement pas plus pratiques qu’une CRL lorsqu’il s’agit de certificats X.509 de courte durée.
KeyTalk peut attribuer n’importe quelle durée de vie à un certificat à émettre, dans la mesure où l’autorité de certification cible le prend en charge. La durée de validité la plus courte que KeyTalk peut attribuer à un certificat est de 1 seconde.
Les certificats émis via le système de gestion des certificats KeyTalk prouvent-ils l'identité numérique d'une personne ou d'une machine ?
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.
Si un certificat (et la clé privée) émis par KeyTalk est installé par le client/app KeyTalk, faut-il redémarrer mon serveur ?
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.
La plateforme KeyTalk doit-elle toujours créer et gérer la clé privée ?
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.
La solution KeyTalk fonctionne-t-elle avec un Trusted Platform Module (TPM) disponible pour générer/enregistrer une clé privée ?
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.
Le fournisseur de services de certificats (qualifiés) (de confiance) KeyTalk ((Q)TCSP) peut-il fonctionner de manière indépendante ?
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.
KeyTalk peut-il également localiser les certificats dans mon réseau?
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.
La plateforme KeyTalk peut-elle publier mes certificats d’encryption d’email et de signature numérique (S/MIME) émis?
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.
Le chiffrement des emails S/MIME et les certificats pour la signature numérique doivent être configurés dans Outlook pour Windows. KeyTalk peut-il prendre en charge cela ?
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.
Si un certificat de chiffrement d’email S/MIME et un certificat signé numériquement sont publiés dans un annuaire public LDAP, comment peuvent-ils être utilisés avec des clients mail courants ?
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.
Puis-je exécuter la plateforme KeyTalk en Haute Disponibilité (HA) / redondante ?
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.
Mon serveur utilise Server Name Indication (SNI). Est-ce pris en charge par KeyTalk en termes de gestion des certificats et de déploiement/installation automatique ?
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.
Mes utilisateurs disposent de plusieurs appareils pour lire leurs emails. Comment KeyTalk garantit-il que le même certificat S/MIME valide et la même clé privée sont utilisés sur tous ces appareils ?
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 :
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:
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“.
