Pré-requis

  • AD CS installé et configuré sur un serveur Windows (par exemple, sur votre contrôleur de domaine ou un serveur dédié).

  • Les utilisateurs ou ordinateurs du domaine disposent des droits nécessaires pour soumettre des demandes de certificats.

  • Le modèle de certificat souhaité (par exemple « Web Server » ou un modèle personnalisé) est publié sur la CA.

  • Un poste (Windows ou Linux) pour générer la demande (CSR).

Dans cette documentation, nous prenons pour exemple de mettre l'outil de ticketing GLPI pour le mettre en HTTPS

Etape 1 :Générer une clé privée et un CSR

Le Subject Alternative Name (SAN) est désormais indispensable pour que le certificat soit reconnu comme valide par les navigateurs modernes. En effet, ces derniers n'acceptent plus le seul champ Common Name (CN) pour valider l'identité du serveur. Il est donc impératif, lors de la génération d'une demande de certificat (CSR), d'inclure le SAN correspondant au ou aux domaines que le certificat doit couvrir. Sans SAN, même si le CN est correct, le certificat sera rejeté ou affichera des avertissements de sécurité.


générer un couple clé/CSR incluant le SAN (Subject Alternative Name) :
sudo openssl req -new -newkey rsa:2048 -nodes \
  -keyout /etc/ssl/private/monserveur.key \
  -out /tmp/monserveur.csr \
  -subj "/CN=monserveur.mondomaine.local" \
  -addext "subjectAltName=DNS:monserveur.mondomaine.local"

Puisque nous avons générer la demande de certificat CSR, nous souhaitons la copie pour réaliser notre demande de certificat : 

Cat /tmp/monserveur.csr

copiez tout son contenu, incluant :

l-----BEGIN CERTIFICATE REQUEST-----
... contenu ...
-----END CERTIFICATE REQUEST-----


Etape 2 : Soumettre la demande de certificat à AD CS

Accéder à l’interface web de la CA:

http://NomDuServeurCA/certsrv :

 Cliquer sur demander un certificat 

Cliquer sur soumettre "un" demande de certificat avancée

Collez le contenu précédemment copié dans le champ "Demande enregistrée", choisir serveur web si c'est bien un serveur web

Dans la zone Attributes (facultative), vous pouvez, si nécessaire, ajouter :


san:dns=monserveur.mondomaine.local


Cliquer sur envoyer 

Etape 3 : Récupérer le certificat signé

Une fois la demande approuvée,  cliquez sur Télécharger le certificat

Remarque : DER vs Base64
Les certificats peuvent être encodés sous deux formats principaux : le format DER et le format Base64 (PEM).

  • DER est un format binaire, généralement utilisé pour le stockage ou la transmission sécurisée, mais qui n'est pas lisible directement par les humains.

  • Base64 (PEM) est un format textuel qui encapsule le contenu DER entre des délimiteurs tels que -----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----. Ce format est largement utilisé par les serveurs web (Apache, Nginx) et les applications pour une intégration facile et une vérification manuelle.
    Il est important de s'assurer que le certificat utilisé dans la configuration de votre serveur est au format Base64 (PEM) pour garantir une compatibilité maximale avec les logiciels et éviter des problèmes de chargement ou d'interprétation.

Enregistrez ce certificat (par exemple, nommez-le monserveur.crt) sur votre poste. 

Transférer le certificat sur le serveur Linux

Utilisez un outil de transfert (SCP, WinSCP, etc.) pour copier le fichier sur votre serveur Linux.

Par exemple : 

scp monserveur.crt utilisateur@votre-serveur:/tmp/

Puis, connectez vous en SSH et renommez et déplacez le dans le répertoire des certificats :

sudo mv /tmp/certnew.cer /etc/ssl/certs/glpi_cert.crt

Vérifier la correspondance entre le certificat et la clé

sudo openssl x509 -noout -modulus -in /etc/ssl/certs/monserveur.crt | openssl md5
sudo openssl rsa -noout -modulus -in /etc/ssl/private/monserveur.key | openssl md5

Les deux valeurs MD5 doivent être identiques. Sinon, il y a une incohérence entre la clé et le certificat. comme dans cet exemple : 

Installer le certificat sur votre serveur (Exemple avec Apache pour GLPI)

Configurer Apache pour HTTPS

Créez ou modifiez le VirtualHost HTTPS dans un fichier, par exemple /etc/apache2/sites-available/glpi-ssl.conf

<VirtualHost *:443>
    ServerName glpi.comptaplus.loc
    ServerAdmin webmaster@votre-domaine.local
    DocumentRoot /var/www/html/glpi/public

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/monserveur.crt
    SSLCertificateKeyFile /etc/ssl/private/monserveur.key
    # Si votre CA fournit un certificat intermédiaire, vous pouvez décommenter la ligne suivante :
    # SSLCertificateChainFile /etc/ssl/certs/ca-chain.crt

    <Directory "/var/www/html/glpi/public">
        Require all granted
        AllowOverride All
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/glpi_error.log
    CustomLog ${APACHE_LOG_DIR}/glpi_access.log combined
</VirtualHost>

Activer le site et le module SSL

sudo a2enmod ssl
sudo a2ensite glpi-ssl.conf
sudo systemctl reload apache2

Configurer la redirection HTTP vers HTTPS (vous pouvez aussi tout mettre dans le même fichier 

<VirtualHost *:80>
    ServerName glpi.comptaplus.loc
    ServerAdmin webmaster@votre-domaine.local
    DocumentRoot /var/www/html/glpi/public

    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*)$ https://%{SERVER_NAME}/$1 [R=301,L]

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Activez ce fichier de configuration : 

sudo a2ensite glpi.conf
sudo systemctl reload apache2


sudo systemctl restart apache2

Les machines du domaine reconnaissent automatiquement la CA interne (Active Directory Certificate Services), ce qui élimine généralement les avertissements de sécurité liés aux certificats. Par conséquent, il n'est pas nécessaire de déployer les certificats via GPO sur les postes utilisateurs, à condition que ceux-ci soient correctement intégrés au domaine.



No valid Data Center license found

Please go to Atlassian Marketplace to purchase or evaluate Refined Toolkit for Confluence Data Center.
Please read this document to get more information about the newly released Data Center version.








Write a comment…