Tous les produits
Search
Centre de documentation

Certificate Management Service:Install an SSL certificate on an Nginx or Tengine server (Linux)

Dernière mise à jour :Sep 09, 2026

Activez le protocole HTTPS sur votre serveur Nginx ou Tengine en installant un certificat SSL. Ce guide vous accompagne dans le téléchargement du certificat, l'ouverture du port 443, la configuration du bloc serveur Nginx et la vérification du résultat.

Objectifs de cette procédure :

  • Téléchargez le package de certificats depuis la console SSL Certificates et transférez-le sur votre serveur

  • Ouvrez le port 443 dans votre groupe de sécurité et votre pare-feu système

  • Ajoutez un bloc serveur HTTPS à votre configuration Nginx

  • Rechargez Nginx et confirmez que le certificat fonctionne correctement

Ces étapes s'appliquent également à Tengine, qui est compatible avec les configurations Nginx.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • Un certificat SSL émis par une autorité de certification (CA) de confiance. Si le certificat a expiré ou est sur le point d'expirer, renouvelez-le au préalable

  • Un compte root ou un compte disposant des privilèges sudo sur le serveur

  • Un enregistrement DNS configuré pour résoudre le nom de domaine vers l'adresse IP publique du serveur

  • Un certificat couvrant tous les domaines que vous souhaitez sécuriser

Règles de couverture des domaines :

Type de couverture

Éléments protégés

Éléments non protégés

Correspondance exacte (example.com)

example.com uniquement

www.example.com ou tout autre sous-domaine

Correspondance exacte (www.example.com)

www.example.com uniquement

Le domaine racine ou d'autres sous-domaines

Joker (*.example.com)

Sous-domaines de premier niveau : www.example.com, a.example.com

Domaine racine example.com, sous-domaines multiniveaux tels que a.b.example.com

Pour protéger un sous-domaine multiniveau tel que a.b.example.com , le champ Bound Domains doit contenir soit le domaine exact, soit un joker correspondant tel que *.b.example.com .

Pour ajouter ou modifier des noms de domaine, achetez un certificat commercial ou ajoutez et remplacez des noms de domaine.

Étape 1 : Préparer le certificat SSL

  1. Accédez à la page SSL Certificates. Dans la colonne Actions correspondant au certificat cible, cliquez sur Download Certificate. Dans l'onglet Download , sélectionnez Nginx comme Server Type et téléchargez le package.

  2. Décompressez le package téléchargé :

    • Si le package contient un fichier de certificat (.pem) et un fichier de clé privée (.key), enregistrez les deux fichiers. Vous en aurez besoin à l'étape suivante.

    • Si le package ne contient qu'un fichier .pem et aucun fichier .key , utilisez le fichier de clé privée que vous avez enregistré localement lors de la génération de la demande de signature de certificat (CSR).

    Si vous avez utilisé OpenSSL ou keytool pour générer la CSR, la clé privée a été enregistrée uniquement sur votre machine locale ; elle n'est pas incluse dans le package téléchargé. Si la clé privée est perdue, le certificat devient inutilisable. Achetez un nouveau certificat commercial et générez une nouvelle CSR ainsi qu'une nouvelle clé privée.
  3. Téléversez les fichiers .pem et .key sur votre serveur. Stockez-les dans un répertoire sécurisé, tel que /etc/ssl/cert.

    Utilisez la fonctionnalité de transfert de fichiers d'un outil de connexion à distance tel que PuTTY, Xshell ou WinSCP. Si votre serveur est une instance Alibaba Cloud Elastic Compute Service (ECS), consultez la rubrique Téléverser ou télécharger des fichiers .

Étape 2 : Ouvrir le port 443

Le trafic HTTPS utilise le port TCP 443. Vérifiez qu'il est ouvert à la fois dans votre groupe de sécurité cloud et dans votre pare-feu système.

Vérifier si le port 443 est ouvert

Exécutez la commande suivante pour tester la connectivité sur le port 443. Remplacez <your_server_public_ip> par l'adresse IP publique de votre serveur.

RHEL/CentOS

command -v nc > /dev/null 2>&1 || sudo yum install -y nc
# Replace <your_server_public_ip> with the public IP address of your server.
sudo ss -tlnp | grep -q ':443 ' || sudo nc -l 443 & sleep 1; nc -w 3 -vz <your_server_public_ip> 443

