Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Un enregistrement DNS direct associe un nom à une adresse. Il rend l’accès plus pratique, mais ne masque pas cette adresse. Un proxy peut présenter ses propres adresses pour les protocoles qu’il prend en charge ; cela n’implique pas qu’il puisse protéger n’importe quel serveur de jeu ou flux UDP.
Le navigateur vérifie que le certificat correspond au nom, qu’il est valable et que sa chaîne est reconnue. Une erreur ne doit pas être contournée systématiquement : vérifier l’heure, le nom utilisé, l’expiration et l’autorité émettrice. Un certificat prévu pour l’origine d’un proxy n’est pas nécessairement reconnu directement par tous les navigateurs.
Lorsqu’un proxy termine TLS, il déchiffre le trafic avant de le transmettre. Prévoir aussi un transport chiffré et authentifié entre ce proxy et le serveur d’origine. Les réglages de chiffrement ne remplacent pas le contrôle des accès applicatifs.
Lister le nom, le propriétaire, le backend, le port, le certificat et les zones autorisées. Tester la résolution depuis l’extérieur puis le certificat et une opération de lecture. Réserver les consoles d’administration à un accès privé. Vérifier IPv4 et IPv6, les éventuelles redirections de la box et les règles du pare-feu.
Les en-têtes indiquant l’adresse du visiteur ne sont fiables que si le serveur accepte ces informations de ses proxys connus et bloque les chemins de contournement. Faire confiance à n’importe quel X-Forwarded-For permettrait de falsifier l’identité réseau dans les journaux.
Pour des données d’entreprise, cartographier les prestataires qui peuvent lire le contenu, les lieux de traitement, les contrats et les transferts éventuels. L’hébergement local ne suffit pas si un intermédiaire termine le chiffrement. Un VPN privé peut réduire le nombre d’intermédiaires pour la gestion ; les pages publiques et les portails clients peuvent conserver une architecture distincte.
Validation : certificat sans erreur, origine non contournable selon la politique choisie, journal affichant la bonne adresse client, absence d’accès anonyme aux documents privés. Conserver le résultat daté ; un test réalisé depuis le LAN n’est pas une preuve complète d’accessibilité externe.
| Type | Contenu | Quand choisir |
|---|---|---|
| A | Nom vers une IPv4 | Service effectivement publié sur cette adresse |
| AAAA | Nom vers une IPv6 | Seulement si chemin et filtrage IPv6 sont opérationnels |
| CNAME | Alias vers un autre nom | Mutualiser une destination, sous contraintes du fournisseur |
| MX | Serveur de messagerie et priorité | Selon l’hébergeur mail, pas l’IP d’un site Web |
| TXT | Texte de validation ou politique | Copier la valeur exacte du service concerné |
| CAA | Autorités autorisées à émettre | Après inventaire de toutes les émissions légitimes |
| TTL | Durée de cache | Baisser avant une migration, puis rétablir un compromis normal |
Un nom DNS n’efface pas l’adresse publique : une résolution A/AAAA la révèle si elle pointe directement vers le serveur. Un proxy HTTP protège certains flux Web, pas automatiquement un serveur de jeu UDP. Ne pas activer une option proxy sur un protocole non pris en charge.
Le navigateur vérifie notamment nom, validité, chaîne de confiance et signature. Le nom utilisé doit apparaître dans les SAN ; changer seulement le titre du site ne corrige rien. Une autorité interne demande que les postes administrés lui fassent confiance par un mécanisme maîtrisé. Un certificat d’origine destiné à un proxy n’est pas nécessairement reconnu par les navigateurs en accès direct.
Pour ACME, choisir validation HTTP si le chemin de challenge est joignable et adapté ; DNS si l’on veut prouver la maîtrise du nom sans publier le serveur d’administration. Limiter les droits de la clé DNS et la conserver hors du wiki. Un certificat valide prouve une association au nom, pas l’absence de faille dans l’application.
Dessiner navigateur → proxy éventuel → reverse proxy → application. Pour chaque segment, écrire protocole, vérification du certificat et partie capable de lire les données. Si le proxy déchiffre puis rechiffre, il peut lire le contenu. Réserver la gestion confidentielle à un accès privé peut réduire cette exposition, mais nécessite encore sauvegardes, postes sûrs et contrôle des comptes.
Sur le backend, vérifier la chaîne et le nom attendus au lieu de désactiver la validation TLS pour supprimer un 502. Déclarer les proxies de confiance dans l’application ; ne pas accepter les en-têtes d’identité ou d’adresse provenant de n’importe quelle source.
Préparer l’application avec le nouveau nom, son certificat et le routage. Tester sans casser l’ancien accès, publier le DNS, puis vérifier depuis l’extérieur. Mettre à jour URL de base, callbacks, courriels, liens, tâches et restrictions CORS si applicables. Rediriger l’ancien nom seulement après validation ; une redirection permanente peut rester en cache.
Dans un réseau privé, le split DNS peut faire résoudre le même nom vers un reverse proxy interne. Le certificat doit toujours être valide pour ce nom. Tester depuis LAN, VPN et réseau mobile : chaque chemin peut utiliser une réponse DNS différente.
NXDOMAIN : enregistrement absent ou mauvais résolveur. Délai TCP : réseau, redirection ou service. Erreur de nom : mauvais certificat ou mauvais SNI. 502/503 : proxy joignable mais backend indisponible/mal sélectionné. Boucle de redirection : incohérence HTTP/HTTPS ou URL d’application. Expiration récurrente : renouvellement ou rechargement du service à corriger, pas calendrier d’acceptation manuelle des avertissements.