Installation initiale du serveur WiKID

• Configurez une autorité de certification intermédiaire, installez-la, générez un certificat localhost et activez les modules de protocole.
• Soumettez la CSR au CA de WiKID, installez le certificat reçu, puis redémarrez le service wAuth avec la passphrase créée.

Vue d’ensemble

Ce guide explique pas à pas l’installation initiale du serveur d’authentification WiKID. Il couvre la génération d’une autorité de certification intermédiaire (CA), la création et la soumission d’une CSR, l’installation du certificat signé, la génération d’un certificat localhost et le redémarrage sécurisé du service.

Important: conservez la passphrase du PKCS12 en lieu sûr. Sans cette passphrase, la clé privée ne peut pas être récupérée et vous devrez recréer la CA.

Intentions de cet article

H1 (intention principale) : Installation initiale du serveur WiKID Variantes liées : configuration CA WiKID, générer CSR WiKID, installer certificat intermédiaire, certificat localhost WiKID, redémarrer wAuth, dépannage certificat WiKID

Avant de commencer

Pré-requis techniques

• Accès administrateur (root) au serveur WiKID.
• Accès web à l’interface d’administration du serveur.
• Adresse email valide pour recevoir le certificat signé.
• Nom DNS entièrement qualifié (FQDN) pour le serveur, si vous n’utilisez pas localhost.

Termes clés

• CSR : Certificate Signing Request, demande de signature de certificat.
• CA : Autorité de certification.
• PKCS12 : Format de fichier sécurisant clé privée et certificat.

Page d’administration initiale

L’interface d’administration permet de réaliser toutes les étapes décrites ici : création de la CA intermédiaire, envoi de la CSR, installation du certificat signé, génération des certificats pour localhost et gestion des modules de protocole.

Figure 3 — Page d’administration initiale

Mise en place de la chaîne de certificats

Le serveur WiKID s’appuie fortement sur les certificats pour deux fonctions principales :

• chaque serveur d’authentification agit aussi comme CA intermédiaire ;
• chaque serveur utilise des certificats pour authentifier et autoriser les clients réseau.

Pour que ces fonctions soient opérationnelles, un certificat doit être généré et installé via l’interface d’administration.

Étape 1 : Générer la CA intermédiaire

Le premier pas consiste à créer la paire de clés publique/privée qui identifiera le serveur et chiffrera les communications SSL. Le serveur embarque déjà le certificat CA de WiKID corporate, mais vous devez générer vos propres clés et une CSR.

Sélectionnez l’onglet « Creating an Intermediate CA » dans l’interface.

Figure 4 — Écran de création de la CA intermédiaire

Remplissez le formulaire. Tous les champs sont requis.

Champs et recommandations

• Intermediate CA Administrator Email : adresse de contact pour la réception du certificat signé. Utiliser une adresse valide.
• Server Fully Qualified Domain Name : nom DNS du serveur. Pour les services réseau, ce nom doit correspondre au nom que les clients utilisent pour se connecter.
• Organization Unit : département ou division (à titre d’identification).
• Organization Name : nom de l’entreprise. Correspondre aux enregistrements de WiKID pour accélérer la validation si vous attendez une intervention de leur part.
• Locality : ville.
• State : état ou province, non abrégé.
• Country Code : code pays à deux caractères (ex. FR, US).
• Passphrase : protège le fichier PKCS12 contenant la clé privée. Cette passphrase n’est pas stockée et ne peut pas être récupérée en cas de perte. Choisir une passphrase forte et mémorable.

Après soumission, l’interface génèrera les clés et la CSR. La CSR s’affichera au format base64 DER.

Figure 5 — La CSR

Copiez tout le bloc affiché (y compris les lignes —–BEGIN CERTIFICATE REQUEST—– et —–END CERTIFICATE REQUEST—–) pour la soumission.

Étape 2 : Soumettre la CSR pour signature

Cliquez sur le lien affiché au-dessus de la CSR pour accéder à la page de soumission du CA de WiKID. Collez le texte de la CSR dans la zone prévue, envoyez la demande et notez le numéro de suivi.

Figure 6 — Écran de soumission de la CSR

Après soumission, vous verrez un écran d’accusé de réception avec votre numéro de demande. Le CA traitera la demande et enverra le certificat signé à l’adresse email fournie. Le délai habituel est inférieur à 1 jour ouvrable, mais cela peut varier selon la charge et la politique d’approbation.

Figure 7 — Écran d’accusé de réception de la CSR

Lorsque vous recevez le certificat par email, il ressemblera à un bloc de texte encodé base64 (—–BEGIN CERTIFICATE—– … —–END CERTIFICATE—–).

Figure 8 — Bloc certificat reçu

Note : le certificat seul n’est utile que si vous possédez la clé privée générée lors de l’étape 1. Couper-coller le certificat en texte brut. Certains clients mail modifient le format du texte.