Si la sortie affiche Ncat: Connected to <your_server_public_ip>:443 , le port 443 est ouvert. Sinon, suivez les étapes ci-dessous.

Debian/Ubuntu

command -v nc > /dev/null 2>&1 || sudo apt-get install -y netcat
# Replace <your_server_public_ip> with the public IP address of your server.
sudo ss -tlnp | grep -q ':443 ' || sudo nc -l -p 443 & sleep 1; nc -w 3 -vz <your_server_public_ip> 443

Si la sortie affiche Connection to <your_server_public_ip> port [tcp/https] succeeded! ou [<your_server_public_ip>] 443 (https) open , le port 443 est ouvert. Sinon, suivez les étapes ci-dessous.

Ouvrir le port 443 dans votre groupe de sécurité

Important

Si votre serveur s'exécute sur une plateforme cloud, son groupe de sécurité doit autoriser le trafic TCP entrant sur le port 443. Les étapes ci-dessous utilisent Alibaba Cloud ECS à titre d'exemple. Pour les autres plateformes cloud, reportez-vous à leur documentation.

Accédez à la page Instances Elastic Compute Service (ECS) et cliquez sur le nom de l'instance cible. Dans la section Security Group Details , ajoutez une règle avec les paramètres suivants, puis cliquez sur Ajouter une règle de groupe de sécurité :

Champ

Valeur

Action

Autoriser

Protocol

TCP personnalisé

Destination (Current Instance)

HTTPS (443)

Source

0.0.0.0/0 (partout)

Ouvrir le port 443 dans votre pare-feu système

Exécutez la commande suivante pour identifier votre pare-feu actif :

if command -v systemctl >/dev/null 2>&1 && systemctl is-active --quiet firewalld; then
    echo "firewalld"
elif command -v ufw >/dev/null 2>&1 && sudo ufw status | grep -qw active; then
    echo "ufw"
elif command -v nft >/dev/null 2>&1 && sudo nft list ruleset 2>/dev/null | grep -q 'table'; then
    echo "nftables"
elif command -v systemctl >/dev/null 2>&1 && systemctl is-active --quiet iptables; then
    echo "iptables"
elif command -v iptables >/dev/null 2>&1 && sudo iptables -L 2>/dev/null | grep -qE 'REJECT|DROP|ACCEPT'; then
    echo "iptables"
else
    echo "none"
fi

Si la sortie affiche none , aucune action relative au pare-feu n'est requise. Sinon, exécutez la commande correspondant à votre type de pare-feu :

firewalld

sudo firewall-cmd --permanent --add-port=443/tcp && sudo firewall-cmd --reload

ufw

sudo ufw allow 443/tcp

nftables

sudo nft add table inet filter 2>/dev/null
sudo nft add chain inet filter input '{ type filter hook input priority 0; }' 2>/dev/null
sudo nft add rule inet filter input tcp dport 443 counter accept 2>/dev/null

iptables

sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Pour rendre les règles iptables persistantes après un redémarrage :

  • RHEL/CentOS :

    sudo yum install -y iptables-services
    sudo service iptables save
  • Debian/Ubuntu :

    sudo apt-get install -y iptables-persistent
    sudo iptables-save | sudo tee /etc/iptables/rules.v4 >/dev/null

Étape 3 : Installer le certificat SSL sur Nginx

Installer le module SSL

Exécutez la commande suivante. Si la sortie affiche --with-http_ssl_module , le module SSL est déjà installé et vous pouvez passer directement à la section Configurer le certificat SSL.

nginx -V 2>&1 | grep -o -- '--with-http_ssl_module'
Si le système renvoie nginx: command not found , utilisez le chemin d'installation complet, par exemple : /usr/local/nginx/sbin/nginx -V 2>&1 | grep -o -- '--with-http_ssl_module' .

Si le module SSL est absent, installez-le en utilisant l'une des méthodes ci-dessous, selon la manière dont Nginx a été installé.

Important

L'ajout du module SSL peut interrompre brièvement le service Nginx. Sauvegardez votre configuration et vos données Nginx au préalable, et effectuez cette modification pendant les heures creuses.

Utilisation d'un gestionnaire de packages

Exécutez les commandes suivantes dans le terminal de votre serveur :

