Une PKI tient souvent pendant des années sans que personne y pense, puis une racine arrive en fin de vie ou une clé d'autorité est mise en doute, et tout le parc est concerné. Le poste demande deux qualités rarement réunies : une lecture précise des normes (RFC 5280, politiques de certification selon la RFC 3647) et une discipline d'exploitation, faite de procédures écrites, de quorums et de traces.
Les offres mélangent les titres : ingénieur PKI, expert PKI, architecte PKI. Elles citent ADCS, EJBCA, Keyfactor, des HSM, et, toujours plus souvent, la gestion du cycle de vie des certificats et la préparation post-quantique. Un CV peut aligner ces produits sans que la personne sache lire une chaîne. L'entretien lui fait valider un certificat à voix haute : extensions, chemin, révocation, et ce qu'un client fait réellement quand l'une des étapes échoue.
Le contexte bouge vite. Les certificats TLS publics sont limités à 200 jours depuis le 15 mars 2026, puis 100 jours en mars 2027 et 47 jours en mars 2029. Let's Encrypt a arrêté OCSP en août 2025 et la RFC 9810 a remplacé la RFC 4210 pour CMP. Le PDF contient 30 questions, un cas de 20 minutes et une grille de 1 à 4.
Normes, protocoles et produits qu'un ingénieur PKI utilise
X.509 et RFC 5280
Le format des certificats et les règles de validation d'une chaîne : signatures, dates, contraintes de base, usages de clé, contraintes de noms, politiques. Un ingénieur PKI lit un certificat champ par champ et sait ce qu'un client vérifie, ou oublie de vérifier.
Hiérarchie d'autorités
Une racine hors ligne, une ou plusieurs autorités intermédiaires, des autorités émettrices par usage. Le découpage décide de ce qu'on peut révoquer sans tout casser. Les certifications croisées ajoutent des chemins possibles, et parfois des surprises.
PC et DPC (RFC 3647)
La politique de certification dit ce que la PKI garantit, la déclaration des pratiques dit comment elle l'opère. Ces documents fixent les durées, la validation des demandes, les rôles de confiance, la révocation et la conservation des traces.
HSM et cérémonies de clés
Les clés des autorités sont générées et gardées dans des HSM, avec des cartes d'administration réparties en quorum. La cérémonie suit un script écrit, devant témoins, avec un procès-verbal. Elle se refait pour chaque nouvelle autorité ou opération sur la racine.
Protocoles d'enrôlement : SCEP, EST, ACME, CMP
SCEP (RFC 8894) reste très présent sur les équipements et via les MDM. EST (RFC 7030) s'appuie sur TLS. ACME (RFC 8555), complété par ARI (RFC 9773, juin 2025), automatise les serveurs. CMP, révisé en RFC 9810 en juillet 2025, couvre des cycles de vie complets d'équipements.
Révocation : CRL et OCSP
La CRL liste les certificats révoqués, le répondeur OCSP donne le statut d'un certificat. Let's Encrypt a arrêté OCSP le 6 août 2025 pour revenir aux seules CRL. Le vrai sujet en entretien est le délai entre la révocation et le moment où les clients la prennent en compte.
Produits PKI
Microsoft ADCS dans les environnements Windows, EJBCA de Keyfactor, des services managés comme AWS Private CA, Google Certificate Authority Service ou Microsoft Cloud PKI, et des outils de cycle de vie des certificats. Le poste généraliste demande de comprendre ce que chaque produit fait de la norme.
Règles des navigateurs et du CA/Browser Forum
Pour les certificats TLS publics : durée maximale de 200 jours depuis le 15 mars 2026, 100 jours en 2027, 47 jours en 2029, et des hiérarchies dédiées à l'authentification serveur exigées par le programme de racines de Chrome. Ces règles pèsent aussi sur les choix des PKI internes.
L'ingénieur PKI travaille avec les équipes systèmes, réseau, poste de travail et applications, qui consomment les certificats sans toujours savoir d'où ils viennent. Il rédige ou tient la politique de certification, opère les autorités et leurs HSM, organise les cérémonies et répond aux incidents de certificats. Selon la taille du parc, le poste est tenu par une personne qui couvre aussi le HSM et la gestion du cycle de vie des certificats, ou par une équipe où chacun se spécialise. Un junior se juge sur la lecture des certificats et l'exploitation, un senior sur l'architecture, les cérémonies et la conduite d'un incident ou d'un changement de racine.
Les compétences PKI à vérifier en entretien
- Lecture et validation des certificats X.509
- Architecture et politique de certification
- Cérémonies de clés et HSM
- Protocoles d'enrôlement
- Révocation et statut des certificats
- Incidents et changements de racine
Les questions d'entretien pour juger un ingénieur PKI
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
SCEP, EST, ACME ou CMP : lequel proposez-vous pour des équipements réseau, des serveurs Linux et des postes de travail, et pourquoi ?
Une bonne réponseACME pour les serveurs, avec un client comme Certbot ou acme.sh et l'extension ARI pour renouveler au bon moment. EST ou CMP pour les équipements qui le supportent, avec une authentification forte du demandeur ; SCEP quand c'est la seule option, en limitant le secret partagé. Pour les postes, l'inscription par l'annuaire ou le MDM. Il justifie chaque choix par la capacité du client et la façon de prouver l'identité du demandeur.
Signal d'alerteUn seul protocole pour tout, ou SCEP partout avec un mot de passe de challenge unique.
Question 2 · confirmé
Un certificat est révoqué à 9 h. À partir de quand un client cesse-t-il réellement de lui faire confiance ?
Une bonne réponseCela dépend de la publication de la prochaine CRL, de sa durée de validité et du cache du client, ou de la durée de validité des réponses OCSP et de leur agrafage côté serveur. Beaucoup de clients continuent si le statut est injoignable. Il chiffre ce délai pour sa PKI, et le réduit en publiant plus souvent ou avec des certificats plus courts.
Signal d'alerte« Immédiatement », sans parler de cache, de prochaine publication ni de comportement en cas d'échec.
Question 3 · confirmé
Comment un client valide-t-il une chaîne de certificats, étape par étape ?
Une bonne réponseIl construit un chemin jusqu'à une ancre de confiance, vérifie chaque signature, les dates de validité, que chaque émetteur est bien une autorité (contraintes de base, usage keyCertSign), la longueur de chemin, les contraintes de noms et les politiques, puis les usages étendus et le nom du serveur dans le SAN. Il termine par le statut de révocation. Il sait que tous les clients ne font pas toutes ces étapes de la même façon.
Signal d'alerteUne validation réduite à « la signature est bonne et la date n'est pas passée ».
Question 4 · senior
Faut-il une autorité émettrice par usage (serveurs, postes, équipements réseau, utilisateurs) ? Comment décidez-vous ?
Une bonne réponseIl sépare quand les populations, les risques ou les règles de validation diffèrent : une compromission ou une révocation d'autorité ne doit pas couper tous les usages. Il pèse ce découpage contre le coût d'exploitation, garde la racine hors ligne, fixe des usages étendus et des identifiants de politique par autorité, et documente le tout dans la politique de certification.
Signal d'alerteUne seule autorité pour tout « parce que c'est plus simple », ou une autorité par application sans raison.
Question 5 · senior
Un certificat émis par votre autorité interne apparaît sur un serveur inconnu, et la base de l'autorité n'en garde aucune trace. Que faites-vous ?
Une bonne réponseIl établit d'abord les faits : numéro de série, date, émetteur, recherche dans la base de l'autorité et dans le journal d'audit du HSM, qui trace les opérations de signature. Il distingue une émission légitime mal tracée (autorité de secours, script d'un opérateur) d'une signature faite hors procédure. En attendant, il suspend l'émission et révoque le certificat trouvé. Si la clé a pu signer hors de l'autorité, il la traite comme compromise : révocation depuis la racine en cérémonie, nouvelle autorité, réémission par ordre de criticité. Il tient la chronologie dès la première heure et informe le RSSI.
Signal d'alerteRévoquer le certificat et classer l'affaire sans chercher comment il a été signé, ou tout révoquer avant d'avoir établi les faits et sans plan de réémission.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
PKI : réponses aux questions courantes
Ingénieur PKI généraliste ou spécialiste d'un produit : que chercher ?
Si la PKI repose sur un seul produit, ADCS ou EJBCA par exemple, un spécialiste sera opérationnel plus vite. Pour concevoir, auditer ou faire coexister plusieurs autorités, mieux vaut un généraliste qui raisonne en normes : validation de chaîne, politique de certification, révocation, cérémonies. Un bon généraliste apprend un produit en quelques semaines. L'inverse est plus long, parce que les réflexes de conception ne viennent pas de l'interface d'un outil.
Comment vérifier qu'un candidat a vraiment exploité une PKI ?
Par des faits datés : la dernière cérémonie à laquelle il a participé et son rôle, la fréquence de publication des CRL de sa PKI, le nombre de certificats émis, un incident d'expiration ou de révocation et sa cause. Une personne qui a opéré une PKI répond avec des chiffres et des procédures. Une personne qui l'a seulement vue de loin reste sur les principes et les noms de produits.
Quelle mise en situation donner à un ingénieur PKI ?
Un test technique simple et parlant : la sortie détaillée imprimée de trois certificats d'une chaîne, avec une erreur glissée, comme un usage de clé manquant sur l'intermédiaire, un nom absent du SAN ou des dates incohérentes. La personne valide la chaîne à voix haute. Pour un senior, s'y ajoute la question de ce qu'il faudrait corriger dans le profil et comment réémettre sans coupure.
Un même poste peut-il couvrir PKI et HSM ?
Souvent, oui, quand le parc est modeste : l'ingénieur PKI administre les HSM qui portent les clés de ses autorités et organise les cérémonies. Quand les HSM servent aussi au chiffrement des bases, à la signature de code ou aux clés cloud, le périmètre devient trop large pour une seule personne. La compétence HSM s'évalue alors à part, avec les questions de quorum, de sauvegarde et d'intégration.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
