TLS est une fonction de plateforme de première classe sur le Stack Harbor PaaS. Chaque environnement peut servir du trafic en HTTPS sans aucune infrastructure à opérer de votre côté. Cette page explique où TLS se termine sur la plateforme et présente les quatre chemins vers un certificat — pour que vous puissiez choisir la bonne option avant de toucher à quoi que ce soit.
Ce que couvre cette page
- Où TLS se termine réellement : le répartiteur partagé (SLB) ou un nœud conteneur dans votre environnement.
- Les quatre chemins vers un certificat : SSL intégré, SSL personnalisé, SSL personnalisé via le répartiteur partagé (SLB) et Let’s Encrypt.
- Un tableau de décision : quel chemin convient à votre situation.
- Le chiffrement des bases de données en transit : les add-ons SSL/TLS pour les paliers base de données infogérés.
- Des liens vers les pages pratiques dédiées à chaque chemin.
Si vous connaissez déjà la terminaison TLS et avez besoin uniquement des étapes, allez directement à la page correspondant à votre chemin de certificat (voir La suite en bas de page).
Où TLS se termine
Le trafic qui atteint un environnement peut terminer TLS à l’un de deux endroits, selon le chemin de certificat choisi.
Au niveau du répartiteur partagé (SLB) : Le SLB est la couche d’entrée partagée de la plateforme. Les environnements qui ne possèdent pas d’IP publique y transitent. Le SLB gère la négociation TLS pour le SSL intégré et pour le SSL personnalisé via SLB, puis transmet le trafic au point d’entrée de l’environnement via le réseau interne. Vos conteneurs ne voient jamais la négociation TLS brute.
Au niveau du point d’entrée de l’environnement : Les environnements disposant d’une IP publique attachée à leur nœud d’entrée (un répartiteur de charge ou un serveur applicatif dans une topologie à nœud unique) gèrent TLS directement sur ce nœud. Le SSL personnalisé et Let’s Encrypt suivent tous deux ce chemin. La plateforme installe le matériel de certificat sur le conteneur d’entrée ; TLS se termine avant que le trafic n’atteigne la couche applicative.
Les quatre chemins vers un certificat
SSL intégré
La plateforme fournit un certificat générique couvrant le nom d’hôte émis par la plateforme pour chaque environnement (par exemple, monenv.region.paas.exemple.com). Vous l’activez d’un simple interrupteur dans les paramètres de topologie — pas de modifications DNS, pas de gestion de certificat, pas d’IP publique requise.
Le SSL intégré se termine au SLB. Parce qu’il est lié au nom d’hôte émis par la plateforme, il ne fonctionne pas avec des domaines personnalisés et est incompatible avec les environnements qui ont une IP publique attachée au point d’entrée.
Utilisez ce chemin pour les outils internes, les environnements de pré-production ou toute situation où l’URL émise par la plateforme convient.
SSL personnalisé
Vous fournissez votre propre clé privée, le certificat de domaine et la chaîne intermédiaire complète pour un domaine personnalisé que vous contrôlez. La plateforme installe le matériel sur le conteneur d’entrée de l’environnement, et TLS s’y termine.
Le SSL personnalisé exige deux prérequis : un domaine personnalisé pointant vers l’environnement, et une IP publique attachée au nœud d’entrée. Sans IP publique, la plateforme ne peut pas exposer le port 443 directement sur votre point d’entrée.
Utilisez ce chemin lorsque vous avez une exigence de conformité imposant une autorité de certification précise, ou lorsque vous gérez déjà des certificats via la PKI de votre organisation.
SSL personnalisé via le répartiteur partagé
Vous fournissez votre propre certificat, mais la terminaison se fait sur le SLB via SNI plutôt que sur un conteneur que vous possédez. Cela permet d’utiliser un domaine personnalisé avec un certificat personnalisé sur un environnement qui n’a pas — et ne peut pas avoir — d’IP publique. La configuration se fait via l’API de la plateforme plutôt que par l’interface de topologie.
Utilisez ce chemin lorsque vos contraintes d’infrastructure vous empêchent d’attacher une IP publique, mais que votre politique de certificats exige un certificat signé par une autorité de certification sur un domaine personnalisé.
Let’s Encrypt
La plateforme propose un add-on Let’s Encrypt que vous installez directement depuis l’interface de topologie. Il gère l’émission et le renouvellement automatique des certificats ; le renouvellement s’exécute environ 30 jours avant l’expiration. Les certificats Let’s Encrypt sont gratuits et approuvés par tous les navigateurs majeurs.
Let’s Encrypt requiert un domaine personnalisé et une IP publique accessible sur le point d’entrée. L’add-on utilise un défi HTTP-01 pour vérifier la propriété du domaine, donc le domaine doit résoudre vers l’IP publique de l’environnement avant l’émission.
Utilisez ce chemin pour les domaines personnalisés en production lorsque vous n’avez pas besoin de spécifier une autorité de certification particulière.
Quand utiliser quoi
| Situation | Chemin recommandé |
|---|---|
| HTTPS rapide sur l’URL émise par la plateforme (sans domaine personnalisé) | SSL intégré |
| Domaine personnalisé en production, IP publique disponible, toute AC acceptable | Let’s Encrypt |
| Domaine personnalisé en production, IP publique disponible, AC précise requise | SSL personnalisé |
| Domaine personnalisé, aucune IP publique disponible | SSL personnalisé via SLB |
| Conformité : AC précise sur domaine personnalisé, sans IP publique | SSL personnalisé via SLB |
| Connexions bases de données — chiffrement en transit pour MySQL/MariaDB/Percona ou PostgreSQL | Add-on SSL/TLS base de données (voir ci-dessous) |
Chiffrement des bases de données en transit
Les quatre chemins ci-dessus s’appliquent tous au trafic HTTP/HTTPS atteignant votre application. La plateforme expose également des add-ons SSL/TLS dédiés pour les paliers base de données infogérés, qui opèrent au niveau de la connexion plutôt qu’au niveau HTTP.
L’add-on SSL/TLS pour bases de données génère des certificats par nœud et reconfigure le démon base de données pour exiger ou préférer les connexions chiffrées des clients. Deux variantes existent : une pour MySQL, MariaDB et Percona, et une distincte pour PostgreSQL. Les détails de chacune — structure des certificats, chaînes de connexion client et comment vérifier que le chiffrement est actif — se trouvent sur les pages dédiées.
La suite
- SSL intégré — activez HTTPS sur l’URL émise par la plateforme en un seul interrupteur.
- SSL personnalisé — installez votre propre certificat sur un environnement avec IP publique.
- SSL personnalisé via répartiteur partagé — certificat personnalisé configuré par API pour les environnements sans IP publique.
- Domaines personnalisés — pointez votre propre domaine vers un environnement avant d’attacher un certificat.
- SSL/TLS pour MySQL, MariaDB et Percona — chiffrement en transit pour le palier base de données MySQL.
- SSL/TLS pour PostgreSQL — chiffrement en transit pour le palier base de données PostgreSQL.