Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Configuration de HTTPS pour votre environnement Elastic Beanstalk
Les rubriques de cette section expliquent comment configurer le protocole HTTPS pour votre environnement Elastic Beanstalk. HTTPS est une nécessité pour n'importe quelle application qui transmet des informations de connexion ou des données utilisateur.
Si vous avez acheté et configuré un [nom de domaine personnalisé](customdomains.md) pour votre environnement Elastic Beanstalk, vous pouvez utiliser HTTPS pour permettre aux utilisateurs de se connecter à votre site web en toute sécurité.
Si vous ne possédez pas un nom de domaine, vous pouvez toujours utiliser HTTPS avec un certificat auto-signé à des fins de développement et de test. Pour de plus amples informations, veuillez consulter [Certificats de serveur](configuring-https.certificate.md).
**Configuration de la terminaison HTTPS au niveau de l'équilibreur de charge**
Un équilibreur de charge distribue les demandes aux instances EC2 qui exécutent votre application. De plus, l'équilibreur de charge vous évite d'exposer directement vos instances sur Internet. Le moyen le plus simple d'utiliser le protocole HTTPS dans un environnement multi-instance Elastic Beanstalk consiste à configurer un écouteur sécurisé pour l'équilibreur de charge. La connexion entre le client et l'équilibreur de charge reste sécurisée. Vous pouvez donc configurer l'équilibreur de charge pour mettre fin au protocole HTTPS. Les connexions principales entre l'équilibreur de charge et les instances EC2 utilisent le protocole HTTP. Aucune configuration supplémentaire des instances n'est donc requise. Pour obtenir des instructions détaillées sur la configuration d'un écouteur sécurisé, consultez[Configuration de la terminaison HTTPS au niveau de l'équilibreur de charge](configuring-https-elb.md).
**Configuration de la terminaison HTTPS sur l'instance EC2**
Si vous exécutez votre application dans un environnement d'instance unique, ou que vous avez besoin de sécuriser la connexion intégralement vers les instances EC2 derrière l'équilibreur de charge, vous pouvez configurer le serveur proxy qui s'exécute sur l'instance pour résilier HTTPS. La configuration de vos instances pour résilier des connexions HTTPS nécessite l'utilisation de [fichiers de configuration](ebextensions.md) pour modifier le logiciel s'exécutant sur les instances et pour modifier les groupes de sécurité pour autoriser des connexions sécurisées. Pour de plus amples informations, veuillez consulter [Configuration de la terminaison HTTPS sur l'instance](https-singleinstance.md).
**Configuration du protocole HTTPS end-to-end**
Pour le end-to-end protocole HTTPS dans un environnement d'équilibrage de charge, vous pouvez combiner la terminaison de l'instance et de l'équilibreur de charge pour chiffrer les deux connexions. Par défaut, si vous configurez l'équilibreur de charge pour acheminer le trafic à l'aide de HTTPS, il va faire confiance à n'importe quel certificat qui lui est présenté par les instances backend. Pour une sécurité optimale, vous pouvez attacher des stratégies à l'équilibreur de charge qui l'empêchent de se connecter aux instances qui ne présentent pas un certificat public auquel il fait confiance. Pour de plus amples informations, veuillez consulter [Configuration du end-to-end chiffrement dans un environnement Elastic Beanstalk à charge équilibrée](configuring-https-endtoend.md).
**Configuration du protocole HTTPS avec TCP Passthrough**
Vous pouvez également configurer l'équilibreur de charge pour relayer le trafic HTTPS sans le déchiffrer. Pour de plus amples informations, veuillez consulter [Configuration de l'équilibreur de charge de votre environnement pour TCP Passthrough](https-tcp-passthrough.md).
**Note**
[Est-ce qu'il y a des serpents ?](https://github.com/awslabs/eb-tomcat-snakes) Un exemple d'application GitHub inclut des fichiers de configuration et des instructions pour chaque méthode de configuration du protocole HTTPS avec une application Web Tomcat. Consultez le [fichier readme](https://github.com/awslabs/eb-tomcat-snakes/blob/master/README.md) et les [instructions HTTPS](https://github.com/awslabs/eb-tomcat-snakes/blob/master/src/.ebextensions/inactive/HTTPS.md) pour plus de détails.
**Topics**
+ [
# Certificats de serveur
](configuring-https.certificate.md)
+ [
# Configuration de la terminaison HTTPS au niveau de l'équilibreur de charge
](configuring-https-elb.md)
+ [
# Configuration de la terminaison HTTPS sur l'instance
](https-singleinstance.md)
+ [
# Configuration du end-to-end chiffrement dans un environnement Elastic Beanstalk à charge équilibrée
](configuring-https-endtoend.md)
+ [
# Configuration de l'équilibreur de charge de votre environnement pour TCP Passthrough
](https-tcp-passthrough.md)
+ [
# Configuration de la redirection HTTP vers HTTPS
](configuring-https-httpredirect.md)
# Certificats de serveur
Cette rubrique décrit les différents types de certificats que vous pouvez utiliser pour configurer le protocole HTTPS et les circonstances dans lesquelles ils doivent être appliqués. Les sous-rubriques de cette section fournissent des instructions pour créer votre propre certificat et comment le télécharger.
**AWS Certificate Manager (ACM)**
ACM est l'outil préféré pour mettre en service, gérer et déployer vos certificats de serveur. Vous pouvez le faire par programmation ou à l'aide du. AWS CLI Avec ACM, vous pouvez créer gratuitement un certificat fiable pour vos noms de domaine.
Les certificats ACM ne peuvent être utilisés qu'avec les équilibreurs de AWS charge et les CloudFront distributions Amazon, et ACM n'est disponible que dans certaines régions. AWS Pour utiliser un certificat ACM avec Elastic Beanstalk, veuillez consulter [Configuration de la terminaison HTTPS au niveau de l'équilibreur de charge](configuring-https-elb.md). Pour plus d'informations sur ACM, consultez le [https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html).
**Note**
Pour obtenir la liste des régions dans lesquelles ACM est disponible, consultez la section [Points de terminaison et quotas ACM](https://docs.aws.amazon.com/general/latest/gr/acm.html) dans le. *Référence générale d'Amazon Web Services*
Si ACM n'est pas disponible dans votre AWS région, vous pouvez télécharger un certificat tiers ou auto-signé et une clé privée vers Gestion des identités et des accès AWS (IAM). Vous pouvez utiliser le AWS CLI pour télécharger le certificat. Les certificats stockés dans IAM peuvent être utilisés avec les équilibreurs de charge et CloudFront les distributions. Pour de plus amples informations, veuillez consulter [Chargement d'un certificat dans IAM](configuring-https-ssl-upload.md).
**Certificat d'une tierce partie**
Si ACM n'est pas disponible dans votre région, vous pouvez acheter un certificat de confiance auprès d'un tiers. Un certificat tiers peut être utilisé pour déchiffrer le trafic HTTPS au niveau de votre équilibreur de charge, sur les instances backend, ou les deux.
**Certificat auto-signé**
Pour le développement et les tests, vous pouvez [créer et signer un certificat](configuring-https-ssl.md) vous-même avec des outils open source. Les certificats auto-signés sont gratuits et faciles à créer, mais ne peuvent pas être utilisés pour le déchiffrement frontal sur les sites publics. Si vous essayez d'utiliser un certificat auto-signé pour une connexion HTTPS à un client, le navigateur de l'utilisateur affiche une erreur indiquant que votre site web n'est pas sécurisé. Vous pouvez, toutefois, utiliser un certificat auto-signé pour sécuriser les connexions backend sans problème.
# Création et signature d'un certificat X509
Vous pouvez créer un certificat X509 pour votre application avec `OpenSSL`. OpenSSL est une bibliothèque open source standard qui prend en charge un large éventail de fonctions de chiffrement, dont la création et la signature de certificats X509. Pour plus d'informations sur OpenSSL, consultez le site [http://www.openssl.org](https://www.openssl.org/).
**Note**
Vous ne devez créer un certificat localement que si vous souhaitez [utiliser HTTPS dans un environnement à instance unique](https-singleinstance.md) ou [effectuer un nouveau chiffrement sur le backend](configuring-https-endtoend.md) avec un certificat auto-signé. Si vous possédez un nom de domaine, vous pouvez créer un certificat AWS et l'utiliser gratuitement dans un environnement à charge équilibrée en utilisant AWS Certificate Manager (ACM). Pour obtenir les instructions, consultez [Demande de certificat](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request.html) dans le *Guide de l'utilisateur AWS Certificate Manager *.
Exécutez `openssl version` dans la ligne de commande pour voir si OpenSSL est déjà installé. Si ce n'est pas le cas, vous pouvez créer et installer le code source en suivant les instructions du [ GitHub dépôt public](https://github.com/openssl/openssl) ou utiliser votre gestionnaire de paquets préféré. [OpenSSL étant également installé sur les images Linux d'Elastic Beanstalk, une alternative rapide consiste à se connecter à une instance dans un environnement d'exécution à l'aide de la commande de l'EB CLI : EC2 ](eb-cli3.md) **eb ssh**
```
~/eb$ eb ssh
[ec2-user@ip-255-55-55-255 ~]$ openssl version
OpenSSL 1.0.1k-fips 8 Jan 2015
```
Vous devez créer une clé privée RSA pour générer votre demande de signature de certificat (CSR). Pour créer votre clé privée, utilisez la commande **openssl genrsa** :
```
[ec2-user@ip-255-55-55-255 ~]$ openssl genrsa 2048 > privatekey.pem
Generating RSA private key, 2048 bit long modulus
.................................................................................................................................+++
...............+++
e is 65537 (0x10001)
```
*privatekey.pem*
Nom du fichier dans lequel vous souhaitez enregistrer la clé privée. Généralement, la commande **openssl genrsa** affiche le contenu de la clé privée à l'écran, mais cette commande redirige le résultat vers un fichier. Choisissez un nom de fichier et stockez le fichier dans un emplacement sécurisé de façon à pouvoir le récupérer ultérieurement. Si vous perdez votre clé privée, vous ne pourrez pas utiliser votre certificat.
Un fichier CSR est un fichier que vous pouvez envoyer à une autorité de certification (CA) pour demander un certificat de serveur numérique. Pour créer un fichier CSR, utilisez la commande **openssl req** :
```
$ openssl req -new -key privatekey.pem -out csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
```
Saisissez les informations demandées et appuyez sur **Entrée**. Le tableau suivant décrit les champs et fournit des exemples pour chacun d'entre eux.
****
| Nom | Description | Exemple |
| --- | --- | --- |
| Nom du pays | Abréviation ISO de deux lettres de votre pays. | US = États-Unis |
| État ou Province | Nom de l’état ou de la province où votre organisation se situe. Vous ne pouvez pas abréger ce nom. | Washington |
| Nom de la localité | Nom de la ville où votre organisation se situe. | Seattle |
| Nom de l’organisation | Nom légal complet de votre organisation. N’abrégez pas le nom de votre organisation. | Exemple d’entreprise |
| Unité organisationnelle | (Facultatif) Informations supplémentaires sur l'organisation. | Marketing |
| Nom commun | Nom de domaine complet de votre site web. Il doit correspondre au nom de domaine que les utilisateurs voient lorsqu'ils visitent votre site (sinon, des erreurs de certificat s'affichent). | www.exemple.com |
| Adresse e-mail | Adresse e-mail de l'administrateur du site. | quelquun@exemple.com |
Vous pouvez envoyer la demande de signature à un tiers pour la signature, ou la signer vous-même à des fins de test et de développement. Les certificats auto-signés peuvent également être utilisés pour le protocole HTTPS principal entre un équilibreur de charge et des instances. EC2
Pour signer le certificat, utilisez la commande **openssl x509**. L'exemple suivant utilise la clé privée de l'étape précédente (*privatekey.pem*) et la demande de signature (*csr.pem*) pour créer un certificat public nommé *public.crt* valide pendant des *365* jours.
```
$ openssl x509 -req -days 365 -in csr.pem -signkey privatekey.pem -out public.crt
Signature ok
subject=/C=us/ST=washington/L=seattle/O=example corporation/OU=marketing/CN=www.example.com/emailAddress=someone@example.com
Getting Private key
```
Conservez la clé privée et le certificat public pour une utilisation ultérieure. Vous pouvez supprimer la demande de signature. Veillez à toujours [stocker la clé privée dans un emplacement sécurisé](https-storingprivatekeys.md) et à ne pas l'ajouter à votre code source.
Pour utiliser le certificat avec la plateforme Windows Server, vous devez le convertir au format PFX. Utilisez la commande suivante pour créer un certificat PFX à partir de la clé privée et des fichiers de certificat public :
```
$ openssl pkcs12 -export -out example.com.pfx -inkey privatekey.pem -in public.crt
Enter Export Password: password
Verifying - Enter Export Password: password
```
Maintenant que vous disposez d'un certificat, vous pouvez [le charger dans IAM](configuring-https-ssl-upload.md) pour l'utiliser avec un équilibreur de charge, ou [configurer les instances de votre environnement pour suspendre HTTPS](https-singleinstance.md).
# Chargement d'un certificat dans IAM
Pour utiliser votre certificat avec l'équilibreur de charge de votre environnement Elastic Beanstalk, téléchargez le certificat et la clé privée vers (IAM). Gestion des identités et des accès AWS Vous pouvez utiliser un certificat stocké dans IAM avec les équilibreurs de charge Elastic Load Balancing et les distributions Amazon CloudFront .
**Note**
AWS Certificate Manager (ACM) est l'outil préféré pour approvisionner, gérer et déployer vos certificats de serveur. Pour plus d'informations sur une demande de certificat ACM, consultez [Request a Certificate](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request.html) (Demande de certificat) dans le *AWS Certificate Manager User Guide* (Guide de l'utilisateur AWS Certificate Manager ). Pour plus d'informations sur l'importation de certificats tiers dans ACM, consultez [Importing Certificates](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) (Importation de certificats) dans le *AWS Certificate Manager User Guide* (Guide de l'utilisateur AWS Certificate Manager ). Utilisez IAM pour télécharger un certificat uniquement si ACM n'est pas [disponible dans votre AWS région](https://docs.aws.amazon.com/general/latest/gr/acm.html).
Vous pouvez utiliser le AWS Command Line Interface (AWS CLI) pour télécharger votre certificat. La commande suivante télécharge un certificat auto-signé nommé *https-cert.crt* avec une clé privée nommée : *private-key.pem*
```
$ aws iam upload-server-certificate --server-certificate-name elastic-beanstalk-x509 --certificate-body file://https-cert.crt --private-key file://private-key.pem
{
"ServerCertificateMetadata": {
"ServerCertificateId": "AS5YBEIONO2Q7CAIHKNGC",
"ServerCertificateName": "elastic-beanstalk-x509",
"Expiration": "2017-01-31T23:06:22Z",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:server-certificate/elastic-beanstalk-x509",
"UploadDate": "2016-02-01T23:10:34.167Z"
}
}
```
Le `file://` préfixe indique de AWS CLI charger le contenu d'un fichier dans le répertoire courant. *elastic-beanstalk-x509*spécifie le nom pour appeler le certificat dans IAM.
Si vous avez acheté un certificat auprès d'une autorité de certification et reçu un fichier de chaîne de certificats, chargez-le également en incluant l'option `--certificate-chain` :
```
$ aws iam upload-server-certificate --server-certificate-name elastic-beanstalk-x509 --certificate-chain file://certificate-chain.pem --certificate-body file://https-cert.crt --private-key file://private-key.pem
```
Notez l'Amazon Resource Name (ARN) de votre certificat. Vous l'utiliserez lors de la mise à jour des paramètres de configuration de votre équilibreur de charge pour utiliser HTTPS.
**Note**
Un certificat chargé dans IAM reste stocké même s'il n'est plus utilisé dans aucun équilibreur de charge de l'environnement. Il contient des données sensibles. Lorsque vous n'avez plus besoin du certificat pour aucun environnement, veillez à le supprimer. Pour de plus amples informations sur la suppression d'un certificat dans IAM, veuillez consulter [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-certs.html#delete-server-certificate](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-certs.html#delete-server-certificate).
Pour de plus amples informations sur les certificats de serveur dans IAM, veuillez consulter [Utilisation des certificats de serveur](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-certs.html) dans le *Guide de l'utilisateur IAM*.
# Stockage sécurisé des clés privées dans Amazon S3
La clé privée qui vous permet de vous connecter à votre certificat public est privée et ne doit pas être validée dans le code source. Vous pouvez éviter de stocker les clés privées dans les fichiers de configuration en les chargeant dans Amazon S3 et en configurant Elastic Beanstalk pour télécharger le fichier à partir d'Amazon S3 lors du déploiement de l'application.
L'exemple suivant décrit les sections [Ressources](environment-resources.md)et [fichiers](customize-containers-ec2.md#linux-files) d'un [fichier de configuration](ebextensions.md), qui télécharge un fichier de clé privée à partir d'un compartiment Amazon S3.
**Example .ebextensions/privatekey.config**
```
Resources:
AWSEBAutoScalingGroup:
Metadata:
AWS::CloudFormation::Authentication:
S3Auth:
type: "s3"
buckets: ["elasticbeanstalk-us-west-2-123456789012"]
roleName:
"Fn::GetOptionSetting":
Namespace: "aws:autoscaling:launchconfiguration"
OptionName: "IamInstanceProfile"
DefaultValue: "aws-elasticbeanstalk-ec2-role"
files:
# Private key
"/etc/pki/tls/certs/server.key":
mode: "000400"
owner: root
group: root
authentication: "S3Auth"
source: https://elasticbeanstalk-us-west-2-123456789012.s3.us-west-2.amazonaws.com/server.key
```
Remplacez l'URL et le nom de compartiment figurant dans l'exemple par vos propres valeurs. La première entrée du fichier ajoute une méthode d'authentification nommée `S3Auth` aux métadonnées du groupe Auto Scaling de l'environnement. Si vous avez configuré un [profil d'instance](concepts-roles-instance.md) personnalisé pour votre environnement, il est utilisé. Sinon, c'est la valeur par défaut du fichier `aws-elasticbeanstalk-ec2-role` qui s'applique. Le profil d'instance par défaut est autorisé à lire les données du compartiment de stockage Elastic Beanstalk. Si vous utilisez un autre compartiment, [ajoutez des autorisations au profil d'instance](iam-instanceprofile.md#iam-instanceprofile-addperms).
La deuxième entrée utilise la méthode d'authentification `S3Auth` pour télécharger la clé privée à partir de l'URL spécifiée et pour l'enregistrer dans `/etc/pki/tls/certs/server.key`. Le serveur proxy peut ensuite lire la clé privée à partir de cet emplacement afin de [mettre les connexions HTTPS hors service dans l'instance](https-singleinstance.md).
Le profil d'instance attribué aux EC2 instances de votre environnement doit être autorisé à lire l'objet clé dans le compartiment spécifié. [Assurez-vous que le profil d'instance est autorisé](iam-instanceprofile.md#iam-instanceprofile-verify) à lire l'objet dans IAM, et que les autorisations sur le compartiment et l'objet n'entraînent pas d'interdiction pour le profil d'instance.
**Pour afficher les autorisations d'un compartiment**
1. Ouvrez la [console de gestion Amazon S3](https://console.aws.amazon.com/s3/home).
1. Choisissez un compartiment.
1. Choisissez **Properties**, puis **Autorisations**.
1. Vérifiez que votre compte bénéficie d'une autorisation de lecture sur le compartiment.
1. Si une stratégie de compartiment est attachée, choisissez **Stratégie de compartiment** pour afficher les autorisations attribuées au compartiment.
# Configuration de la terminaison HTTPS au niveau de l'équilibreur de charge
Pour mettre à jour votre AWS Elastic Beanstalk environnement afin qu'il utilise le protocole HTTPS, vous devez configurer un écouteur HTTPS pour l'équilibreur de charge de votre environnement. Deux types d'équilibreur de charge prennent en charge un écouteur HTTPS : l'équilibreur Classic Load Balancer et l'équilibreur Application Load Balancer.
Vous pouvez utiliser la console Elastic Beanstalk ou un fichier de configuration pour configurer un écouteur sécurisé et attribuer le certificat.
**Note**
Les environnements d'instance unique n'ont pas d'équilibreur de charge et ne prennent pas en charge la terminaison HTTPS au niveau de l'équilibreur de charge.
## Configuration d'un écouteur sécurisé à l'aide de la console Elastic Beanstalk
**Pour attribuer un certificat à l'équilibreur de charge de votre environnement**
1. Ouvrez la console [Elastic Beanstalk](https://console.aws.amazon.com/elasticbeanstalk), puis **dans la liste des régions, sélectionnez votre**. Région AWS
1. Dans le panneau de navigation, choisissez **Environments** (Environnements), puis choisissez le nom de votre environnement dans la liste.
1. Dans le panneau de navigation, choisissez **Configuration**.
1. Dans la catégorie de configuration **Load balancer (Équilibreur de charge)**, choisissez **Edit (Modifier)**.
**Note**
Si la catégorie de configuration **Load balancer (Équilibreur de charge)** ne dispose pas du bouton **Edit (Modifier)**, cela signifie que votre environnement ne dispose pas d'un [équilibreur de charge](using-features-managing-env-types.md#using-features.managing.changetype).
1. Sur la page **Modifier l'équilibreur de charge**, la procédure varie selon le type d'équilibreur de charge associé à votre environnement.
+ **Equilibreur de charge classique**
1. Choisissez **Add listener** (Ajouter un écouteur).
1. Dans la boîte de dialogue **Classic Load Balancer listener (Écouteur Classic Load Balancer)**, configurez les paramètres suivants :
+ Pour **Port d'écoute**, tapez le port du trafic entrant, généralement `443`.
+ Pour **Protocole d'écoute**, choisissez **HTTPS**.
+ Pour **Port de l'instance**, tapez `80`.
+ Pour **Protocole de l'instance**, choisissez **HTTP**.
+ Pour **SSL Certificate** (Certificat SSL), sélectionnez votre certificat.
1. Cliquez sur **Add** (Ajouter).
+ **Application Load Balancer**
1. Choisissez **Add listener** (Ajouter un écouteur).
1. Dans la boîte de dialogue **Application Load Balancer listener (Écouteur de l'équilibreur Application Load Balancer)**, configurez les paramètres suivants :
+ Pour **Port**, tapez le port du trafic entrant, généralement `443`.
+ Pour **Protocole**, choisissez **HTTPS**.
+ Pour **SSL Certificate** (Certificat SSL), sélectionnez votre certificat.
1. Cliquez sur **Add** (Ajouter).
**Note**
Pour l'équilibreur Classic Load Balancer et l'équilibreur Application Load Balancer, si le menu déroulant n'affiche aucun certificat, vous devez créer ou charger un certificat pour votre [nom de domaine personnalisé](customdomains.md) dans [AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/) (de préférence). Vous pouvez également charger un certificat dans IAM à l'aide de l' AWS CLI.
+ **Network Load Balancer**
1. Choisissez **Add listener** (Ajouter un écouteur).
1. Dans la boîte de dialogue**Network Load Balancer listener (Écouteur de l'équilibreur Network Load Balancer)** pour **Port**, tapez le port de trafic entrant, généralement `443`.
1. Choisissez **Ajouter**.
1. Pour enregistrer les modifications, cliquez sur **Appliquer** en bas de la page.
## Configuration d'un écouteur sécurisé avec un fichier de configuration
Vous pouvez configurer un écouteur sécurisé sur votre équilibreur de charge avec un des [fichiers de configuration](ebextensions.md) suivants.
**Example .ebextensions/securelistener-clb.config**
Utilisez cet exemple lorsque votre environnement dispose d'un équilibreur Classic Load Balancer. L'exemple utilise des options dans l'espace de noms `aws:elb:listener` pour configurer un écouteur HTTPS sur le port 443 avec le certificat spécifié et pour transférer le trafic déchiffré vers les instances de votre environnement sur le port 80.
```
option_settings:
aws:elb:listener:443:
SSLCertificateId: arn:aws:acm:us-east-2:1234567890123:certificate/####################################
ListenerProtocol: HTTPS
InstancePort: 80
```
Remplacez le texte en surbrillance par l'ARN de votre certificat. Le certificat peut être un certificat que vous avez créé ou chargé dans AWS Certificate Manager (ACM) (de préférence), ou un certificat que vous avez chargé sur IAM avec le. AWS CLI
Pour de plus amples informations concernant les options de configuration d'un équilibreur Classic Load Balancer, veuillez consulter [Espaces de noms pour la configuration d'un Classic Load Balancer](environments-cfg-clb.md#environments-cfg-clb-namespace).
**Example .ebextensions/securelistener-alb.config**
Utilisez cet exemple lorsque votre environnement dispose d'un équilibreur Application Load Balancer. L'exemple utilise les options dans l'espace de noms `aws:elbv2:listener` pour configurer un écouteur HTTPS sur le port 443 avec le certificat spécifié. L'écouteur achemine le trafic vers le processus par défaut.
```
option_settings:
aws:elbv2:listener:443:
ListenerEnabled: 'true'
Protocol: HTTPS
SSLCertificateArns: arn:aws:acm:us-east-2:1234567890123:certificate/####################################
```
**Example .ebextensions/securelistener-nlb.config**
Utilisez cet exemple lorsque votre environnement dispose d'un équilibreur Network Load Balancer. L'exemple utilise les options dans l'espace de noms `aws:elbv2:listener` pour configurer un écouteur sur le port 443. L'écouteur achemine le trafic vers le processus par défaut.
```
option_settings:
aws:elbv2:listener:443:
ListenerEnabled: 'true'
```
## Configuration d'un groupe de sécurité
Si vous configurez votre équilibreur de charge pour transférer le trafic vers un port de l'instance autre que le port 80, vous devez ajouter une règle à votre groupe de sécurité autorisant le trafic entrant via le port de l'instance à partir de votre équilibreur de charge. Si vous créez votre environnement dans un VPC personnalisé, Elastic Beanstalk ajoute automatiquement cette règle.
Pour ajouter cette règle, ajoutez une clé `Resources` à un [fichier de configuration](ebextensions.md) dans le répertoire `.ebextensions` correspondant à votre application.
L'exemple de fichier de configuration suivante ajoute une règle de trafic entrant au groupe de sécurité `AWSEBSecurityGroup`. Cela permet le trafic sur le port 1000 à partir du groupe de sécurité de l'équilibreur de charge.
**Example .ebextensions/sg-ingressfromlb.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 1000
FromPort: 1000
SourceSecurityGroupId: {"Fn::GetAtt" : ["AWSEBLoadBalancerSecurityGroup", "GroupId"]}
```
# Configuration de la terminaison HTTPS sur l'instance
Vous pouvez utiliser des [fichiers de configuration](ebextensions.md) pour configurer le serveur proxy qui transmet le trafic à votre application afin de mettre des connexions HTTPS hors service. Cette opération est utile si vous souhaitez utiliser HTTPS avec un environnement d'instance unique ou si vous configurez votre équilibreur de charge pour transmettre le trafic sans le déchiffrer.
Pour activer le protocole HTTPS, vous devez autoriser le trafic entrant sur le port 443 à destination de l' EC2 instance sur laquelle s'exécute votre application Elastic Beanstalk. Pour ce faire, utilisez la `Resources` clé du fichier de configuration pour ajouter une règle pour le port 443 aux règles d'entrée du groupe de sécurité du AWSEBSecurity groupe.
L'extrait suivant ajoute une règle de trafic entrant au groupe de sécurité `AWSEBSecurityGroup` qui ouvre le port 443 pour tout le trafic, pour un environnement d'instance unique :
**`.ebextensions/https-instance-securitygroup.config`**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à charge équilibrée [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) (Amazon VPC) par défaut, vous pouvez modifier cette stratégie pour accepter uniquement le trafic provenant de l'équilibreur de charge. Consultez [Configuration du end-to-end chiffrement dans un environnement Elastic Beanstalk à charge équilibrée](configuring-https-endtoend.md) pour obtenir un exemple.
**Topics**
+ [
# Résiliation de connexions HTTPS sur des instances EC2 exécutant Docker
](https-singleinstance-docker.md)
+ [
# Résiliation du protocole HTTPS sur les EC2 instances exécutant Go
](https-singleinstance-go.md)
+ [
# Résiliation des connexions HTTPS sur des instances EC2 exécutant Java SE
](https-singleinstance-java.md)
+ [
# Suspension des connexions HTTPS sur des instances EC2 exécutant Node.js
](https-singleinstance-nodejs.md)
+ [
# Mettre fin au protocole HTTPS sur les EC2 instances exécutant PHP
](https-singleinstance-php.md)
+ [
# Suspension des connexions HTTPS sur des instances EC2 exécutant Python
](https-singleinstance-python.md)
+ [
# Suspension des connexions HTTPS sur des instances EC2 exécutant Ruby
](https-singleinstance-ruby.md)
+ [
# Suspension des connexions HTTPS sur des instances EC2 exécutant Tomcat
](https-singleinstance-tomcat.md)
+ [
# Résiliation des connexions HTTPS sur les instances Amazon EC2 exécutant .NET Core sous Linux
](https-singleinstance-dotnet-linux.md)
+ [
# Résiliation du protocole HTTPS sur les EC2 instances Amazon exécutant .NET
](SSLNET.SingleInstance.md)
# Résiliation de connexions HTTPS sur des instances EC2 exécutant Docker
Pour les conteneurs Docker, vous utilisez un [fichier de configuration](ebextensions.md) pour activer HTTPS.
Ajoutez l'extrait suivant à votre fichier de configuration, en remplaçant le certificat et la clé privée comme demandé, puis enregistrez-les dans le répertoire `.ebextensions` de votre bundle de fichiers source. Le fichier de configuration effectue les tâches suivantes :
+ La clé `files` crée les fichiers suivants sur l'instance :
`/etc/nginx/conf.d/https.conf`
Configure le serveur nginx. Ce fichier est chargé lorsque le service nginx démarre.
`/etc/pki/tls/certs/server.crt`
Crée le fichier de certificat sur l'instance. *certificate file contents*Remplacez-le par le contenu de votre certificat.
YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.
Si vous avez des certificats intermédiaires, incluez-les dans `server.crt` après votre certificat de site.
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
Crée le fichier de clé privée sur l'instance. *private key contents*Remplacez-le par le contenu de la clé privée utilisée pour créer la demande de certificat ou le certificat auto-signé.
**Example .ebextensions/https-instance.config**
```
files:
/etc/nginx/conf.d/https.conf:
mode: "000644"
owner: root
group: root
content: |
# HTTPS Server
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://docker;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
/etc/pki/tls/certs/server.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**Note**
Évitez de valider un fichier de configuration qui contient votre clé privée de contrôle de code source. Une fois que vous avez testé la configuration et vérifié qu'elle fonctionne, stockez votre clé privée dans Amazon S3 et modifiez la configuration pour la télécharger durant le déploiement. Pour obtenir des instructions, veuillez consulter [Stockage sécurisé des clés privées dans Amazon S3](https-storingprivatekeys.md).
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
# Résiliation du protocole HTTPS sur les EC2 instances exécutant Go
Pour les types de conteneurs Go, vous activez HTTPS avec un [fichier de configuration](ebextensions.md) et un fichier de configuration nginx qui configure le serveur nginx pour utiliser HTTPS.
Ajoutez l'extrait suivant à votre fichier de configuration, en remplaçant les espaces réservés pour le certificat et la clé privée comme demandé, puis enregistrez-le dans le répertoire `.ebextensions` de votre bundle de fichiers source. Le fichier de configuration effectue les tâches suivantes :
+ La clé `Resources` active le port 443 sur le groupe de sécurité utilisé par l'instance de votre environnement.
+ La clé `files` crée les fichiers suivants sur l'instance :
`/etc/pki/tls/certs/server.crt`
Crée le fichier de certificat sur l'instance. *certificate file contents*Remplacez-le par le contenu de votre certificat.
YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.
Si vous avez des certificats intermédiaires, incluez-les dans `server.crt` après votre certificat de site.
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
Crée le fichier de clé privée sur l'instance. *private key contents*Remplacez-le par le contenu de la clé privée utilisée pour créer la demande de certificat ou le certificat auto-signé.
**Example .ebextensions/https-instance.config**
```
files:
/etc/pki/tls/certs/server.crt:
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**Note**
Évitez de valider un fichier de configuration qui contient votre clé privée de contrôle de code source. Une fois que vous avez testé la configuration et vérifié qu'elle fonctionne, stockez votre clé privée dans Amazon S3 et modifiez la configuration pour la télécharger durant le déploiement. Pour obtenir des instructions, veuillez consulter [Stockage sécurisé des clés privées dans Amazon S3](https-storingprivatekeys.md).
Placez les éléments suivants dans un fichier avec l'extension `.conf` dans le répertoire `.ebextensions/nginx/conf.d/` de votre bundle de fichiers source (par exemple, `.ebextensions/nginx/conf.d/https.conf`). *app\$1port*Remplacez-le par le numéro de port que votre application écoute. Cet exemple configure le serveur nginx pour écouter sur le port 443 à l'aide de SSL. Pour plus d'informations sur ces fichiers de configuration sur la plateforme Go, consultez [Configuration du serveur proxy](go-nginx.md).
**Example . ebextensions/nginx/conf.d/https.conf**
```
# HTTPS server
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://localhost:app_port;
proxy_set_header Connection "";
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
```
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
# Résiliation des connexions HTTPS sur des instances EC2 exécutant Java SE
Pour les types de conteneurs Java SE, vous activez HTTPS avec un [fichier de configuration](ebextensions.md) .ebextensions, ainsi qu'un fichier de configuration nginx qui configure le serveur nginx pour utiliser HTTPS.
Toutes les AL2 plateformes AL2023/prennent en charge une fonctionnalité de configuration de proxy uniforme. Pour plus d'informations sur la configuration du serveur proxy sur les versions de votre plate-forme exécutant AL2023/AL2, consultez[Configuration du proxy inverse](platforms-linux-extend.proxy.md).
Ajoutez l'extrait suivant à votre fichier de configuration, en remplaçant les espaces réservés pour le certificat et la clé privée comme indiqué, puis enregistrez-le dans le répertoire `.ebextensions`. Le fichier de configuration effectue les tâches suivantes :
+ La clé `files` crée les fichiers suivants sur l'instance :
`/etc/pki/tls/certs/server.crt`
Crée le fichier de certificat sur l'instance. *certificate file contents*Remplacez-le par le contenu de votre certificat.
YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.
Si vous avez des certificats intermédiaires, incluez-les dans `server.crt` après votre certificat de site.
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
Crée le fichier de clé privée sur l'instance. *private key contents*Remplacez-le par le contenu de la clé privée utilisée pour créer la demande de certificat ou le certificat auto-signé.
**Example .ebextensions/https-instance.config**
```
files:
/etc/pki/tls/certs/server.crt:
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**Note**
Évitez de valider un fichier de configuration qui contient votre clé privée de contrôle de code source. Une fois que vous avez testé la configuration et vérifié qu'elle fonctionne, stockez votre clé privée dans Amazon S3 et modifiez la configuration pour la télécharger durant le déploiement. Pour obtenir des instructions, veuillez consulter [Stockage sécurisé des clés privées dans Amazon S3](https-storingprivatekeys.md).
Placez les éléments suivants dans un fichier avec l'extension `.conf` dans le répertoire `.ebextensions/nginx/conf.d/` de votre bundle de fichiers source (par exemple, `.ebextensions/nginx/conf.d/https.conf`). *app\$1port*Remplacez-le par le numéro de port que votre application écoute. Cet exemple configure le serveur nginx pour écouter sur le port 443 à l'aide de SSL. Pour plus d'informations sur ces fichiers de configuration sur la plateforme Java SE, consultez [Configuration du serveur proxy](java-se-nginx.md).
**Example . ebextensions/nginx/conf.d/https.conf**
```
# HTTPS server
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://localhost:app_port;
proxy_set_header Connection "";
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
```
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
# Suspension des connexions HTTPS sur des instances EC2 exécutant Node.js
L'exemple de fichier de configuration suivant [étend la configuration nginx par défaut](nodejs-platform-proxy.md) pour écouter sur le port 443 et SSL/TLS mettre fin aux connexions avec un certificat public et une clé privée.
Si vous avez configuré votre environnement pour les [rapports améliorés sur l'état](health-enhanced.md), vous devez configurer nginx pour générer les journaux d'accès. Pour ce faire, supprimez la mise en commentaire du bloc de lignes sous le commentaire où il est écrit `# For enhanced health...` en supprimant les caractères `#` de tête.
**Example .ebextensions/https-instance.config**
```
files:
/etc/nginx/conf.d/https.conf:
mode: "000644"
owner: root
group: root
content: |
# HTTPS server
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
# For enhanced health reporting support, uncomment this block:
#if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})T(\d{2})") {
# set $year $1;
# set $month $2;
# set $day $3;
# set $hour $4;
#}
#access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd;
#access_log /var/log/nginx/access.log main;
location / {
proxy_pass http://nodejs;
proxy_set_header Connection "";
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
/etc/pki/tls/certs/server.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
La clé `files` crée les fichiers suivants sur l'instance :
`/etc/nginx/conf.d/https.conf`
Configure le serveur nginx. Ce fichier est chargé lorsque le service nginx démarre.
`/etc/pki/tls/certs/server.crt`
Crée le fichier de certificat sur l'instance. *certificate file contents*Remplacez-le par le contenu de votre certificat.
YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.
Si vous avez des certificats intermédiaires, incluez-les dans `server.crt` après votre certificat de site.
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
Crée le fichier de clé privée sur l'instance. *private key contents*Remplacez-le par le contenu de la clé privée utilisée pour créer la demande de certificat ou le certificat auto-signé.
**Note**
Évitez de valider un fichier de configuration qui contient votre clé privée de contrôle de code source. Une fois que vous avez testé la configuration et vérifié qu'elle fonctionne, stockez votre clé privée dans Amazon S3 et modifiez la configuration pour la télécharger durant le déploiement. Pour obtenir des instructions, veuillez consulter [Stockage sécurisé des clés privées dans Amazon S3](https-storingprivatekeys.md).
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
# Mettre fin au protocole HTTPS sur les EC2 instances exécutant PHP
Pour les types de conteneurs PHP, vous utilisez un [fichier de configuration](ebextensions.md) pour permettre au serveur HTTP Apache d'utiliser HTTPS.
Ajoutez l'extrait suivant à votre fichier de configuration, en remplaçant le certificat et la clé privée comme demandé, puis enregistrez-les dans le répertoire `.ebextensions` de votre bundle de fichiers source.
Le fichier de configuration effectue les tâches suivantes :
+ La clé `packages` utilise yum pour installer `mod24_ssl`.
+ La clé `files` crée les fichiers suivants sur l'instance :
`/etc/httpd/conf.d/ssl.conf`
Configure le serveur Apache. Ce fichier se charge lorsque le service Apache démarre.
`/etc/pki/tls/certs/server.crt`
Crée le fichier de certificat sur l'instance. *certificate file contents*Remplacez-le par le contenu de votre certificat.
YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.
Si vous avez des certificats intermédiaires, incluez-les dans `server.crt` après votre certificat de site.
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
Crée le fichier de clé privée sur l'instance. *private key contents*Remplacez-le par le contenu de la clé privée utilisée pour créer la demande de certificat ou le certificat auto-signé.
**Example .ebextensions/https-instance.config**
```
packages:
yum:
mod24_ssl : []
files:
/etc/httpd/conf.d/ssl.conf:
mode: "000644"
owner: root
group: root
content: |
LoadModule ssl_module modules/mod_ssl.so
Listen 443
Order deny,allow
Allow from all
SSLEngine on
SSLCertificateFile "/etc/pki/tls/certs/server.crt"
SSLCertificateKeyFile "/etc/pki/tls/certs/server.key"
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLSessionTickets Off
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
ProxyPass / http://localhost:80/ retry=0
ProxyPassReverse / http://localhost:80/
ProxyPreserveHost on
RequestHeader set X-Forwarded-Proto "https" early
/etc/pki/tls/certs/server.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**Note**
Évitez de valider un fichier de configuration qui contient votre clé privée de contrôle de code source. Une fois que vous avez testé la configuration et vérifié qu'elle fonctionne, stockez votre clé privée dans Amazon S3 et modifiez la configuration pour la télécharger durant le déploiement. Pour obtenir des instructions, veuillez consulter [Stockage sécurisé des clés privées dans Amazon S3](https-storingprivatekeys.md).
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
# Suspension des connexions HTTPS sur des instances EC2 exécutant Python
Pour les types de conteneurs Python utilisant Apache HTTP Server avec l'interface WSGI (Web Server Gateway Interface), vous utilisez un [fichier de configuration](ebextensions.md) pour permettre l'Apache HTTP Server d'utiliser HTTPS.
Ajoutez l'extrait suivant à votre [fichier de configuration](ebextensions.md), en remplaçant le document certificat et clé privée comme demandé, puis enregistrez-le dans le répertoire `.ebextensions` de votre bundle source. Le fichier de configuration effectue les tâches suivantes :
+ La clé `packages` utilise yum pour installer `mod_ssl`.
+ La clé `files` crée les fichiers suivants sur l'instance :
`/etc/httpd/conf.d/ssl.conf`
Configure le serveur Apache. Si votre application n'est pas nommée `application.py`, remplacez le texte en surbrillance dans la valeur pour `WSGIScriptAlias` par le chemin d'accès local à votre application. Par exemple, une application Django peut être sur `django/wsgi.py`. L'emplacement doit correspondre à la valeur de l'option `WSGIPath` que vous avez définie pour votre environnement.
En fonction des besoins de votre application, vous aurez peut-être également besoin d'ajouter d'autres répertoires au paramètre **python-path**.
`/etc/pki/tls/certs/server.crt`
Crée le fichier de certificat sur l'instance. *certificate file contents*Remplacez-le par le contenu de votre certificat.
YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.
Si vous avez des certificats intermédiaires, incluez-les dans `server.crt` après votre certificat de site.
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
Crée le fichier de clé privée sur l'instance. *private key contents*Remplacez-le par le contenu de la clé privée utilisée pour créer la demande de certificat ou le certificat auto-signé.
+ La clé `container_commands` arrête le service httpd une fois que tout a été configuré de telle sorte que le service utilise le nouveau certificat et le nouveau fichier `https.conf`.
**Note**
L'exemple fonctionne uniquement dans des environnements utilisant la plateforme [Python](create-deploy-python-container.md).
**Example .ebextensions/https-instance.config**
```
packages:
yum:
mod_ssl: []
files:
/etc/httpd/conf.d/ssl.conf:
mode: "000644"
owner: root
group: root
content: |
LoadModule wsgi_module modules/mod_wsgi.so
WSGIPythonHome /var/app/venv/staging-LQM1lest
WSGISocketPrefix run/wsgi
WSGIRestrictEmbedded On
Listen 443
SSLEngine on
SSLCertificateFile "/etc/pki/tls/certs/server.crt"
SSLCertificateKeyFile "/etc/pki/tls/certs/server.key"
Alias /static/ /var/app/current/static/
Order allow,deny
Allow from all
WSGIScriptAlias / /var/app/current/application.py
Require all granted
WSGIDaemonProcess wsgi-ssl processes=1 threads=15 display-name=%{GROUP} \
python-path=/var/app/current \
python-home=/var/app/venv/staging-LQM1lest \
home=/var/app/current \
user=webapp \
group=webapp
WSGIProcessGroup wsgi-ssl
/etc/pki/tls/certs/server.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
container_commands:
01killhttpd:
command: "killall httpd"
02waitforhttpddeath:
command: "sleep 3"
```
**Note**
Évitez de valider un fichier de configuration qui contient votre clé privée de contrôle de code source. Une fois que vous avez testé la configuration et vérifié qu'elle fonctionne, stockez votre clé privée dans Amazon S3 et modifiez la configuration pour la télécharger durant le déploiement. Pour obtenir des instructions, veuillez consulter [Stockage sécurisé des clés privées dans Amazon S3](https-storingprivatekeys.md).
**Remarque pour les environnements Amazon Linux 2023**
Sur Amazon Linux 2023, il `mod_wsgi` doit être installé séparément car il n'est pas disponible dans les référentiels de packages. Pour les instructions d'installation, consultez [mod\$1wsgi sur PyPI](https://pypi.org/project/mod-wsgi/).
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
# Suspension des connexions HTTPS sur des instances EC2 exécutant Ruby
Pour les types de conteneur Ruby, la façon dont vous activez HTTPS dépend du type de serveur d'applications utilisé.
**Topics**
+ [
## Configuration de HTTPS pour Ruby avec Puma
](#Puma)
+ [
## Configuration de HTTPS pour Ruby avec Passenger
](#Passenger)
## Configuration de HTTPS pour Ruby avec Puma
Pour les types de conteneurs Ruby qui utilisent Puma en tant que serveur d'applications, vous utilisez un [fichier de configuration](ebextensions.md) pour activer HTTPS.
Ajoutez l'extrait suivant à votre fichier de configuration, en remplaçant le certificat et la clé privée comme demandé, puis enregistrez-les dans le répertoire `.ebextensions` de votre bundle de fichiers source. Le fichier de configuration effectue les tâches suivantes :
+ La clé `files` crée les fichiers suivants sur l'instance :
`/etc/nginx/conf.d/https.conf`
Configure le serveur nginx. Ce fichier est chargé lorsque le service nginx démarre.
`/etc/pki/tls/certs/server.crt`
Crée le fichier de certificat sur l'instance. *certificate file contents*Remplacez-le par le contenu de votre certificat.
YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.
Si vous avez des certificats intermédiaires, incluez-les dans `server.crt` après votre certificat de site.
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
Crée le fichier de clé privée sur l'instance. *private key contents*Remplacez-le par le contenu de la clé privée utilisée pour créer la demande de certificat ou le certificat auto-signé.
**Example .ebextensions/https-instance.config**
```
files:
/etc/nginx/conf.d/https.conf:
content: |
# HTTPS server
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://my_app;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
location /assets {
alias /var/app/current/public/assets;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
location /public {
alias /var/app/current/public;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
}
/etc/pki/tls/certs/server.crt:
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**Note**
Évitez de valider un fichier de configuration qui contient votre clé privée de contrôle de code source. Une fois que vous avez testé la configuration et vérifié qu'elle fonctionne, stockez votre clé privée dans Amazon S3 et modifiez la configuration pour la télécharger durant le déploiement. Pour obtenir des instructions, veuillez consulter [Stockage sécurisé des clés privées dans Amazon S3](https-storingprivatekeys.md).
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
## Configuration de HTTPS pour Ruby avec Passenger
Pour les types de conteneurs Ruby qui utilisent Passenger en tant que serveur d'applications, vous utilisez un fichier de configuration et un fichier JSON pour activer HTTPS.
**Pour configurer HTTPS pour Ruby avec Passenger**
1. Ajoutez l'extrait suivant à votre fichier de configuration, en remplaçant le certificat et la clé privée comme demandé, puis enregistrez-les dans le répertoire `.ebextensions` de votre bundle de fichiers source. Le fichier de configuration effectue les tâches suivantes :
+ La clé `files` crée les fichiers suivants sur l'instance :
`/etc/pki/tls/certs/server.crt`
Crée le fichier de certificat sur l'instance. *certificate file contents*Remplacez-le par le contenu de votre certificat.
YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.
Si vous avez des certificats intermédiaires, incluez-les dans `server.crt` après votre certificat de site.
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
Crée le fichier de clé privée sur l'instance. *private key contents*Remplacez-le par le contenu de la clé privée utilisée pour créer la demande de certificat ou le certificat auto-signé.
**Example Extrait .Ebextensions pour la configuration de HTTPS pour Ruby avec Passenger**
```
files:
/etc/pki/tls/certs/server.crt:
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**Note**
Évitez de valider un fichier de configuration qui contient votre clé privée de contrôle de code source. Une fois que vous avez testé la configuration et vérifié qu'elle fonctionne, stockez votre clé privée dans Amazon S3 et modifiez la configuration pour la télécharger durant le déploiement. Pour obtenir des instructions, veuillez consulter [Stockage sécurisé des clés privées dans Amazon S3](https-storingprivatekeys.md).
1. Créez un fichier texte et ajoutez le JSON suivant au fichier. Enregistrez-le dans le répertoire racine de votre groupe source avec le nom `passenger-standalone.json`. Ce fichier JSON configure Passenger pour utiliser HTTPS.
**Important**
Ce fichier JSON ne doit pas contenir une marque d'ordre d'octet (BOM). Si tel est le cas, la bibliothèque Passenger JSON ne lira pas le fichier correctement et le service Passenger ne démarrera pas.
**Example passenger-standalone.json**
```
{
"ssl" : true,
"ssl_port" : 443,
"ssl_certificate" : "/etc/pki/tls/certs/server.crt",
"ssl_certificate_key" : "/etc/pki/tls/certs/server.key"
}
```
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
# Suspension des connexions HTTPS sur des instances EC2 exécutant Tomcat
Pour les types de conteneurs Tomcat, vous devez utiliser un [fichier de configuration](ebextensions.md) afin d'autoriser Apache HTTP Server à utiliser HTTPS lorsqu'il agit en tant que proxy inverse pour Tomcat.
Ajoutez l'extrait suivant à votre fichier de configuration, en remplaçant le certificat et la clé privée comme demandé, puis enregistrez-les dans le répertoire `.ebextensions` de votre bundle de fichiers source. Le fichier de configuration effectue les tâches suivantes :
+ La clé `files` crée les fichiers suivants sur l'instance :
`/etc/pki/tls/certs/server.crt`
Crée le fichier de certificat sur l'instance. *certificate file contents*Remplacez-le par le contenu de votre certificat.
YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.
`/etc/pki/tls/certs/server.key`
Crée le fichier de clé privée sur l'instance. *private key contents*Remplacez-le par le contenu de la clé privée utilisée pour créer la demande de certificat ou le certificat auto-signé.
`/opt/elasticbeanstalk/hooks/appdeploy/post/99_start_httpd.sh`
Crée un script de hook post-déploiement pour redémarrer le service httpd.
**Example .ebextensions/https-instance.config**
```
files:
/etc/pki/tls/certs/server.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
/opt/elasticbeanstalk/hooks/appdeploy/post/99_start_httpd.sh:
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
sudo service httpd restart
```
Vous devez également configurer le serveur proxy de votre environnement pour écouter sur le port 443. La configuration Apache 2.4 suivante ajoute un écouteur sur le port 443. Pour en savoir plus, veuillez consulter la section [Configuration du serveur proxy](java-tomcat-proxy.md).
**Example . ebextensions/httpd/conf.d/ssl.conf**
```
Listen 443
ServerName server-name
SSLEngine on
SSLCertificateFile "/etc/pki/tls/certs/server.crt"
SSLCertificateKeyFile "/etc/pki/tls/certs/server.key"
Require all granted
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
ErrorLog /var/log/httpd/elasticbeanstalk-ssl-error_log
```
Votre fournisseur de certificats peut inclure des certificats intermédiaires, que vous pouvez installer pour améliorer la compatibilité avec les clients mobiles. Configurez Apache avec un bundle de certificats intermédiaires en ajoutant ce qui suit à votre fichier de configuration SSL (consultez [Extension et remplacement de la configuration Apache par défaut — Amazon Linux AMI () AL1](java-tomcat-proxy.md#java-tomcat-proxy-apache) pour l'emplacement) :
+ Dans le contenu du fichier `ssl.conf`, spécifiez le fichier de chaîne :
```
SSLCertificateKeyFile "/etc/pki/tls/certs/server.key"
SSLCertificateChainFile "/etc/pki/tls/certs/gd_bundle.crt"
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
```
+ Ajoutez une nouvelle entrée à la clé `files` avec le contenu des certificats intermédiaires :
```
files:
/etc/pki/tls/certs/gd_bundle.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
First intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Second intermediate certificate
-----END CERTIFICATE-----
```
**Note**
Évitez de valider un fichier de configuration qui contient votre clé privée de contrôle de code source. Une fois que vous avez testé la configuration et vérifié qu'elle fonctionne, stockez votre clé privée dans Amazon S3 et modifiez la configuration pour la télécharger durant le déploiement. Pour obtenir des instructions, veuillez consulter [Stockage sécurisé des clés privées dans Amazon S3](https-storingprivatekeys.md).
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
# Résiliation des connexions HTTPS sur les instances Amazon EC2 exécutant .NET Core sous Linux
Pour les types de conteneur .NET Core sous Linux, vous activez HTTPS avec un [fichier de configuration](ebextensions.md) `.ebextensions` et un fichier de configuration nginx qui configure le serveur nginx pour utiliser HTTPS.
Ajoutez l'extrait suivant à votre fichier de configuration, en remplaçant les espaces réservés pour le certificat et la clé privée comme indiqué, puis enregistrez-le dans le répertoire `.ebextensions`. Le fichier de configuration effectue les tâches suivantes :
+ La clé `files` crée les fichiers suivants sur l'instance :
`/etc/pki/tls/certs/server.crt`
Crée le fichier de certificat sur l'instance. *certificate file contents*Remplacez-le par le contenu de votre certificat.
YAML utilise une mise en retrait cohérente. Respectez le niveau de retrait lorsque vous remplacez du contenu dans un exemple de fichier de configuration et veillez à ce que votre éditeur de texte utilise des espaces, et non des caractères de tabulation, pour la mise en retrait.
Si vous avez des certificats intermédiaires, incluez-les dans `server.crt` après votre certificat de site.
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
Crée le fichier de clé privée sur l'instance. *private key contents*Remplacez-le par le contenu de la clé privée utilisée pour créer la demande de certificat ou le certificat auto-signé.
**Example .ebextensions/https-instance.config**
```
files:
/etc/pki/tls/certs/server.crt:
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**Note**
Évitez de valider un fichier de configuration qui contient votre clé privée de contrôle de code source. Une fois que vous avez testé la configuration et vérifié qu'elle fonctionne, stockez votre clé privée dans Amazon S3 et modifiez la configuration pour la télécharger durant le déploiement. Pour obtenir des instructions, veuillez consulter [Stockage sécurisé des clés privées dans Amazon S3](https-storingprivatekeys.md).
Placez les éléments suivants dans un fichier avec l'extension `.conf` dans le répertoire `.platform/nginx/conf.d/` de votre bundle de fichiers source (par exemple, `.platform/nginx/conf.d/https.conf`). *app\$1port*Remplacez-le par le numéro de port que votre application écoute. Cet exemple configure le serveur nginx pour écouter sur le port 443 à l'aide de SSL. Pour de plus amples informations sur les fichiers de configuration sur la plateforme .NET Core sous Linux, veuillez consulter [Configuration du serveur proxy](dotnet-linux-platform-nginx.md).
**Example . platform/nginx/conf.d/https.conf**
```
# HTTPS server
server {
listen 443 ssl;
server_name localhost;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://localhost:app_port;
proxy_set_header Connection "";
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
```
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
# Résiliation du protocole HTTPS sur les EC2 instances Amazon exécutant .NET
Le [fichier de configuration](ebextensions.md) suivant crée et exécute un PowerShell script Windows qui exécute les tâches suivantes :
+ Vérifie la présence d'un certificat HTTPS existant lié au port 443.
+ Obtient le [certificat PFX](configuring-https-ssl.md) à partir d'un compartiment Amazon S3.
**Note**
Ajoutez une `AmazonS3ReadOnlyAccess` politique au `aws-elasticbeanstalk-ec2-role` pour accéder au certificat SSL dans le compartiment Amazon S3.
+ Obtient le mot de passe de AWS Secrets Manager.
**Note**
Ajoutez une instruction `aws-elasticbeanstalk-ec2-role` qui autorise l'`secretsmanager:GetSecretValue`action pour le secret qui contient le mot de passe du certificat
+ Installe le certificat.
+ Lie le certificat au port 443.
**Note**
Pour supprimer le point de terminaison HTTP (port 80), incluez la commande `Remove-WebBinding` sous la section **Remove the HTTP binding** de l'exemple.
**Example extensions .eb/ .config https-instance-dotnet**
```
files:
"C:\\certs\\install-cert.ps1":
content: |
import-module webadministration
## Settings - replace the following values with your own
$bucket = "amzn-s3-demo-bucket" ## S3 bucket name
$certkey = "example.com.pfx" ## S3 object key for your PFX certificate
$secretname = "example_secret" ## AWS Secrets Manager name for a secret that contains the certificate's password
##
# Set variables
$certfile = "C:\cert.pfx"
$pwd = Get-SECSecretValue -SecretId $secretname | select -expand SecretString
# Clean up existing binding
if ( Get-WebBinding "Default Web Site" -Port 443 ) {
Echo "Removing WebBinding"
Remove-WebBinding -Name "Default Web Site" -BindingInformation *:443:
}
if ( Get-Item -path IIS:\SslBindings\0.0.0.0!443 ) {
Echo "Deregistering WebBinding from IIS"
Remove-Item -path IIS:\SslBindings\0.0.0.0!443
}
# Download certificate from S3
Read-S3Object -BucketName $bucket -Key $certkey -File $certfile
# Install certificate
Echo "Installing cert..."
$securepwd = ConvertTo-SecureString -String $pwd -Force -AsPlainText
$cert = Import-PfxCertificate -FilePath $certfile cert:\localMachine\my -Password $securepwd
# Create site binding
Echo "Creating and registering WebBinding"
New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https
New-Item -path IIS:\SslBindings\0.0.0.0!443 -value $cert -Force
## Remove the HTTP binding
## (optional) Uncomment the following line to unbind port 80
# Remove-WebBinding -Name "Default Web Site" -BindingInformation *:80:
##
# Update firewall
netsh advfirewall firewall add rule name="Open port 443" protocol=TCP localport=443 action=allow dir=OUT
commands:
00_install_ssl:
command: powershell -NoProfile -ExecutionPolicy Bypass -file C:\\certs\\install-cert.ps1
```
Dans un environnement à instance unique, vous devez également modifier le groupe de sécurité de l'instance pour autoriser le trafic sur le port 443. Le fichier de configuration suivant récupère l'ID du groupe de sécurité à l'aide d'une CloudFormation [fonction](ebextensions-functions.md) et y ajoute une règle.
**Example extensions .eb/ .config https-instance-single**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
Dans un environnement à répartition de charge équilibrée, vous configurez l'équilibreur de charge pour qu'il fasse [passer le trafic sécurisé sans le toucher, soit pour le déchiffrer et le rechiffrer à](https-tcp-passthrough.md) [des fins de chiffrement](configuring-https-endtoend.md). end-to-end
# Configuration du end-to-end chiffrement dans un environnement Elastic Beanstalk à charge équilibrée
La suspension des connexions sécurisées au niveau de l'équilibreur de charge et l'utilisation de HTTP sur le backend peuvent s'avérer suffisantes pour votre application. Le trafic réseau entre les ressources AWS ne peut pas être écouté par les instances qui ne font pas partie de la connexion, même si elles sont exécutées sous le même compte.
Toutefois, si vous développez une application qui doit respecter des réglementations externes strictes, vous pouvez être contraint de sécuriser toutes les connexions réseau. Pour respecter ces obligations, vous pouvez utiliser la console Elastic Beanstalk ou les [fichiers de configuration](ebextensions.md) afin que l'équilibreur de charge de votre environnement Elastic Beanstalk se connecte aux instances backend en toute sécurité. La procédure suivante se concentre sur les fichiers de configuration.
Commencez par [ajouter un écouteur sécurisé à votre équilibreur de charge](configuring-https-elb.md), si vous ne l'avez pas encore fait.
Vous devez également configurer les instances de votre environnement pour autoriser l'écoute sur le port sécurisé et la suspension des connexions HTTPS. La configuration varie selon la plateforme. Pour obtenir des instructions, consultez [Configuration de la terminaison HTTPS sur l'instance](https-singleinstance.md). Vous pouvez utiliser un [certificat auto-signé](configuring-https-ssl.md) pour les EC2 instances sans problème.
Ensuite, configurez l'écouteur pour transférer le trafic à l'aide du protocole HTTPS vers le port sécurisé utilisé par votre application. Utilisez l'un des fichiers de configuration suivants en fonction du type d'équilibreur de charge utilisé par votre environnement.
**`.ebextensions/https-reencrypt-clb.config`**
Utilisez ce fichier de configuration avec un équilibreur Classic Load Balancer. En plus de configurer l'équilibreur de charge, le fichier de configuration modifie également par défaut la vérification de l'état pour utiliser le port 443 et HTTPS, afin de veiller à ce que l'équilibreur de charge puisse se connecter en toute sécurité.
```
option_settings:
aws:elb:listener:443:
InstancePort: 443
InstanceProtocol: HTTPS
aws:elasticbeanstalk:application:
Application Healthcheck URL: HTTPS:443/
```
**`.ebextensions/https-reencrypt-alb.config`**
Utilisez ce fichier de configuration avec un équilibreur Application Load Balancer.
```
option_settings:
aws:elbv2:listener:443:
DefaultProcess: https
ListenerEnabled: 'true'
Protocol: HTTPS
aws:elasticbeanstalk:environment:process:https:
Port: '443'
Protocol: HTTPS
```
**`.ebextensions/https-reencrypt-nlb.config`**
Utilisez ce fichier de configuration avec un équilibreur Network Load Balancer.
```
option_settings:
aws:elbv2:listener:443:
DefaultProcess: https
ListenerEnabled: 'true'
aws:elasticbeanstalk:environment:process:https:
Port: '443'
```
L'option `DefaultProcess` est nommée ainsi en raison des équilibreurs de charge Application Load Balancer, qui peuvent avoir des écouteurs autres que ceux par défaut sur le même port pour le trafic vers des chemins spécifiques (voir [Application Load Balancer](environments-cfg-alb.md) pour plus de détails). Pour un équilibreur de charge Network Load Balancer, l'option spécifie le seul processus cible de cet écouteur.
Dans cet exemple, nous avons nommé le processus `https`, car il écoute le trafic sécurisé (HTTPS). L'écouteur envoie le trafic vers le processus sur le port désigné à l'aide du protocole TCP, car un équilibreur de charge Network Load Balancer fonctionne uniquement avec TCP. C'est tout à fait normal, car le trafic réseau pour HTTP et HTTPS est mis en œuvre par-dessus TCP.
**Note**
L'interface de ligne de commande (CLI) EB et la console Elastic Beanstalk appliquent les valeurs recommandées pour les options précédentes. Vous devez supprimer ces paramètres si vous voulez utiliser des fichiers de configuration pour configurer la même chose. Consultez [Valeurs recommandées](command-options.md#configuration-options-recommendedvalues) pour plus de détails.
Dans la tâche suivante, vous devez modifier le groupe de sécurité de l'équilibreur de charge pour autoriser le trafic. Selon l'[Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) (Amazon VPC) dans lequel vous lancez votre environnement (le VPC par défaut ou un VPC personnalisé), le groupe de sécurité de l'équilibreur de charge varie. Dans un VPC par défaut, Elastic Load Balancing fournit un groupe de sécurité par défaut que tous les équilibreurs de charge peuvent utiliser. Dans un VPC Amazon que vous créez, Elastic Beanstalk crée un groupe de sécurité que l'équilibreur de charge doit utiliser.
Pour prendre en charge les deux scénarios, vous pouvez créer un groupe de sécurité et demander à Elastic Beanstalk de l'utiliser. Le fichier de configuration suivant crée un groupe de sécurité et l'associe à l'équilibreur de charge.
**`.ebextensions/https-lbsecuritygroup.config`**
```
option_settings:
# Use the custom security group for the load balancer
aws:elb:loadbalancer:
SecurityGroups: '`{ "Ref" : "loadbalancersg" }`'
ManagedSecurityGroup: '`{ "Ref" : "loadbalancersg" }`'
Resources:
loadbalancersg:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: load balancer security group
VpcId: vpc-########
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 0.0.0.0/0
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
SecurityGroupEgress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
```
Remplacez le texte en surbrillance par l'ID de votre VPC par défaut ou personnalisé. L'exemple précédent inclut le trafic entrant et sortant via le port 80 pour autoriser les connexions HTTP. Vous pouvez supprimer ces propriétés si vous souhaitez autoriser uniquement les connexions sécurisées.
Enfin, ajoutez des règles de trafic entrant et sortant qui autorisent la communication sur le port 443 entre le groupe de sécurité de l'équilibreur de charge et le groupe de sécurité des instances.
**`.ebextensions/https-backendsecurity.config`**
```
Resources:
# Add 443-inbound to instance security group (AWSEBSecurityGroup)
httpsFromLoadBalancerSG:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
SourceSecurityGroupId: {"Fn::GetAtt" : ["loadbalancersg", "GroupId"]}
# Add 443-outbound to load balancer security group (loadbalancersg)
httpsToBackendInstances:
Type: AWS::EC2::SecurityGroupEgress
Properties:
GroupId: {"Fn::GetAtt" : ["loadbalancersg", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
DestinationSecurityGroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
```
Si vous effectuez cette opération en dehors du processus de création du groupe de sécurité, vous pouvez limiter les groupes de sécurité source et de destination sans créer de dépendance circulaire.
Après avoir effectué toutes les tâches précédentes, l'équilibreur de charge se connecte à vos instances backend en toute sécurité à l'aide du protocole HTTPS. L'équilibreur de charge ne s'occupe pas de savoir si le certificat de votre instance est auto-signé ou a été émis par une autorité de certification compétente : il accepte tous les certificats qui lui sont présentés.
Pour modifier ce comportement, vous pouvez ajouter des stratégies à l'équilibreur de charge en lui demandant de ne faire confiance qu'à un certificat spécifique. Le fichier de configuration suivant crée deux stratégies. La première spécifie un certificat public, et la deuxième indique à l'équilibreur de charge qu'il ne doit faire confiance qu'à ce certificat pour les connexions au port 443 de l'instance.
**`.ebextensions/https-backendauth.config`**
```
option_settings:
# Backend Encryption Policy
aws:elb:policies:backendencryption:
PublicKeyPolicyNames: backendkey
InstancePorts: 443
# Public Key Policy
aws:elb:policies:backendkey:
PublicKey: |
-----BEGIN CERTIFICATE-----
################################################################
################################################################
################################################################
################################################################
################################################
-----END CERTIFICATE-----
```
Remplacez le texte surligné par le contenu du certificat public de votre EC2 instance.
# Configuration de l'équilibreur de charge de votre environnement pour TCP Passthrough
Si vous ne souhaitez pas que l'équilibreur de charge de votre AWS Elastic Beanstalk environnement déchiffre le trafic HTTPS, vous pouvez configurer l'écouteur sécurisé pour qu'il relaie les demandes aux instances de backend telles quelles.
**Important**
La configuration de l'équilibreur de charge pour relayer le trafic HTTPS sans le déchiffrer présente un inconvénient. L'équilibreur de charge ne peut pas voir les demandes chiffrées et ne peut donc pas optimiser le routage ni communiquer les mesures de réponse.
[Configurez d'abord les EC2 instances de votre environnement pour mettre fin au protocole HTTPS](https-singleinstance.md). Testez la configuration sur un environnement d'instance unique pour vous assurer que tout fonctionne avant d'ajouter un équilibreur de charge au mélange.
Ajoutez un [fichier de configuration](ebextensions.md) à votre projet pour configurer un auditeur sur le port 443 qui passe des paquets TCP en l'état vers le port 443 sur les instances backend :
**`.ebextensions/https-lb-passthrough.config`**
```
option_settings:
aws:elb:listener:443:
ListenerProtocol: TCP
InstancePort: 443
InstanceProtocol: TCP
```
Dans un VPC [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) (Amazon VPC) par défaut, vous devez également ajouter une règle au groupe de sécurité des instances pour autoriser le trafic entrant sur 443 à partir de l'équilibreur de charge :
**`.ebextensions/https-instance-securitygroup.config`**
```
Resources:
443inboundfromloadbalancer:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
SourceSecurityGroupName: { "Fn::GetAtt": ["AWSEBLoadBalancer", "SourceSecurityGroup.GroupName"] }
```
Dans un VPC personnalisé, Elastic Beanstalk met automatiquement à jour la configuration du groupe de sécurité.
# Configuration de la redirection HTTP vers HTTPS
Cette rubrique décrit comment gérer le trafic HTTP vers votre application si les utilisateurs finaux continuent de le lancer. Pour ce faire, vous devez configurer la *redirection de HTTP vers HTTPS*, parfois appelée *forçage HTTPS*.
Pour configurer la redirection, vous devez d'abord configurer votre environnement pour gérer le trafic HTTPS. Ensuite, vous redirigez le trafic HTTP vers HTTPS. Ces deux étapes sont abordées dans les sous-sections suivantes.
## Configurer votre environnement pour gérer le trafic HTTPS
Selon la configuration d'équilibrage de charge de votre environnement, effectuez l'une des opérations suivantes :
+ **Environnement à charge équilibrée** : [configurez votre équilibreur de charge pour résilier les connexions HTTPS](configuring-https-elb.md).
+ **Environnement à instance unique** : [configurez votre application pour résilier les connexions HTTPS au niveau de l'instance](https-singleinstance.md). Cette configuration dépend de la plateforme de votre environnement.
## Rediriger le trafic HTTP vers HTTPS
Pour rediriger le trafic HTTP vers HTTPS pour votre application, vous pouvez configurer les serveurs Web sur les instances de votre environnement ou configurer l'Application Load Balancer de l'environnement.
**Configuration des serveurs Web de l'instance**
Cette méthode fonctionne sur n'importe quel environnement de serveur Web. Configurez les serveurs Web de vos EC2 instances Amazon pour qu'ils répondent au trafic HTTP avec un statut de réponse de redirection HTTP.
Cette configuration dépend de la plateforme de votre environnement. Recherchez le dossier de votre plateforme dans la [https://github.com/awsdocs/elastic-beanstalk-samples/tree/master/configuration-files/aws-provided/security-configuration/https-redirect](https://github.com/awsdocs/elastic-beanstalk-samples/tree/master/configuration-files/aws-provided/security-configuration/https-redirect)collection sur GitHub, et utilisez l'exemple de fichier de configuration contenu dans ce dossier.
Si votre environnement utilise les [vérifications de l'état Elastic Load Balancing](using-features.healthstatus.md#using-features.healthstatus.understanding), l'équilibreur de charge attend qu'une instance saine réponde aux messages de vérification de l'état HTTP avec des réponses HTTP 200 (OK). Par conséquent, votre serveur web ne devrait pas rediriger ces messages vers HTTPS. Les exemples de fichiers de configuration dans [https://github.com/awsdocs/elastic-beanstalk-samples/tree/master/configuration-files/aws-provided/security-configuration/https-redirect](https://github.com/awsdocs/elastic-beanstalk-samples/tree/master/configuration-files/aws-provided/security-configuration/https-redirect) gèrent cette exigence correctement.
**Configuration de l'équilibreur de charge**
Cette méthode fonctionne si vous disposez d'un environnement d'équilibrage de charge qui utilise un [Application](environments-cfg-alb.md) Load Balancer. Un Application Load Balancer peut envoyer des réponses de redirection au fur et à mesure que le trafic HTTP arrive. Dans ce cas, vous n'avez pas besoin de configurer la redirection sur les instances de votre environnement.
Nous avons deux exemples de fichiers de configuration GitHub qui montrent comment configurer un Application Load Balancer pour la redirection.
+ Le fichier de configuration [https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/aws-provided/resource-configuration/alb-http-to-https-redirection-full.config](https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/aws-provided/resource-configuration/alb-http-to-https-redirection-full.config) crée un écouteur HTTPS sur le port 443 et modifie l'écouteur de port 80 par défaut pour rediriger le trafic HTTP entrant vers HTTPS.
+ Le fichier [https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/aws-provided/resource-configuration/alb-http-to-https-redirection.config](https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/aws-provided/resource-configuration/alb-http-to-https-redirection.config)de configuration s'attend à ce que l'écouteur 443 soit défini. Pour le définir, vous pouvez utiliser les espaces de noms de configuration standard d'Elastic Beanstalk ou la console Elastic Beanstalk. Ensuite, il prend soin de modifier l'écouteur du port 80 pour la redirection.