Étape 3 : Installer le certificat

Retournez dans l’onglet « Install Intermediate CA » de l’interface de gestion des certificats. Sélectionnez Installer et collez le bloc de certificat reçu par email dans la zone prévue. Entrez la passphrase utilisée à l’étape 1 pour déverrouiller la clé privée et installez l’intermédiaire.

Figure 9 — Écran d’installation du certificat

Si l’installation échoue, vérifiez :

• que la passphrase saisie est correcte ;
• que vous avez collé le certificat en texte brut ;
• que le certificat reçu correspond à la CSR initiale.

Si la passphrase est perdue, il faudra revenir à l’étape 1 et recréer la CA et la clé privée.

Étape 4 : Générer un certificat localhost

Les services locaux qui communiquent avec le serveur d’authentification (modules de protocole, interfaces LDAP, modules RADIUS encapsulés, etc.) nécessitent un certificat émis par la CA intermédiaire pour valider les connexions. Pour les services locaux, créez un certificat dont le FQDN est « localhost ». Le serveur l’installera automatiquement aux emplacements attendus.

Figure 10 — Écran de génération de certificat

Champs et sens :

• Client Fully Qualified Domain Name : nom résolu par le serveur pour la connexion client. Pour services locaux, saisir localhost.
• Organization Name : nom de l’organisation.
• Locality : ville.
• State : état/province.
• Country Code : code pays à deux chiffres.
• Client PKCS12 Passphrase : passphrase protégeant le PKCS12 du client.
• Passphrase again : confirmation de la passphrase client.
• Server Keystore Passphrase : passphrase de la CA intermédiaire créée en étape 1.

Sélectionnez Générer. Le message affichera l’emplacement du fichier PKCS12 généré. Pour localhost, le certificat est parfois installé automatiquement.

Figure 11 — Écran de livraison PKCS

Étape 5 : Redémarrer le service wAuth

Connectez-vous en root et exécutez la commande suivante pour redémarrer les services d’authentification :

wikidctl restart

Lors du redémarrage, le serveur demandera la passphrase wAuth. C’est la passphrase que vous avez créée à l’étape 1 pour la CA intermédiaire. Saisir la passphrase permet au serveur d’utiliser la clé privée et le certificat pour authentifier les clients.

Si vous préférez éviter la saisie manuelle de la passphrase à chaque redémarrage, vous pouvez créer un fichier sécurisé contenant la variable WAUTH_PASSPHRASE. Exemple :

• Créez le fichier /etc/WiKID/security avec une seule ligne : WAUTH_PASSPHRASE=votrepassphrase
• Restreignez les permissions à root : chmod 600 /etc/WiKID/security

Important: stocker une passphrase en clair augmente le risque. Assurez-vous que le fichier est accessible uniquement par root et que le serveur lui-même est physiquement et logiquement protégé.

Bonnes pratiques pour les passphrases et la sécurité

• Utilisez une passphrase d’au moins 16 caractères, mélange de lettres, chiffres et symboles.
• Conservez la passphrase dans un coffre-fort de mots de passe d’entreprise ou un gestionnaire de secrets approuvé.
• Ne partagez pas la passphrase par email non chiffré.
• Auditez périodiquement les accès root et les permissions des fichiers contenant des secrets.

Recommandations opérationnelles

• Planifiez une fenêtre de maintenance pour l’installation initiale et les redémarrages.
• Testez l’accès des clients internes après l’installation du certificat localhost.
• Documentez la CSR, le numéro de demande et l’email utilisé pour la traçabilité.

Modèles et exemples utiles

Modèle de message à l’équipe CA après génération de la CSR

Objet : Soumission CSR WiKID pour serveur FQDN

Corps :

• Nom du serveur : exemple.mondomaine.fr
• Email de contact : [email protected]
• Numéro de ticket interne : 12345
• Remarque : CSR envoyée via l’interface WiKID, merci de renvoyer le certificat signé à l’adresse ci-dessus.

Template de formulaire CSR (champs à remplir) :

• Intermediate CA Administrator Email :
• Server FQDN :
• Organization Unit :
• Organization Name :
• Locality :
• State :
• Country Code :
• Passphrase (PKCS12) :

Checklist d’installation initiale

• Générer la CA intermédiaire et sauvegarder la CSR
• Soumettre la CSR au CA et noter le numéro de demande
• Recevoir le certificat signé par email
• Installer le certificat via l’onglet Install Intermediate CA
• Générer et installer le certificat localhost si nécessaire
• Redémarrer wAuth et vérifier les logs
• Vérifier l’accès des clients et des modules (LDAP, RADIUS, etc.)

Procédure de vérification et critères d’acceptation

Критерии приёмки

