Versions Compared

Old Version 1

changes.mady.by.user Johnny

Saved on

compared with

New Version Current

changes.mady.by.user Johnny

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

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).

Info

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

ste

...

UI Steps

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

UI Step
Note

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é.


Code Block
titlegé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 : 

Code Block
Cat /tmp/monserveur.csr

copiez tout son contenu, incluant :

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


Etape 2 : Soumettre la demande de certificat à AD CS

UI Step

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

http://NomDuServeurCA/certsrv :

Image Added

 Cliquer sur demander un certificat 

Image Added

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

Image Added

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 :


Code Block
san:dns=monserveur.mondomaine.local


Cliquer sur envoyer 

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

UI Step

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

Image Added

Note

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 : 

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

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

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

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

Code Block
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 : 

Image Added

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

UI Step

Configurer Apache pour HTTPS

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

Code Block
<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

Code Block
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 


Code Block
<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 : 

Code Block
sudo a2ensite glpi.conf
sudo systemctl reload apache2


Code Block
sudo systemctl restart apache2


Note

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.