RHEL/CentOS

# Add the official Nginx repository.
sudo tee /etc/yum.repos.d/nginx.repo <<EOF
[nginx-stable]
name=nginx stable repo
baseurl=https://nginx.org/packages/centos/\$releasever/\$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
EOF

# Upgrade Nginx.
sudo yum upgrade nginx

Debian/Ubuntu

# Upgrade Nginx.
sudo apt-get update
sudo apt-get install --only-upgrade nginx

Compilation depuis les sources

  1. Installez les dépendances de compilation.

    RHEL/CentOS

    sudo yum install -y gcc pcre-devel zlib-devel openssl-devel

    Debian/Ubuntu

    sudo apt-get update
    sudo apt-get install -y build-essential libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev
  2. Enregistrez les paramètres de compilation actuels.

    nginx -V

    Copiez tous les paramètres affichés après configure arguments: . Vous en aurez besoin à l'étape 4.

  3. Téléchargez le code source de votre version actuelle de Nginx. Exécutez nginx -v pour vérifier la version (1.14.2 est utilisé à titre d'exemple). Ensuite, téléchargez et extrayez le package source :

    wget http://nginx.org/download/nginx-1.14.2.tar.gz
    tar -zxvf nginx-1.14.2.tar.gz
    cd nginx-1.14.2
  4. Recompilez Nginx avec le module SSL. Ajoutez --with-http_ssl_module aux paramètres que vous avez enregistrés et recompilez :

    Si vous rencontrez l'erreur error: 'ENGINE_by_id' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] , exécutez plutôt make CFLAGS='-Wno-error=deprecated-declarations' .
    # Keep all original parameters to avoid losing existing modules.
    ./configure <Original parameters> --with-http_ssl_module
    make
  5. Remplacez le binaire Nginx. Sauvegardez le binaire d'origine (en utilisant /usr/local/nginx/sbin/nginx à titre d'exemple) :

    # Replace /usr/local/nginx/sbin/nginx with the actual path to your nginx binary.
    sudo cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak

    Écrasez-le avec le binaire nouvellement compilé :

    # Replace /usr/local/nginx/sbin/nginx with the actual path to your nginx binary.
    sudo cp objs/nginx /usr/local/nginx/sbin/nginx
  6. Vérifiez que le module SSL est installé.

    nginx -V 2>&1 | grep -o -- '--with-http_ssl_module'

    La sortie --with-http_ssl_module confirme que le module est installé.

Configurer le certificat SSL

Important

