| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
| linux_ejbca [2024/03/19 16:47] – nekan | linux_ejbca [2024/03/26 16:53] (Version actuelle) – [L'état des différents containers] nekan |
|---|
| ====== EJBCA - Installation d'une infrastructure à clés publiques (PKI) ====== | ====== EJBCA - Installation d'une infrastructure à clés publiques (PKI) ====== |
| |
| <label type="success">Création</label> --- //[[nekan@shyrkasystem.com|Nicolas THOREZ]] 2024/03/19 10:29// | <label type="success">Création</label> --- //[[nekan@shyrkasystem.com|Nicolas THOREZ]] 2024/03/19 10:29// \\ |
| | <label type="info">Modification</label> --- //[[nekan@shyrkasystem.com|Nicolas THOREZ]] 2024/03/26 16:26// |
| |
| Une infrastructure à clés publiques ou PKI (//**P**ublic **K**ey **I**nfrastructure//) est un ensemble de services permettant de gérer des clés publiques et se faisant, permettant l'authentification d'un service, système ou utilisateur. | Une infrastructure à clés publiques ou PKI (//**P**ublic **K**ey **I**nfrastructure//) est un ensemble de services permettant de gérer des clés publiques et se faisant, permettant l'authentification d'un service, système ou utilisateur. |
| echo "Script de gestion du service EJBCA" | echo "Script de gestion du service EJBCA" |
| echo "" | echo "" |
| echo "Usage : ./manage-ejbca-daemon.sh [start|stop|restart|status|help]" | echo "Usage : ./manage-ejbca-daemon.sh [backup|help|restart|start|status|stop|upgrade]" |
| echo "" | echo "" |
| echo "start Démarre l'instance." | echo "backup Sauvegarde la base de données." |
| echo "stop Arrête l'instance." | echo "help Affiche cette aide." |
| echo "restart Redémarre l'instance." | echo "restart Redémarre l'instance." |
| | echo "start Démarre l'instance." |
| echo "status Affiche l'état de l'instance." | echo "status Affiche l'état de l'instance." |
| echo "help Affiche cette aide." | echo "stop Arrête l'instance." |
| | echo "upgrade Met à jour l'instance." |
| } | } |
| |
| |
| case $1 in | case $1 in |
| "start"|"restart"|"stop"|"status") | "start"|"restart"|"stop"|"status"|"upgrade"|"backup") |
| ACTION="$1" | ACTION="$1" |
| ;; | ;; |
| ;; | ;; |
| esac | esac |
| | ;; |
| | "backup") |
| | # Vérification de l'état et action |
| | case $STATUS in |
| | 0) |
| | # Démarré |
| | echo "Sauvegarde en cours..." |
| | Version=$(curl -k -s https://localhost/ejbca/ejbca-rest-api/v1/certificate/status | jq .revision | awk '{print $2}') |
| | UserName=$(grep 'MYSQL_USER' $WRKDIR/docker-compose.yml | cut -d'=' -f2) |
| | PassWord=$(grep 'MYSQL_PASSWORD' $WRKDIR/docker-compose.yml | cut -d'=' -f2) |
| | cd $WRKDIR && docker compose exec $EJBDB mysqldump ejbca -u${UserName} -p${PassWord} > ejbca-${Version}-backup-$(date +%Y%m%d_%H%M_%Z).sql |
| | if [[ $? -eq 0 ]]; then |
| | # Sauvegarde réussie |
| | echo "Sauvegarde réussie" |
| | CODE=0 |
| | else |
| | # Sauvegarde raté |
| | echo "Sauvegarde en échec" |
| | CODE=2 |
| | fi |
| | ;; |
| | *) |
| | # Autres |
| | echo "L'instance n'est pas correctement démarrée. Sauvegarde impossible." |
| | CODE=2 |
| | ;; |
| | esac |
| | ;; |
| | "upgrade") |
| | # On arrête l'instance |
| | echo "Arrêt de l'instance" |
| | cd $WRKDIR && docker compose down |
| | |
| | # Mise à jour |
| | echo "Téléchargement de la dernière version" |
| | cd $WRKDIR && docker image pull keyfactor/ejbca-ce:latest |
| | |
| | # Redémarrage de l'instance |
| | echo "Redémarrage et mise à jour" |
| | cd $WRKDIR && docker compose up -d |
| ;; | ;; |
| *) | *) |
| <file>@reboot /opt/ejbca/manage-ejbca-daemon.sh start</file> | <file>@reboot /opt/ejbca/manage-ejbca-daemon.sh start</file> |
| |
| ===== Configuration ===== | ===== Création du compte administrateur ===== |
| | |
| ==== Création du compte administrateur ==== | |
| |
| <callout type="info" title="Nomenclature" icon="true">Du point de vue de EJBCA, tous les utilisateurs sont des administrateurs. Les comptes sont déterminés selon ces différents types : | <callout type="info" title="Nomenclature" icon="true">Du point de vue de EJBCA, tous les utilisateurs sont des administrateurs. Les comptes sont déterminés selon ces différents types : |
| * Admin : Compte d'administration avec des droits limités. | * Admin : Compte d'administration avec des droits limités. |
| |
| De mon côté, je pars toujours du fait qu'un administrateur a toujours tous les droits. Lorsque les droits sont limités, on est alors sur un profils d'utilisateur (User) ou d' utilisateur privilégié (PowerUser). | De mon côté, je pars toujours du fait qu'un administrateur a toujours tous les droits. Lorsque les droits sont limités, on est alors sur un profils d'utilisateur (User) ou d'utilisateur privilégié (PowerUser). |
| |
| Du coup, dans la suite de cette procédure, j'utiliserais les termes suivant : | Du coup, dans la suite de cette procédure, j'utiliserais les termes suivant : |
| </callout> | </callout> |
| |
| | ==== Création du certificat ==== |
| | |
| | * Lors de la 1<sup>ère</sup> connexion à l'interface, il est possible que votre navigateur vous propose d'envoyer un certificat pour l'authentification. Il faudra décocher la case ''Se souvenir de cette décision'' et refuser cet envoi. Ce message peut revenir plusieurs fois tant que l'authentification n'est pas paramétrée : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-001.png |}}</image> |
| | * Pour créer un compte admin, on ira dans ''RA Web'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-002.png |}}</image> |
| | * Dans la nouvelle fenêtre, on ira dans la section ''Request new certificate'' et on cliquera sur ''Make New Request'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-003.png |}}</image> |
| | * Dans la section ''Select Request Template'', on choisit les options suivantes : |
| | * **Certificate subtype** : ''ENDUSER (default)'' |
| | * **Key-pair generation** : ''By the CA'' |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-004.png |}}</image> |
| | * Dans la section ''Select key algorithm'', on choisira : |
| | * **Key algorithm** : ''RSA 2048 bits'' |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-005.png |}}</image> |
| | * Dans la section ''Provide request info'', on entre les informations : |
| | * **CN, Common Name** : on entre le nom du compte administrateur. |
| | * **Key Recoverable** : on décoche le case. |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-006.png |}}</image> |
| | * Dans la section ''Provide User Credentials'', on entre les informations : |
| | * **Username** : Le nom de du compte administrateur. |
| | * **Enrollment code** : Le mot de passe permettant d'enregistrer le certificat. |
| | * **Confirm enrollment code** : On confirme le mot de passe précédent. |
| | * **Email** : L'adresse mail associé à ce compte d'administration. |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-007.png |}}</image> |
| | * Finalement, dans la section ''Confirm request'', on trouvera le résumé de nos paramétrages et on pourra télécharger le certificat en cliquant sur ''Download PKCS#12'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-008.png |}}</image> |
| | |
| | ==== Import du certificat dans le navigateur ==== |
| | |
| | <callout type="info" title="Navigateur" icon="true">J'utilise principalement ''Firefox'' en tant que navigateur internet. La procédure est donc basée sur ce dernier mais reste relativement similaire sur les autres navigateurs.</callout> |
| | |
| | * Maintenant, il faut importer le certificat dans le navigateur. Pour ''Firefox'', on ira donc dans le menu ''Paramètres'' puis ''Vie privée et sécurité'' et enfin ''Afficher les certificats...'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-009.png |}}</image> |
| | * Dans le gestionnaire de certificats, on sélectionne ''Vos certificats'' et on clique sur ''Importer...'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-010.png |}}</image> |
| | * On choisit le certificat créé, on entre le mot de passe de l'enregistrement et on clique sur ''Connexion'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-011.png |}}</image> |
| | * On peut vérifier la présence du nouveau certificat dans la liste et on sort du gestionnaire. |
| | |
| | ==== Création du compte sur EJBCA ==== |
| | |
| | * On retourne sur l'interface d'administration de ''EJBCA'' et on clique sur ''Roles and Access Rules'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-012.png |}}</image> |
| | * On supprime ''Public Access Role'' et on édite les membres de ''Super Administrator Role'' en cliquant sur ''Members'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-013.png |}}</image> |
| | * On paramètre : |
| | * **Match with** : On sélectionne ''X509: CN, Common name''. |
| | * **CA** : On choisit ''ManagementCA''. |
| | * **Match Value** : On entre le nom du compte administrateur tel qu'il a été entré dans le champs ''CN, Common Name'' lors de la création du certificat. Attention, ce champs est sensible à la casse. |
| | * **Description** : Optionnel, cela permet d'identifier plus facilement le compte. |
| | * Une fois les paramètres réglés, on valide en cliquant sur ''Add'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-014.png |}}</image> |
| | * On redémarre l'instance et on attend son démarrage complet : |
| | <sxh bash>/opt/ejbca/manage-ejbca-daemon.sh restart |
| | cd /opt/ejbca/containers/ && docker compose logs -f | grep 'Health ckeck now reports application'</sxh> |
| | |
| | ==== Test et validation ==== |
| | |
| | * On ferme le navigateur pour vider le cache et on se reconnecte sur l'interface d'administration et lors de la demande d'envoi de certificat, on choisit le certificat créé. |
| | |
| | <callout type="warning" title="Décisions d'authentification" icon="true">Si à la reconnexion, vous n'avez pas de demande de certificat, c'est très probablement parce que ''Firefox'' a enregistré la décision de ne pas en envoyer. Pour réinitialiser cette décision, il suffit de supprimer l'entrée correspondante à l'adresse du serveur dans le gestionnaire de certificats de ''Firefox'' (ouvert lors de l'enregistrement du certificat), onglet ''Décisions d'authentification''. Une fois la réinitialisation faîte, on peut retenter la connexion.</callout> |
| | |
| | * On retourne sur l'interface d'administration, dans ''Roles and Access Rules'', et ''Members'' de ''Super Administrator Role''. |
| | * On supprime ''PublicAccessAuthenticationToken'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-015.png |}}</image> |
| | |
| | <callout type="warning" title="Echec d'authentification" icon="true">Si vous ne vous êtes pas connecté grâce au certificat, alors vous aurez une erreur et vous ne pourrez pas supprimer l'accès publique.</callout> |
| | |
| | ===== Configuration pour les accès API ===== |
| | |
| | Si on souhaite interagir avec les autorités de certifications via API (pour de l'automatisation par exemple), il convient de le configurer le service et l'utilisateur au niveau de l'interface d'administration : |
| | |
| | ==== Service ==== |
| | |
| | * On va dans ''System Configuration'', ''Protocol Configuration'' et on active ''REST Certificate Management'' avec le bouton ''Enable'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-060.png |}}</image> |
| | |
| | ==== Utilisateur ==== |
| | |
| | <callout type="info" title="Automatisation" icon="true">A ce niveau, le service API est disponible sur notre infrastructure. Les administrateurs peuvent l'utiliser avec leur certificat. Cependant, dans le cadre d'une automatisation, il est dangereux d'utiliser un compte avec trop de droits et notamment celui d'un admin. Il faut donc créer un utilisateur avec des droits se limitant au strict nécessaire. On va donc créer un profil pour créer, interroger et révoquer des certificats TLS uniquement.</callout> |
| | |
| | * On va commencer par créer un certificat utilisateur, qu'on appellera ''script'', comme on l'a fait pour l'administrateur. |
| | * Une fois en possession du certificat, on va dans ''Roles and Access Rules'' et on crée un rôle en cliquant sur ''Add'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-061.png |}}</image> |
| | * On nomme notre rôle et on clique sur ''Add'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-062.png |}}</image> |
| | * On édite les droits pour ce nouveau rôle en cliquant sur ''Access Rules'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-063.png |}}</image> |
| | * On va directement dans ''Advanced Mode'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-064.png |}}</image> |
| | * On modifie les puces suivantes : |
| | |
| | ^Catégorie ^Droits ^ Autorisation ^ |
| | |Role Based Access Rules |/administrator/ | Allow | |
| | |Regular Access Rules |/ca_functionality/create_certificate/ | Allow | |
| | |:::|/ca_functionality/use_username/ | Allow | |
| | |:::|/ra_functionality/edit_end_entity/ | Allow | |
| | |:::|/ra_functionality/revoke_end_entity/ | Allow | |
| | |CA Access Rules |/ca/<votre autorité intermédiaire>/ | Allow | |
| | |End Entity Profile Access Rules |/endentityprofilesrules/<votre profil de certificat TLS>/ | Allow | |
| | |:::|/endentityprofilesrules/<votre profil de certificat TLS>/approve_end_entity/ | Deny | |
| | |:::|/endentityprofilesrules/<votre profil de certificat TLS>/delete_end_entity/ | Deny | |
| | |:::|/endentityprofilesrules/<votre profil de certificat TLS>/view_end_entity/ | Deny | |
| | |:::|/endentityprofilesrules/<votre profil de certificat TLS>/view_end_entity_history/ | Deny | |
| | |
| | * On n'oublie pas de sauvegarder les droits en cliquant sur ''Save'' en bas de page. |
| | * On retourne sur notre liste de rôle et on clique sur ''Members'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-065.png |}}</image> |
| | * Comme précédemment pour le compte administrateur, on paramètre : |
| | * **Match with** : On sélectionne ''X509: CN, Common name''. |
| | * **CA** : On choisit ''ManagementCA''. |
| | * **Match Value** : On entre le nom du compte utilisateur, à savoir ''script'' dans notre cas. |
| | * **Description** : Optionnel, cela permet d'identifier plus facilement le compte. |
| | * On ajoute le compte en cliquant sur ''Add'' : |
| | <image shape="thumbnail">{{ :linux:ejbca:ejbca-066.png |}}</image> |
| | |
| | <callout type="info" title="Bot" icon="true">Voilà, on dispose désormais d'un utilisateur authentifié avec un certificat et un mot de passe et disposant de droits limités.</callout> |
| | |
| | ===== Supervision ===== |
| | |
| | Pour la supervision dans ''Nagios'', nous allons contrôler 4 éléments : |
| | * L'état du service ''docker''. |
| | * L'état des différents containers. |
| | * L'état de santé de la PKI. |
| | * La présence de mises à jour. |
| | |
| | Ci-dessous, je dépose les scripts que j'utilise pour les différents contrôles |
| | |
| | ==== L'état du service docker ==== |
| | |
| | On se base sur les plugins de ''nagios'' avec la commande : |
| | <sxh bash>/usr/lib/nagios/plugins/check_procs -w 1:1 -c 0: -C dockerd</sxh> |
| | |
| | ==== L'état des différents containers ==== |
| | |
| | J'utilise le script de Tim Laurence (Source : [[https://github.com/timdaman/check_docker/blob/master/check_docker/check_docker.py|GitHub]]) pour contrôler l'état des containers. Une fois le script installé, il suffit de lancer la commande suivante : |
| | <sxh bash>/usr/lib/nagios/plugins/check_docker.py --no-ok --status running --containers ejbca ejbca-database</sxh> |
| | |
| | ==== L'état de santé de la PKI ==== |
| | |
| | La PKI réalise une vérification automatique de son état de santé. Son rapport est affiché à l'URI ''/ejbca/publicweb/healthcheck/ejbcahealth''. Le script suivant interroge cette adresse et renvoie l'information au format ''NRPE'' : |
| | <sxh bash>#!/bin/bash |
| | |
| | # Adresse du serveur |
| | ServerAddress="localhost" |
| | |
| | # URI de l'état de santé |
| | Uri="/ejbca/publicweb/healthcheck/ejbcahealth" |
| | |
| | # Requête |
| | Request=$(curl -k -s https://${ServerAddress}${Uri}) |
| | |
| | # Traitement du résultat de la requête |
| | if [ "$Request" == "ALLOK" ]; then |
| | # Tout va bien |
| | Status="GOOD" |
| | ExitCode=0 |
| | else |
| | # PKI en erreur |
| | Status="CRIT" |
| | ExitCode=2 |
| | fi |
| | |
| | # Renvoi des informations |
| | echo "$Status - Health status : $Request" |
| | exit $ExitCode</sxh> |
| | |
| | ==== La présence de mises à jour ==== |
| | |
| | On vérifie la présence de mise à jour en comparant le hash de la version actuelle de notre PKI avec le hash de la dernière version. |
| | <sxh bash>#!/bin/bash |
| | |
| | # Adresse du serveur |
| | ServerAddress="localhost" |
| | |
| | # Uri du status |
| | ServerUri="/ejbca/ejbca-rest-api/v1/certificate/status" |
| | |
| | # Nom du container |
| | Container="keyfactor/ejbca-ce" |
| | |
| | # Récupération de la version actuelle |
| | Actual=$(curl -k -s https://${ServerAddress}${ServerUri} | jq .revision | awk '{print $2}') |
| | |
| | # Récupération du hash de la version actuelle |
| | ActualHash=$(docker manifest inspect ${Container}:${Actual} | jq .config.digest) |
| | |
| | # Récupération du hash de la dernière version |
| | LatestHash=$(docker manifest inspect ${Container}:latest | jq .config.digest) |
| | |
| | # Test et retour |
| | if [ "$ActualHash" == "$LatestHash" ]; then |
| | # Les hash sont les mêmes, on est à jour |
| | echo "GOOD - up-to-date" |
| | exit 0 |
| | else |
| | # Une mise à jour est disponible |
| | echo "WARN - update available" |
| | exit 1 |
| | fi</sxh> |
| | |
| | ===== Conclusion ===== |
| | |
| | <callout type="success" title="Opérationnel" icon="true">A ce stade, vous avez une infrastructure opérationnelle. Félicitations.</callout> |
| | |
| | On peut désormais créer des autorités de certifications : [[ejbca_createca|EJBCA - Création de certificats racine et intermédiaire]] |
| |
| |
| ~~DISCUSSION~~ | ~~DISCUSSION~~ |