30 août 2025
Introduction
Obtenir un certificat de signature numérique commence par une décision d’usage, pas par le téléchargement d’un fichier. L’organisation doit savoir qui signera, au nom de qui, sur quel dispositif et dans quels logiciels les destinataires vérifieront les documents. Sans ces réponses, elle risque d’acheter un certificat reconnu dans son propre environnement, mais inutilisable dans le flux prévu.
Le certificat associe une clé publique à une identité selon les contrôles effectués par son émetteur. La signature est créée avec la clé privée correspondante, qui doit demeurer protégée. Le certificat ne confère pas à lui seul une autorité d’affaires, ne choisit pas le niveau de signature requis et ne rend pas automatiquement tout document exécutoire.
Ce guide aide un gestionnaire de la sécurité à définir le besoin, choisir un fournisseur, préparer la validation d’identité, protéger la clé et encadrer le cycle de vie du certificat avant la première signature.
Définir le titulaire et l’usage du certificat
Précisez d’abord ce que la signature doit représenter. Une personne peut signer en son nom ou dans l’exercice d’une fonction autorisée. Une organisation peut aussi avoir besoin d’un procédé distinct pour appliquer un sceau ou automatiser certaines opérations. Ces cas ne sont pas interchangeables et peuvent exiger des certificats, des clés et des contrôles différents.
Documentez les types de fichiers, les applications de signature, les destinataires habituels, les territoires concernés et le niveau d’assurance attendu. Vérifiez également si une politique interne, un contrat ou une règle applicable impose un fournisseur, un profil de certificat, une méthode d’identification ou un dispositif particulier.
Cette analyse permet de formuler un profil d’achat utile :
- identité qui doit figurer au certificat;
- personne ou service autorisé à utiliser la clé;
- usages et formats de signature visés;
- logiciels et systèmes qui doivent reconnaître la chaîne;
- volume et fréquence des signatures;
- clé locale sur dispositif ou service de signature à distance;
- besoins d’intégration, d’horodatage et de validation à long terme;
- exigences de renouvellement, de révocation et de soutien.
Choisir une autorité de certification ou un fournisseur
Une autorité de certification délivre le certificat et publie les règles qui encadrent son émission et son cycle de vie. Un fournisseur de services de confiance peut offrir, selon son territoire et ses services, la validation d’identité, la gestion de clés, la signature à distance, l’horodatage ou d’autres fonctions connexes.
Le bon fournisseur n’est pas simplement celui dont le site est le plus facile à trouver. Confirmez que son certificat est adapté à l’usage, que sa chaîne sera reconnue dans les environnements des destinataires et que son modèle de clé est compatible avec le flux. Les magasins de confiance varient selon les lecteurs PDF, les systèmes d’exploitation et les applications d’entreprise.
Examinez la documentation de l’émetteur, notamment sa politique de certification et sa déclaration des pratiques de certification lorsqu’elles sont disponibles. Portez attention aux contrôles d’identité, à la protection des clés, aux modalités de révocation, au soutien, à l’exportation des preuves et aux responsabilités du titulaire.
Avant de commander, réalisez un essai ou demandez un exemple de chaîne si le processus est critique. Pour une intégration Nota Sign fondée sur un certificat, confirmez aussi que le fournisseur, la méthode de signature et le format nécessaires sont pris en charge dans la configuration et le territoire visés.
Préparer la validation d’identité et la demande
Les renseignements exigés dépendent du type de certificat et des pratiques de l’émetteur. Une demande individuelle peut nécessiter des pièces d’identité et une vérification en personne ou à distance. Une demande liée à une organisation peut aussi exiger la preuve de son existence, l’autorité du demandeur et la fonction du titulaire.
Préparez uniquement les documents demandés et transmettez-les par le canal sécurisé du fournisseur. Les copies d’identité, coordonnées et preuves d’autorité doivent être protégées selon leur sensibilité et supprimées des emplacements temporaires lorsqu’elles ne sont plus nécessaires.
Dans une infrastructure interne, la demande peut comprendre une requête de signature de certificat contenant la clé publique et les attributs demandés. Dans un service géré, le fournisseur peut orchestrer cette étape sans remettre la clé privée au demandeur. Dans les deux cas, vérifiez les renseignements avant l’émission : une erreur de nom, d’organisation ou d’usage peut imposer une révocation et une nouvelle demande.
Générer et protéger la clé privée
Le niveau de protection doit correspondre au risque et au modèle de service. La clé peut être créée dans une carte, un jeton cryptographique, un module matériel de sécurité ou un service de signature à distance. Dans un processus bien conçu, elle n’est pas envoyée par courriel ni déposée sur un partage réseau.
Le titulaire d’un certificat personnel ne devrait pas partager son authentifiant ou son dispositif. Pour une clé utilisée par un service organisationnel, les contrôles sont différents : accès de service, séparation des rôles, journalisation, approbations et mesures contre l’utilisation non autorisée. Il faut donc éviter la règle simpliste selon laquelle toute clé appartient forcément à une seule personne physique.
La politique devrait préciser :
- où la clé est générée et conservée;
- qui peut en autoriser ou en déclencher l’utilisation;
- si une sauvegarde est permise et comment elle est protégée;
- comment signaler une perte, une compromission ou un départ;
- qui peut demander la révocation;
- quelles traces sont conservées sans exposer de secrets.
Ne consignez jamais la clé privée, son NIP ou un secret de récupération dans l’inventaire des certificats.
Contrôler le certificat émis et tester la signature
À la délivrance, rapprochez le certificat de la demande approuvée. Vérifiez le titulaire, l’organisation s’il y a lieu, l’émetteur, le numéro de série, la période de validité, les usages de clé et la chaîne fournie. Une simple réussite d’installation ne confirme pas que le profil convient au document.
Installez les certificats intermédiaires nécessaires selon les instructions de l’émetteur, sans ajouter arbitrairement une nouvelle racine de confiance. Effectuez ensuite un essai de signature et de validation dans les applications réellement utilisées. Si les destinataires emploient plusieurs environnements, couvrez les plus importants avant de généraliser le certificat.
L’essai devrait montrer l’identité affichée, le contenu signé, le résultat cryptographique, la chaîne, le statut de révocation disponible et l’horodatage prévu. Documentez aussi ce qui se produit lorsqu’un certificat est inconnu ou que la validation échoue; les équipes de soutien auront besoin de cette procédure.
Gérer le renouvellement, la révocation et les preuves
Inscrivez chaque certificat dans un inventaire contrôlé : titulaire ou service, usage autorisé, émetteur, numéro de série, emplacement de la clé, dates de validité, propriétaire opérationnel et procédure de révocation. L’inventaire ne doit contenir aucun secret.
Planifiez le renouvellement assez tôt pour refaire les validations et les essais. Un renouvellement peut produire une nouvelle paire de clés et une nouvelle chaîne; ne supposez pas que tous les systèmes reconnaîtront automatiquement le résultat. Les documents déjà signés doivent rester associés aux anciens certificats et aux preuves permettant d’évaluer leur état au moment pertinent.
Demandez une révocation selon la procédure de l’émetteur lorsqu’une clé est perdue ou soupçonnée d’être compromise, lorsque les renseignements du certificat ne sont plus exacts ou lorsque le titulaire n’est plus autorisé à l’utiliser. Le délai précis dépend du contrat et de la politique applicables, mais l’escalade interne devrait être immédiate lorsqu’un risque de compromission existe.
Après la demande, conservez la référence, la date, le motif autorisé et le statut retourné. La révocation du certificat n’efface pas l’incident : l’organisation doit également déterminer quels documents ou systèmes ont pu être touchés et appliquer ses processus de sécurité.