Les étapes suivantes utilisent Nginx 1.14.2 et le fichier de configuration /etc/nginx/nginx.conf à titre d'exemple. Pour identifier le fichier de configuration actif sur votre serveur, consultez la section Comment trouver le fichier de configuration Nginx actif ?

  1. Ouvrez le fichier de configuration. Vous pouvez personnaliser les noms de fichiers et les chemins de stockage du fichier de certificat (.pem ou .crt) ainsi que du fichier de clé privée (.key). Assurez-vous que les chemins indiqués dans la configuration Nginx sont corrects et que le processus Nginx dispose des autorisations de lecture sur ces fichiers.

    sudo vim /etc/nginx/nginx.conf
  2. Ajoutez un bloc server pour le HTTPS. Copiez le bloc server existant qui écoute sur le port 80, remplacez listen 80 par listen 443 ssl, puis ajoutez les directives SSL indiquées ci-dessous. Conservez tous les autres paramètres tels quels.

    # Original server block listening on port 80
    server {
        listen 80;
        server_name yourdomain www.yourdomain;
    
        # Other configurations
        location / {
            proxy_pass http://127.0.0.1:8000;
        }
    }
    
    # New server block for HTTPS.
    server {
        # Change the original 'listen 80' to 'listen 443 ssl'.
        listen 443 ssl;
        # Original server_name. You can add more domain names supported by the current certificate.
        server_name yourdomain www.yourdomain;
    
        # ======================= Start of certificate configuration =======================
        # Specify the certificate file (the intermediate certificate can be appended to this .pem file). Replace /etc/ssl/cert/ssl.pem with the absolute path of your certificate file.
        ssl_certificate /etc/ssl/cert/ssl.pem;
        # Specify the private key file. Replace /etc/ssl/cert/ssl.key with the absolute path of your private key file.
        ssl_certificate_key /etc/ssl/cert/ssl.key;
        # Configure the SSL session cache to improve performance.
        ssl_session_cache shared:SSL:1m;
        # Set the SSL session timeout period.
        ssl_session_timeout 5m;
        # Customize the TLS protocol types and cipher suites to use (the following is an example configuration; evaluate whether you need to configure it).
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
        # Specify the allowed TLS protocol versions. Higher TLS versions provide better security for HTTPS communication, but have poorer browser compatibility than lower TLS versions.
        ssl_protocols TLSv1.2 TLSv1.3;
        # Prioritize the cipher suites specified by the server.
        ssl_prefer_server_ciphers on;
        # ======================= End of certificate configuration =======================
    
        # Other configurations
    }
  3. (Facultatif) Redirigez le HTTP vers le HTTPS. Ajoutez la directive return au bloc server du port 80.

    # Original server block listening on port 80
    server {
        listen 80;
        server_name yourdomain www.yourdomain;
    
        # Redirect all HTTP traffic to HTTPS.
        return 301 https://$host$request_uri;
    
        # Other original configurations can be removed as they will no longer be reached.
    }
  4. (Facultatif) Configurez les chemins d'accès aux certificats lorsque le service web Nginx ou Tengine s'exécute dans un conteneur Docker.

    Un conteneur possède son propre système de fichiers, isolé de celui du serveur hôte ; Nginx ne peut donc pas lire directement les fichiers de certificat depuis un chemin de l'hôte. Montez le certificat numérique (fichier .pem

    Pourquoi c'est important

    Comment l'appliquer

    Exécuter en tant qu'utilisateur non root

    Limiter l'impact d'un incident de sécurité

    Créer un utilisateur système dédié avec des privilèges réduits pour l'application

    Terminer le SSL au niveau de la passerelle

    Simplifier la gestion des certificats et réduire la complexité du backend

    Déployer le certificat sur un Server Load Balancer (SLB). Le SLB termine le HTTPS et transfère le HTTP en clair vers le backend

    Externaliser les secrets

    Empêcher la fuite d'identifiants via le code source ou les fichiers de configuration

    Utiliser des variables d'environnement, HashiCorp Vault ou Alibaba Cloud Key Management Service au lieu de coder en dur les mots de passe

    Forcer la redirection HTTP vers HTTPS

    Prévenir les attaques de type « man-in-the-middle » sur le trafic non chiffré

    Ajouter return 301 https://$host$request_uri; au bloc server du port 80

    Désactiver les versions TLS non sécurisées

    SSLv3, TLSv1.0 et TLSv1.1 sont vulnérables à des attaques connues

    Définir ssl_protocols TLSv1.2 TLSv1.3; dans la configuration Nginx

    Surveiller les certificats et les renouveler à temps

    Un certificat expiré interrompt le HTTPS pour tous les utilisateurs

    Activer la surveillance des domaines. Alibaba Cloud vérifie la validité des certificats et envoie des rappels de renouvellement avant l'expiration. Consultez la section Acheter et activer la surveillance publique des noms de domaine

FAQ

Pourquoi le HTTPS est-il inaccessible après l'installation ?

Vérifiez les points suivants dans l'ordre :

  • Le port 443 est bloqué — Le groupe de sécurité ou le pare-feu n'autorise pas le trafic entrant sur le port 443. Consultez la section Ouvrir le port 443.

  • Incompatibilité de domaine — Le domaine auquel vous accédez ne figure pas dans la liste des Domaines liés du certificat. Consultez le tableau de couverture des domaines dans la section Prérequis.

  • Nginx non rechargé — La configuration n'a pas été rechargée après les modifications. Exécutez sudo nginx -s reload.

  • Chemins de fichiers incorrects — Les directives ssl_certificate ou ssl_certificate_key pointent vers des chemins incorrects. Vérifiez les chemins absolus de vos fichiers .pem et .key.

  • Certificat absent sur les services en amont — Si votre domaine transite par un Content Delivery Network (CDN), un Server Load Balancer (SLB) ou un Web Application Firewall (WAF), le certificat doit également être installé sur ces services. Consultez la section Emplacements de déploiement des certificats lorsque le trafic traverse plusieurs services Alibaba Cloud.

  • Certificat non déployé sur tous les serveurs — Si le DNS du domaine résout vers plusieurs serveurs, installez le certificat sur chacun d'eux.

