GLPI en HTTPS : comment ajouter un certificat SSL ?
Sommaire
I. Présentation
Dans ce tutoriel, nous allons voir comment ajouter un certificat SSL Let's Encrypt sur un serveur GLPI de manière à avoir une connexion HTTPS sécurisée associée à un certificat valide. Nous verrons également comment configurer Apache pour rendre accessible GLPI en HTTPS plutôt qu'en HTTP.
Pour obtenir un certificat SSL/TLS, il y a plusieurs possibilités :
- Certificat autosigné (déconseillé)
- Certificat émit via une autorité de certification interne telle qu'ADCS (pertinent si votre GLPI est accessible uniquement en interne)
- Certificat Let's Encrypt (gratuit, recommandé pour cet usage)
- Certificat payant provenant de GeoTrust, DigiCert, GlobalSign, Sectigo, etc...
Pour un serveur GLPI, le certificat Let's Encrypt me semble une bonne option, sauf si vous disposez déjà d'un certificat wildcard pour votre nom de domaine. Dans ce cas, il pourrait s'avérer intéressant de l'utiliser. Sinon, Let's Encrypt représente une solution fiable et gratuite pour obtenir un certificat en quelques minutes. Ce certificat est valide 90 jours, mais nous allons configurer le serveur pour qu'il soit renouvelé automatiquement.
Pour réaliser une installation de GLPI sur Debian 12, vous pouvez suivre ce tutoriel :
Le serveur précédemment installé me sert de base pour ce tutoriel. Actuellement, GLPI est accessible en HTTP depuis Internet, via le nom de domaine support.it-connect.tech.
II. Activer le module SSL sur Apache2
Nous allons effectuer le gros de la configuration directement avec Certbot, l'utilitaire permettant de demander un certificat Let's Encrypt. Toutefois, vous devez être sûr que le module SSL soit bien activé sur votre serveur Apache2.
Exécutez simplement cette commande :
sudo a2enmod sslIII. Demander un certificat Let's Encrypt pour GLPI
Nous allons installer Certbot sur le serveur GLPI afin de pouvoir demander un certificat Let's Encrypt. Commencez par mettre à jour les paquets puis procédez à l'installation des paquets nécessaires :
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install certbot python3-certbot-apachePour utiliser Certbot, il y a plusieurs possibilités, dont le mode certonly pour demander le certificat sans l'installer et un mode pour demander le certificat et l'installer à notre place. Ceci va permettre de configurer le VirtualHost Apache. Nous allons choisir cette seconde option.
Pour demander un certificat pour le domaine "support.it-connect.tech", cela donne :
sudo certbot --apache --agree-tos --redirect --hsts -d support.it-connect.tech --email [email protected]Quelques précisions sur les options utilisées :
- --apache : nous précisons qu'il s'agit d'un serveur Web Apache
- --agree-tos : accepter les conditions d'utilisation du service Let's Encrypt
- --redirect : configurer le VirtualHost Apache pour rediriger les requêtes HTTP vers HTTPS (règle de réécriture)
- --hsts : configurer le HSTS pour des raisons de sécurité
- -d : le nom de domaine pour lequel obtenir un certificat Let's Encrypt
- --email : l'adresse e-mail du contact, notamment pour recevoir une notification s'il y a un problème de renouvellement du certificat
Vous pouvez ajouter d'autres options... La liste complète est visible dans la documentation de Certbot.
Suite à l'exécution de commande, l'assistant commence par vous demander si votre e-mail peut être utilisé également pour vous contacter au sujet des nouveautés du projet, ou pour vous expliquer comment faire un don. Choisissez entre oui et non en répondant par yes ou no.
Ensuite, le processus va se poursuivre... En principe, vous avez juste à patienter quelques secondes car nous avons indiqué notre nom de domaine dans les paramètres de la commande. Comme le montre l'image ci-dessous, Certbot indique l'emplacement des fichiers générés, dont le certificat.
Voilà, nous venons d'obtenir un certificat et en plus, Apache doit être préconfiguré par Certbot.
IV. Vérifier la configuration d'Apache2 (HTTPS)
Même si Certbot a effectué le travail de configuration à notre place, c'est bien de savoir ce qu'il a fait. Le répertoire "/etc/apache2/sites-available/" de notre serveur contenait déjà le fichier de configuration "support.it-connect.tech.conf". Désormais, il y en a un second qui contient la version "HTTPS" du vHost Apache : "support.it-connect.tech-le-ssl.conf". Certbot a créé ce fichier en reprenant l'autre fichier comme base.
Dans le fichier d'origine, Certbot a ajouté une règle de réécriture pour que les requêtes en HTTP soient redirigées en HTTPS. Il s'agit d'une redirection permanente. D'ailleurs, si les règles ajoutées (RewriteCond et RewriteRule) ne donnent pas satisfaction, ajoutez celle-ci à la suite (en adaptant) :
Redirect permanent / https://support.it-connect.techPour le vérifier, éditez le fichier de configuration :
sudo nano /etc/apache2/sites-available/support.it-connect.tech.confVous verrez ces deux lignes :
Quant au second fichier, à savoir "support.it-connect.tech-le-ssl.conf", il contient des directives supplémentaires pour préciser les chemins vers le certificat et sa clé privée. Il contient aussi une option pour le HSTS (grâce à l'option --hsts spécifiée dans certbot). Il intègre aussi les options contenues dans le fichier "/etc/letsencrypt/options-ssl-apache.conf", ce qui active le SSL, autorise certains protocoles, etc... Afin d'avoir une configuration adéquate.
SSLCertificateFile /etc/letsencrypt/live/support.it-connect.tech/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/support.it-connect.tech/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
Header always set Strict-Transport-Security "max-age=31536000"
Pour finir, redémarrez Apache2 afin que cette nouvelle configuration soit activée :
sudo systemctl restart apache2V. GLPI : tester l'accès en HTTPS
Désormais, vous pouvez tester l'accès à votre GLPI en HTTPS (ou HTTP pour tester la redirection). Le certificat est bien valide et dans les détails, nous pouvons voir qu'il a été émis par Let's Encrypt et qu'il est valide 90 jours.
Un bon moyen de vérifier la configuration du SSL/TLS sur son serveur Web pour un domaine précis, c'est de lancer une analyse depuis le site SSL Labs. Ceci peut mettre en évidence des problèmes de configuration. Dans notre cas, le score obtenu est très bon :
VI. Renouvellement automatique du certificat Let's Encrypt
Pour finir, nous devons configurer le renouvellement automatique du certificat Let's Encrypt. Commençons par exécuter la commande ci-dessous pour s'assurer que Certbot sera capable de renouveler le certificat : l'option --dry-run permet de faire une simulation.
sudo certbot renew --dry-run
Tout est bon puisque le message "Congratulations, all simulated renewals succeeded" s'affiche.
Il ne reste plus qu'à éditer la crontab pour créer une tâche planifiée de renouvellement.
sudo crontab -eAjoutez la ligne ci-dessous, en adaptant si besoin la fréquence de la tâche. Dans cet exemple, il y aura une tentative effectuée tous les jours à 5h00 du matin. L'option --quiet permet d'effectuer l'action silencieusement.
0 5 * * * /usr/bin/certbot renew --quietCe qui donne :
Enregistrez et fermez.
VII. Conclusion
En suivant ce tutoriel, vous devriez être capable d'ajouter un certificat SSL Let's Encrypt à votre serveur Web qui héberge GLPI ! Ainsi, vous disposez d'un certificat valide et d'une connexion sécurisée via HTTPS pour accéder à votre solution d'ITSM.
N'hésitez pas à poster un commentaire si vous avez une question.
Bonjour,
Très bon tuto j’avais suivi ces manipulations et avait laissé mon serveur en ligne pour ce fameux renouvellement tous les 3mois Résultat piraté et serveur tombé. Glpi déconseille fortement l’usage en ligne, ou alors je recommande un reversepeoxy mais vraiment ne jamais le mettre sur internet !
Bonjour,
Avec un reverse proxy, il est clair que c’est préférable et je le recommande également ! Ceci fera l’objet d’un prochain article afin d’y aller progressivement. 🙂
Mais bon, le fait d’être piraté n’est pas une généralité : j’ai utilisé un GLPI exposé sur Internet pendant plusieurs années et il n’a pas été piraté.
Effectivement, je te recommande Crowdsec avec bouncer Apache et Firewall en parallèle d’un Apache Reverse Proxy afin d’intensifier ta sécurité avec du ban automatique.
Bonjour, il me semble que GLPI n’est pas compatible avec Crowdsec et le bouncer php (apache)
Bonjour,
Merci pour l’article. Let’s Encrypt c’est génial dans l’ensemble mais laissé une porte ouverte depuis le net pour le renouvellement automatique c’est vraiment dommage. Reverse Proxy ok mais ce n’est pas infaillible. Dommage qu’il n’y ait pas de liste de serveurs Let’s Encrypt pour n’autoriser qu’eux.
Bonjour,
Merci pour ce tuto très intéressant et très complet comme toujours.
Est-il possible de faire un article avec le certificat émit via une autorité de certification interne telle qu’ADCS et d’utiliser ce certificat pour un site sous apache?
Bonjour,
De mon coté j’ai déja un glpi en https avec comme adresse glpi.mondomaine.com qui est uniquement utilisé en interne avec une authentification Kerberos pour faire du SSO.. Désormais j’aimerai pouvoir y accéder depuis l’extérieur en passant par mon reverseproxy Nginx et en utilisant la meme adresse glpi.mondomaine.com sauf que je rencontre un souci d’authentification surement car mon kerberos attends un tickets de mon serveur glpi alors que c’est mon reverseproxy qui fait la demande… Quelqu’un pourrait il me confirmer qu’il faut que je configure le kerberos sur mon reverseproxy avec un fichier keytab ? Merci
Bonjour Florian,
Merci pour ce super tuto. Comme toujours. J’ai une petite question, j’utilise Certbot pour mon serveur Emby. Dans ton tuto tu montres comment faire le renouvellement automatique en faisant une demande tous les jours à 5h du matin. Seulement si l’on souhaite faire juste une demande un peu avant les 90 jours, quelle valeur faut-il entrer?
Bonjour,
Merci pour ce tuto
j’ai rencontrer un problème pour demander le certificat
Message d’erreur :
An unexpected error occurred:
AttributeError: can’t set attribute
Merci
Bonjour
Même erreur que ci-dessus
Message d’erreur :
An unexpected error occurred:
AttributeError: can’t set attribute
Si vous avez un tuyau merci
Bonjour Florian,
J’ai un petit problème. J’ai installé un serveur glpi 10 en local sans domaine et accessible que localement. Donc on se connecte avec l’adresse IP. J’avais suivie ta procédure pour le faire.
Or Je voulais mettre GLPI en HTTPS pour que je puisse installer Oauth IMAP afin que GLPI puisse envoyer des mails automatique lors de la création de ticket. Et sur Azure Microsoft demande que le lien soit en HTTPS.
Donc comment je pourrais faire cela sans domaine. Je suis pas super bon, mais j’aurais besoin de ton conseille.
Pour information, on ne peut pas le mettre dans le domaine (corrompu)
Merci pour ton aide
Bonjour
Même erreur également:
An unexpected error occurred:
AttributeError: can’t set attribute
Comment la résoudre j’ai fais des recherches mais rien trouvé
Bonjour,
J’ai tenté de passer glpi, de HTTP en HTTPS sur un serveur « glpi.mondomain.local », mais les inventaires ne remontent pas. Je peux utliser GLPI normalement mais plus rien de remonte depuis les agents.
J’ai créé un certifcat auto-signé, mais :
[error] [http client] internal response: 500 Can’t connect to glpi.mondomain.local:443 (Bad file descriptor), SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
[Tue Apr 2 08:13:55 2024][error] No supported answer from server at https://glpi.mondomain.local
Que me conseillez-vous pour utiliser glpi en local mais en HTTPS quand même ?
Je suis sous DEBIAN 12
Quelqu’un aurait une réponse ?
Voici ma solution, j’aimerais avoir votre opinion.
J’ai ouvert un compte chez Cloudlare
J’ai acheté un nom de domaine pour mon organisation (exemple monnomdedomaine.net)
Dans « Zero Trust », J’ai créé un tunnel pour mon organisation.
J’ai configuré la route du tunnel: glpi.monnomdedomaine.net
J’ai installé le connecteur Cloudlare sur mon serveur GLPI avec le script fourni.
J’accède au portail de GLPI par https://glpi.monnomdedomaine.net
Pour les glpi-agent, le Target Server est https://glpi.monnomdedomaine.net
Automatiquement mis en HTTPS par Cloudflare.
Tout fonctionne.
Cette solution vous semble-t-elle sécuritaire ?
Bonjour, manip OK pour le certificat SSL. Le Port 80 doit être ouvert pour renouvelé le certif sinon erreur. Si on accède au site de l’extérieur il s’affiche pas donc cela me va.
J’ai juste une erreur que je n’arrive pas à résoudre sur la page d’accueil : La directive PHP « session.cookie_secure » devrait être définie à « on » quand GLPI est accessible via le protocole HTTPS.
J’ai modifié la valeur dans : /etc/php/8.2/fpm/php.ini j’ai mis 1 ou on ou true avec PHP/APACHE redémarré et ça ne passe toujours pas si quelqu’une à une idée ? Merci
Bonjour,
Petite question comment cela se passe si je souhaite mettre en place un certificat provenant d’une autorite de certification qui serait mon AD ?
Merci