Domaine et certificat
L’accès à une instance passe par un reverse proxy fourni avec le produit. Il répartit les requêtes entre les composants de l’application et s’occupe du certificat. La variante de certificat qui s’applique se choisit dans la configuration.
L’instance a besoin d’un nom DNS qui pointe vers le serveur. Les enregistrements exacts à créer sont indiqués dans le manuel d’exploitation. Pour la délivrance automatique du certificat, le serveur doit être joignable depuis Internet sur les ports web habituels.
Variante 1 : certificat public
Section intitulée « Variante 1 : certificat public »Le cas normal pour un serveur ayant une adresse publique. Le reverse proxy obtient et renouvelle le certificat de lui-même via Let’s Encrypt. La condition préalable est un DNS résolvant publiquement. Dans un réseau cloisonné, cette variante ne fonctionne pas.
Variante 2 : CA interne dans le LAN
Section intitulée « Variante 2 : CA interne dans le LAN »Pour les serveurs sans accessibilité publique. Le reverse proxy délivre les certificats depuis sa propre autorité de certification locale. Les appareils ont pour cela besoin d’un enregistrement DNS interne, et l’autorité de certification racine doit être déclarée de confiance sur chaque appareil. Sinon, un avertissement de certificat apparaît.
Le passage ultérieur à un certificat public est simple : nom d’hôte, liens et URI de redirection restent identiques.
Variante 3 : derrière un WAF existant
Section intitulée « Variante 3 : derrière un WAF existant »Lorsqu’une appliance en amont comme Sophos, F5, HAProxy ou nginx termine déjà le HTTPS, le proxy fourni ne doit pas aller chercher un second certificat. Dans cette variante, il n’assure que la répartition ; la terminaison reste du ressort de l’appliance.
Pour que l’affectation fonctionne, l’appliance doit transmettre l’en-tête Host. Dans la configuration de l’application, l’adresse publique est déposée telle que vos utilisateurs l’appellent. Sinon, il en résulte par exemple des liens d’invitation qui ne mènent nulle part.