• Le service wAuth redémarre sans erreur après saisie de la passphrase.
• Les connexions locales utilisant le certificat localhost sont acceptées.
• Les clients réseau reconnus par le serveur s’authentifient correctement.
• Les fichiers PKCS12 sont présents aux emplacements attendus et protégés par permissions restreintes.

Tests d’acceptation recommandés

• Test 1 : tentative d’authentification LDAP via l’interface WiKID ; résultat attendu : réussite.
• Test 2 : vérification d’établissement TLS entre un client test et le serveur ; résultat attendu : handshake TLS réussi et certificat valide.
• Test 3 : tentative d’accès non autorisé depuis une source non approuvée ; résultat attendu : refus.

Scénarios d’échec courants et résolutions

Symptôme : erreur lors de l’installation du certificat « passphrase incorrecte »

• Cause probable : passphrase PKCS12 erronée.
• Solution : vérifier la passphrase utilisée lors de l’étape 1. Si perdue, régénérer la CA intermédiaire et re-soumettre une nouvelle CSR.

Symptôme : clients signalent un mismatch de nom d’hôte sur le certificat

• Cause probable : le FQDN inscrit dans le certificat ne correspond pas au nom que les clients utilisent.
• Solution : régénérer le certificat client avec le bon FQDN ou mettre à jour les clients pour utiliser le nom inscrit dans le certificat.

Symptôme : réception de certificat par email mais handshake TLS échoue

• Vérifier que le certificat reçu correspond bien à la CSR envoyée.
• Vérifier l’ordre de confiance : la chaîne doit inclure le certificat intermédiaire et, si nécessaire, le certificat racine.
• Vérifier le format : coller en texte brut, sans modification d’encodage.

Playbook incident : certificat compromi ou perte de passphrase

1. Identification : confirmer que la clé privée ou la passphrase est compromise ou perdue.
2. Contention : mettre hors ligne le service si nécessaire pour empêcher l’usage non autorisé.
3. Remédiation : régénérer la CA intermédiaire, créer une nouvelle CSR, soumettre au CA et installer le nouveau certificat.
4. Validation : redémarrer wAuth, valider les connexions et les logs.
5. Rétroaction : notifier les équipes affectées et mettre à jour le plan de gestion des secrets.

Checklist rôles et responsabilités

Administrateur système

• Générer la CA et la CSR.
• Installer le certificat signé.
• Redémarrer les services et gérer les fichiers PKCS12.

Responsable sécurité

• Valider la politique de passphrase.
• Vérifier les permissions et l’audit des accès.
• Autoriser la publication du certificat si nécessaire.

Opérations réseau

• Vérifier la résolution DNS pour le FQDN du serveur.
• Tester les connexions TLS depuis les segments réseau concernés.

Arbre de décision pour choisir entre localhost ou FQDN

flowchart TD
  A[Besoin de certificat pour des services locaux ?] -->|Oui| B{Les services utilisent-ils 'localhost' comme nom ?}
  A -->|Non| C[Créer certificat avec FQDN réel]
  B -->|Oui| D[Créer certificat client avec FQDN = localhost]
  B -->|Non| E[Créer certificat client avec le FQDN utilisé par les clients]
  D --> F[Installer localement et vérifier]
  C --> F
  E --> F

Sécurité et conformité

Sécurité

• Restreindre l’accès aux emplacements contenant les PKCS12.
• Utiliser des permissions 600 sur les fichiers secrets.
• Envisager l’utilisation d’un HSM ou d’un gestionnaire de clés si disponible.

Protection des données et RGPD (notes générales)

• Les certificats et les clés n’exposent pas directement des données à caractère personnel, mais leur compromission peut permettre un accès non autorisé aux systèmes qui en contiennent.
• Documentez les traitements et les finalités en cas d’utilisation de certificats pour l’authentification d’utilisateurs ou la journalisation d’accès.

Annexes techniques

Emplacements et permissions recommandés

• Fichier PKCS12 CA : /etc/WiKID/keystore.p12 (protéger par permissions 600)
• Fichier secrets : /etc/WiKID/security (600 et uniquement root)

Exemples de commandes utiles

• Redémarrage des services : wikidctl restart
• Vérifier les logs : tail -f /var/log/wikid/*.log (adapter selon la configuration)

Glossaire rapide

• CA : autorité de certification qui signe des certificats.
• CSR : demande de signature de certificat contenant la clé publique et les informations d’identité.
• PKCS12 : format regroupant certificat et clé privée, protégé par passphrase.

Récapitulatif final

• Générez la CA intermédiaire et conservez la passphrase.
• Soumettez la CSR au CA de WiKID et installez le certificat reçu.
• Créez un certificat localhost pour les services locaux si nécessaire.
• Redémarrez wAuth avec la passphrase et validez le fonctionnement.

Important: sans la clef privée et la passphrase du PKCS12, le certificat signé ne permettra pas au serveur d’établir d’identité. Sauvegardez ces éléments en respectant les procédures de sécurité de votre organisation.