EJBCA est la PKI open source de Keyfactor, déclinée en édition Community et en édition Enterprise, en logiciel, en appliance, en conteneur ou en SaaS. L'ingénieur PKI EJBCA la configure et l'exploite : autorités, profils, crypto tokens sur HSM, protocoles d'enrôlement, publication des CRL et OCSP. Les questions d'entretien d'un ingénieur PKI sur cette plateforme portent souvent aussi sur Keyfactor Command, l'outil de gestion du cycle de vie qui inventorie et renouvelle les certificats de toutes les autorités.
On le croise dans des contextes variés : PKI d'entreprise hors écosystème Microsoft, certificats d'objets connectés ou d'équipements industriels, PKI de prestataires de services de confiance, et automatisation pour Kubernetes et les chaînes CI/CD. Les CV citent EJBCA dès qu'une personne a ouvert l'interface. Le bon profil cite la version, l'édition, le HSM, les protocoles en production, et qui a écrit la politique de certification.
Un détail aide à situer l'expérience : depuis EJBCA 9.6.2, l'usage d'un HSM demande l'édition Enterprise. Un candidat qui a tenu une PKI de production sur HSM connaît donc l'édition payante et ses fonctions de séparation, comme les peers. Le PDF propose 30 questions réparties sur six axes, un cas pratique et une grille.
EJBCA, Keyfactor Command et l'environnement technique du poste
EJBCA
La plateforme d'autorité de certification de Keyfactor, écrite en Java. Elle héberge une ou plusieurs autorités, émet, révoque et publie. La version 9.7 date de septembre 2026. L'édition Community est gratuite, l'édition Enterprise ajoute le support, l'usage des HSM et des fonctions de haute disponibilité et de séparation.
Profils de certificat et d'entité finale
Le profil de certificat fixe le contenu du certificat (algorithmes, durée, usages, extensions). Le profil d'entité finale fixe ce que le demandeur peut demander (champs du nom, SAN, autorités autorisées). La qualité d'une PKI EJBCA se lit dans ces deux catalogues.
Crypto tokens et HSM
Les clés des autorités sont rangées dans des crypto tokens, logiciels ou reliés en PKCS#11 à un HSM (Thales Luna, Entrust nShield, Utimaco, Securosys). La génération des clés d'une racine se fait en cérémonie, avec témoins et procès-verbal.
Protocoles d'enrôlement et API REST
EJBCA accepte ACME, SCEP, EST, CMP et une API REST. Chaque protocole se règle par alias, rattaché à des profils. Le choix dépend de ce que parlent les clients : ACME pour les serveurs, SCEP pour les MDM, CMP pour certains équipements industriels, REST pour les chaînes de déploiement.
RA, VA et peers
Dans une architecture solide, l'autorité ne reçoit aucune connexion entrante. Les autorités d'enregistrement (RA) et les répondeurs de validation (VA) tournent sur des instances séparées, et l'autorité va les chercher par une connexion sortante (peers, édition Enterprise).
Keyfactor Command
La plateforme de gestion du cycle de vie des certificats de Keyfactor. Elle découvre les certificats sur le réseau, tient l'inventaire toutes autorités confondues, alerte sur les échéances et installe les certificats renouvelés sur les serveurs par des orchestrateurs. Elle existe en version hébergée par l'entreprise ou en SaaS.
Conteneurs, Kubernetes et cert-manager
EJBCA se déploie en conteneur avec un chart Helm officiel. Côté clients, cert-manager obtient des certificats pour les clusters Kubernetes auprès d'EJBCA par ACME ou par un émetteur fourni par Keyfactor.
Bases de données et supervision
La configuration et les certificats sont stockés dans une base (MariaDB, PostgreSQL, Oracle ou SQL Server). La supervision porte sur l'état des crypto tokens, les échéances des CRL et des certificats d'infrastructure, et la file de publication.
Les offres EJBCA viennent de PKI d'entreprise construites hors de l'écosystème Microsoft, de projets d'objets connectés, de prestataires de services de confiance et d'équipes plateforme qui automatisent les certificats. Elles associent souvent EJBCA à HashiCorp Vault ou OpenBao pour les secrets, à des HSM, à Kubernetes et à Keyfactor Command, et des rôles d'AMOA ou de chef de projet PKI apparaissent sur Command seul. L'expérience réelle se vérifie sur l'édition utilisée, le HSM, les protocoles en production et la participation à une cérémonie de clés.
Compétences d'un ingénieur PKI EJBCA à contrôler
- Profils EJBCA et règles d'émission
- HSM et cérémonies de clés
- ACME, SCEP, EST, CMP et API REST
- Architecture RA, VA et haute disponibilité
- Cycle de vie avec Keyfactor Command
- Montées de version et audit
Les questions d'entretien d'un ingénieur PKI EJBCA
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 · junior à confirmé
Dans EJBCA, quelle différence faites-vous entre un profil de certificat et un profil d'entité finale ? Donnez un exemple où vous modifiez l'un sans toucher l'autre.
Une bonne réponseLe profil de certificat décrit ce que contient le certificat : algorithmes et tailles de clé acceptés, durée, usages, extensions. Le profil d'entité finale décrit le demandeur : champs du DN et du SAN autorisés ou obligatoires, valeurs par défaut, autorités et profils de certificat utilisables. Exemple attendu : imposer un domaine dans le SAN des serveurs web touche le profil d'entité finale, passer la durée de 398 à 200 jours touche le profil de certificat.
Signal d'alerteLes confondre, ou décrire un seul « template » à la manière d'ADCS sans voir qu'EJBCA sépare le contenu du certificat et les règles sur le demandeur.
Question 2 · confirmé
Comment reliez-vous EJBCA à un HSM, et que se passe-t-il pour les clés de l'autorité quand le HSM redémarre ?
Une bonne réponsePar un crypto token PKCS#11 qui pointe vers la bibliothèque du constructeur et un slot ou une partition, avec les clés de signature de l'autorité et de test référencées par alias. Selon la configuration, le token se réactive seul ou attend un code saisi par un opérateur. Il cite la haute disponibilité côté HSM (Thales Luna, Entrust nShield, Utimaco, Securosys) et le contrôle d'état d'EJBCA qui signale un token hors ligne. Il sait que depuis la version 9.6.2, l'usage d'un HSM dans EJBCA demande l'édition Enterprise.
Signal d'alerteDes clés d'autorité en crypto token logiciel en production sans le justifier, ou aucune idée de la réactivation après coupure.
Question 3 · confirmé
Une chaîne CI/CD doit obtenir des certificats de votre EJBCA sans intervention humaine. Quel protocole ou quelle API choisissez-vous, et comment l'authentifiez-vous ?
Une bonne réponseL'API REST avec un certificat client propre à la chaîne et un rôle limité à un profil d'entité finale, ou ACME si les outils de la chaîne le parlent déjà. Il évite le mot de passe d'enrôlement partagé dans le code, range le certificat client dans le gestionnaire de secrets et prévoit son renouvellement. Il sait que les droits REST passent par les règles d'accès d'EJBCA.
Signal d'alerteUn compte super-administrateur pour l'automatisation, ou un appel à l'interface web scripté.
Question 4 · senior
Comment séparez-vous l'autorité, l'autorité d'enregistrement (RA) et le répondeur de validation (VA) dans une architecture EJBCA, et qui ouvre les connexions ?
Une bonne réponseL'autorité reste dans une zone protégée et n'accepte aucune connexion entrante. Les RA et VA sont des instances séparées, plus exposées, et l'autorité ouvre elle-même la connexion sortante vers elles grâce aux peers, fonction de l'édition Enterprise. La RA reçoit les demandes des protocoles et les transmet, le VA sert l'OCSP à partir des statuts publiés. Il explique ce que gagne la sécurité à cette direction de connexion.
Signal d'alerteUne instance unique exposée sur Internet avec tous les rôles, ou des RA qui écrivent directement dans la base de l'autorité.
Question 5 · confirmé
L'entreprise a EJBCA, une autorité ADCS historique et deux autorités publiques. Où s'arrête le rôle d'EJBCA et où commence celui de Keyfactor Command ?
Une bonne réponseEJBCA émet et révoque pour les autorités qu'il héberge. Keyfactor Command tient l'inventaire de tous les certificats, quelle que soit l'autorité, découvre ceux qui tournent sur le réseau, alerte sur les échéances et pousse les renouvellements sur les serveurs grâce à des orchestrateurs. Il décrit Command comme la couche de cycle de vie et EJBCA comme une des autorités qu'elle pilote.
Signal d'alertePrésenter Command comme une autorité de certification, ou penser qu'EJBCA suffit à inventorier les certificats achetés ailleurs.
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
Ingénieur EJBCA et Keyfactor : les questions fréquentes
Un expert ADCS peut-il prendre en main une PKI EJBCA ?
Les notions communes sont nombreuses : hiérarchie, révocation, HSM, durées de vie. Le modèle diffère. EJBCA sépare profil de certificat et profil d'entité finale, gère les droits par rôles et règles d'accès, et se déploie souvent en architecture distribuée avec RA et VA. Un profil ADCS solide s'adapte, à condition de comprendre cette séparation. L'entretien la vérifie, sinon il recréera ses habitudes de modèles Microsoft.
Faut-il exiger l'édition Enterprise sur le CV ?
Pas pour un junior. Pour un poste sur une PKI de production avec HSM, oui en pratique, car l'édition Community ne permet plus les HSM depuis la version 9.6.2. L'édition Enterprise apporte aussi les peers et la haute disponibilité, qui changent l'architecture. Un candidat qui n'a connu que l'édition Community en laboratoire doit montrer qu'il a compris ces différences et qu'il a déjà lu une politique de certification.
Keyfactor Command et EJBCA : un même profil pour les deux ?
Souvent, mais les compétences diffèrent. EJBCA demande de la profondeur sur la PKI elle-même : profils, cryptographie, HSM, protocoles. Command demande de connaître le parc : serveurs, répartiteurs de charge, comptes de service, propriétaires des applications et automatisation. Certaines offres recherchent d'ailleurs un chef de projet ou une AMOA sur Command seul. L'offre précise la part de chacun pour attirer le bon profil.
Quel exercice est donné à un ingénieur PKI EJBCA ?
Un test technique court fonctionne bien : un besoin métier (certificats pour des équipements réseau, durée, noms autorisés, protocole disponible) à traduire en profil de certificat, profil d'entité finale et alias de protocole, sur papier ou sur une instance Community de démonstration. Une question sur la révocation et le renouvellement le complète. Vingt minutes suffisent pour voir si la personne raisonne en règles d'émission ou en clics.
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.
