Publier un service sur un VPS Linux derrière Nginx en HTTPS

Un VPS Linux qui héberge une application, une interface d'administration ou un service interne en HTTP simple expose ses échanges en clair. Passer par Nginx en proxy inverse et par un certificat Let's Encrypt gratuit est la méthode standard : Nginx termine le chiffrement, et votre application continue d'écouter tranquillement sur une adresse locale. Ce tutoriel couvre la préparation du nom de domaine, l'écriture du bloc de configuration, la validation avant rechargement, puis la demande et le renouvellement du certificat.

Ce que Nginx fait dans cette architecture

Nginx est un serveur web : c'est lui qui répond aux navigateurs sur les ports 80 et 443, distribue les sites internet hébergés sur la machine et relaie vers une application ce qu'il ne sert pas lui-même. Il fonctionne avec un processus maître qui lit la configuration et des processus de travail qui traitent les requêtes. Cette séparation explique une propriété très utile en exploitation : lorsqu'on recharge la configuration, le processus maître vérifie d'abord sa validité, et si la nouvelle version est invalide, il annule les changements et poursuit avec l'ancienne configuration. Une erreur de syntaxe ne coupe donc pas le service en cours.

Le fichier de configuration principal se nomme nginx.conf et se trouve généralement dans /etc/nginx. Il contient des blocs server qui décrivent chacun un site ou un service, et des blocs location qui précisent le traitement des chemins d'URL. Les serveurs web comme Nginx lisent ces fichiers au démarrage, puis les rechargent lorsque vous le demandez explicitement.

Un serveur virtuel, c'est-à-dire un VPS dont les ressources sont isolées par la virtualisation, suffit largement pour héberger plusieurs sites web et quelques services internes, à condition de dimensionner correctement la RAM et le processeur. La plupart des hébergeurs proposent des serveurs virtuels de tailles différentes, et c'est le dimensionnement choisi au départ qui déterminera le nombre de services que vous pourrez publier confortablement.

C'est aussi la différence de fond avec un hébergement mutualisé : sur un serveur mutualisé, vous déposez des fichiers mais vous ne configurez pas le serveur web, alors qu'avec un VPS vous accédez à la configuration complète. Cette liberté demande en échange de comprendre ce que vous modifiez, ce qui est l'objet de ce guide.

Se connecter au VPS en SSH

Toutes les opérations décrites ici se font en SSH, sur un VPS sous Ubuntu ou Debian, depuis un poste d'administration ou depuis le panneau de contrôle de votre hébergeur lorsqu'un terminal intégré est proposé. Connectez-vous avec votre compte, puis utilisez sudo pour les commandes qui touchent à la configuration du serveur, ou travaillez directement en root si votre hébergeur vous fournit ce niveau d'accès. Installez Nginx depuis les paquets de la distribution quand il n'est pas déjà présent, puis vérifiez que le service démarre correctement avant d'ajouter votre premier site.

Prenez aussi l'habitude de conserver une session SSH déjà ouverte pendant que vous modifiez la configuration réseau ou le pare-feu : c'est le moyen le plus simple de ne pas se retrouver bloqué dehors après une mauvaise règle. Un compte administrateur dédié, distinct de votre compte personnel, simplifie ensuite la traçabilité des modifications, et cette organisation évite que plusieurs administrateurs système partagent les mêmes identifiants.

Préparer le nom de domaine

Un certificat se demande pour un nom de domaine, pas pour une adresse IP. Faites pointer un enregistrement de type A vers l'adresse du VPS, puis vérifiez que le nom se résout correctement avant toute demande de certificat. Prévoyez l'alias www si votre service doit répondre sur les deux formes : chaque nom utilisé dans la commande Certbot fait partie du même certificat et doit résoudre vers la machine. Si la machine porte plusieurs adresses IP, vérifiez que la zone DNS pointe vers celle qui répond réellement.

Si votre machine possède déjà une adresse IP supplémentaire, notre guide pour configurer une IP secondaire sur un VPS Linux vous aidera à séparer proprement les services. Et si vous partez d'une application déjà installée, un VPS avec applications préconfigurées fait gagner cette étape de mise en place et vous permet d'arriver directement à la configuration du proxy inverse.

Faire écouter le service en local

Le service à publier ne doit pas être exposé directement sur Internet. Configurez-le pour qu'il écoute sur l'interface de boucle locale, par exemple 127.0.0.1:8080, afin qu'il ne soit joignable qu'à travers Nginx. Cette règle vaut pour une application écrite maison comme pour un CMS ou une interface d'administration qui s'appuie sur une base de données MySQL ou MariaDB sur la même machine : plus le nombre de ports ouverts est faible, plus la surface d'attaque se réduit.

Cette étape est aussi l'occasion de reprendre les bases de la sécurisation d'un serveur dédié : un service qui n'écoute pas publiquement réduit la surface d'attaque, même si le pare-feu n'est pas encore parfaitement réglé.

Ouvrir les ports nécessaires

Deux flux doivent être autorisés depuis Internet : le port 80 pour la validation du certificat et pour la redirection, et le port 443 pour le trafic chiffré. Le port de votre application, lui, reste interne. Vérifiez également qu'aucun autre serveur web n'occupe déjà le port 80 sur la machine, car deux services ne peuvent pas écouter sur le même port en même temps.

Si vous gérez votre filtrage avec UFW, notre guide pour ouvrir les ports d'un serveur de jeu Linux avec UFW détaille la syntaxe des règles et les vérifications utiles. Avec un pare-feu matériel ou un firewall fourni par l'hébergeur, appliquez la même logique : autoriser 80 et 443 en entrée, et ne laisser le reste accessible que depuis votre adresse d'administration.