Pour obtenir de l'aide supplémentaire, consultez les sections Résoudre les problèmes de déploiement de certificats en fonction des messages d'erreur du navigateur et Guide de dépannage du déploiement de certificats SSL .

Comment mettre à jour ou remplacer un certificat SSL sans interruption de service ?

  1. Sauvegardez les fichiers .pem et .key actuels sur le serveur.

  2. Téléchargez le nouveau certificat et la nouvelle clé privée depuis la console Certificate Management Service.

  3. Téléchargez les nouveaux fichiers sur le serveur en remplaçant les existants. Utilisez exactement les mêmes chemins et noms de fichiers que ceux référencés dans votre configuration Nginx.

  4. Rechargez Nginx : sudo nginx -s reload.

Comment trouver le fichier de configuration Nginx actif (nginx.conf) sur un serveur Linux ?

  1. Exécutez ps -ef | grep '[n]ginx: master' | grep -- ' -c '. Si la sortie contient quelque chose comme -c /etc/nginx/custom.conf, Nginx utilise ce fichier de configuration personnalisé.

  2. Si l'étape 1 ne renvoie aucune sortie, Nginx utilise son chemin compilé par défaut. Exécutez nginx -V 2>&1 | grep -oP -- '--conf-path=[^ ]*' pour afficher le chemin par défaut, par exemple --conf-path=/etc/nginx/nginx.conf.

Comment désactiver TLSv1.0 et TLSv1.1 pour corriger les avertissements « le certificat ne respecte pas les normes » ?

Définissez la directive ssl_protocols dans votre configuration Nginx comme suit :

ssl_protocols TLSv1.2 TLSv1.3;

Cela désactive les protocoles non sécurisés TLSv1.0 et TLSv1.1. Après avoir enregistré le fichier, exécutez nginx -s reload pour appliquer la modification.

Pourquoi nginx -t échoue-t-il avec l'erreur bind() to 0.0.0.0:443 failed (98: Address already in use) ?

Un autre processus écoute déjà sur le port 443. Exécutez sudo ss -tlnp | grep :443 pour l'identifier. Arrêtez ensuite le processus conflictuel (tel qu'un autre serveur web ou une instance Nginx bloquée) ou reconfigurez-le pour utiliser un port différent.

Pourquoi nginx -t échoue-t-il avec l'erreur cannot load certificate "/etc/nginx/ssl/domain.pem": BIO_new_file() failed ?

Nginx ne trouve pas le fichier de certificat au chemin spécifié dans votre configuration. Corrigez la directive ssl_certificate dans nginx.conf pour qu'elle pointe vers le chemin absolu réel de votre fichier .pem.

Pourquoi le rechargement de Nginx échoue-t-il avec l'erreur the "ssl" parameter requires ngx_http_ssl_module ?

La compilation de Nginx ne comprend pas le module SSL. Installez ou recompiles Nginx avec le module ngx_http_ssl_module activé. Consultez la section Installer le module SSL.

Pourquoi obtenez-vous l'erreur No such file or directory: fopen('/cert/3970497_demo.aliyundoc.com.pem','r') lors du rechargement de Nginx ?

Le chemin spécifié pour ssl_certificate ou ssl_certificate_key est incorrect. Vérifiez que les chemins indiqués dans votre configuration sont des chemins absolus corrects et que les fichiers existent bien à ces emplacements.

Pourquoi Nginx ne parvient-il pas à lire les fichiers de certificat SSL avec une erreur permission denied ?

L'utilisateur du processus worker Nginx ne dispose pas d'un accès en lecture aux fichiers de certificat.

  1. Identifiez l'utilisateur worker Nginx : recherchez la directive user dans nginx.conf (par exemple, user nginx;).

  2. Accordez à cet utilisateur l'autorisation de lecture (r) sur les fichiers de certificat et de clé privée, ainsi que l'autorisation d'exécution (x) sur tous les répertoires parents du chemin.

Nginx 1.2 prend-il en charge les certificats téléchargés depuis SSL Certificate Management V2.0 ?

Oui. Les certificats émis via SSL Certificate Management V2.0 sont identiques à ceux émis via V1.0. La seule différence réside dans la méthode d'achat.