Écrire le bloc server

Ajoutez un fichier de config dédié à votre site plutôt que de modifier le fichier principal : un bloc par service reste lisible, et un fichier isolé se sauvegarde et se rétablit facilement. Dans la plupart des installations, la configuration principale inclut un ou plusieurs répertoires dédiés, et c'est là que vous déposerez votre fichier pour garder des configurations séparées et faciles à relire. Un bloc de proxy inverse minimal, directement inspiré de l'exemple publié dans la documentation Nginx, ressemble à ceci :

server {
    listen 80;
    server_name service.exemple.fr www.service.exemple.fr;

    location / {
        proxy_pass http://127.0.0.1:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

La directive proxy_pass transmet la requête à votre service local. La documentation Nginx illustre cette configuration avec les en-têtes Host et X-Real-IP, qui permettent à l'application de connaître le nom de domaine demandé et l'adresse d'origine du visiteur. Commencez volontairement par un bloc en HTTP : c'est ce bloc que Certbot reprendra ensuite pour ajouter TLS puis la redirection permanente.

Tester puis recharger sans couper le service

Nginx documente deux paramètres complémentaires. nginx -t teste le fichier de configuration, en vérifiant la syntaxe puis en tentant d'ouvrir les fichiers auxquels la configuration fait référence. nginx -T fait la même chose en affichant la configuration finale, ce qui permet de voir quelle version des fichiers inclus est réellement appliquée. Une fois le test concluant, nginx -s reload applique la configuration sans interrompre le service, et systemctl restart nginx reste disponible lorsque vous devez repartir d'un état propre.

Avant chaque modification, gardez une copie de sauvegarde, un simple backup du fichier concerné suffit, et rangez les commandes de modification dans un script versionné : vous saurez toujours comment le serveur a été configuré et dans quel ordre. Ces scripts servent aussi de documentation pour la personne qui reprendra l'exploitation. À l'inverse, redémarrer brutalement un serveur mal configuré en production est la meilleure façon de provoquer une coupure évitable.

Obtenir le certificat avec Certbot

Certbot, le client recommandé par Let's Encrypt, automatise la demande et l'installation du certificat. Son greffon Nginx est à la fois un authentificateur et un installateur : il utilise la validation HTTP-01 sur le port 80, puis modifie la configuration Nginx pour servir le certificat SSL et gérer le renouvellement. La commande s'écrit simplement :

certbot --nginx -d service.exemple.fr -d www.service.exemple.fr

Trois points sont rappelés par la documentation officielle. Sauvegardez vos fichiers de configuration Nginx avant l'opération, même si Certbot sait revenir en arrière avec certbot --nginx rollback. Si vous préférez ne pas laisser l'outil modifier votre configuration, certbot certonly obtient le certificat sans l'installer et vous renseignez vous-même les chemins. Enfin, les certificats sont enregistrés dans /etc/letsencrypt/live/ et renouvelés selon un calendrier régulier mis en place par l'outil.

La validation HTTP-01 impose une contrainte à connaître : elle passe obligatoirement par le port 80, et Let's Encrypt suit les redirections vers HTTP ou HTTPS sur les ports 80 et 443, sur dix niveaux au maximum. Une redirection globale mal placée, par exemple vers un port non standard, fait donc échouer la validation. Les certificats génériques, qui couvrent plusieurs sous-domaines, nécessitent en revanche la validation DNS-01 et un fournisseur DNS disposant d'une API exploitable pour l'automatiser.

Renouvellement et suivi dans la durée

Les certificats délivrés par Let's Encrypt ont une durée de validité de 90 jours, et la documentation recommande un renouvellement tous les 60 jours. Certbot met ce renouvellement en place automatiquement lors de la première demande : testez-le réellement avec certbot renew --dry-run au lieu de le supposer, car un certificat expiré coupe l'accès à votre service sans prévenir.

Un service publié mérite aussi un peu de surveillance. Gardez un oeil sur l'espace disque d'un VPS Linux pour éviter qu'un remplissage ne casse les journaux et le renouvellement, et prévoyez une méthode de retour arrière lorsque vous modifiez vos services, par exemple en installant Docker sur un VPS.

Quand le nombre de connexions simultanées augmente, ce sont le CPU, la RAM, le SSD et la bande passante qui deviennent déterminants, avant même la configuration du serveur web. Si votre service prend de l'ampleur, comparez les besoins d'un serveur dédié et d'un VPS, et rappelez-vous qu'il est possible de répartir plusieurs services sur plusieurs serveurs pour ne pas tout faire reposer sur une seule machine.

Erreurs fréquentes

• Redémarrer Nginx au lieu de tester la configuration puis de la recharger.
• Exposer le port de l'application directement sur Internet en plus du proxy inverse.
• Demander un certificat pour un nom de domaine qui ne se résout pas encore vers la bonne adresse.
• Oublier un alias comme www dans la commande Certbot, puis découvrir un avertissement de sécurité dans le navigateur.
• Configurer Nginx alors qu'un autre serveur web occupe déjà le port 80.
• Ne jamais contrôler le renouvellement automatique avant la date d'expiration.
• Modifier un bloc server sans conserver la version précédente du fichier.

Checklist avant mise en production

1. Le nom de domaine pointe vers l'adresse du VPS et se résout correctement.
2. Le service applicatif écoute uniquement sur l'interface locale.
3. nginx -t ne retourne aucune erreur, le serveur est donc correctement configuré.
4. Le certificat est obtenu et le renouvellement automatique a été testé.
5. La redirection vers HTTPS fonctionne et le service répond correctement depuis l'extérieur du VPS.