HTTPS vers une IP privée : identité du certificat ou nom d’hôte ?

Votre service à l’adresse https://10.60.0.25 peut disposer d’un TLS authentifié même sans nom DNS. L’adresse est l’identité que le client doit valider, et le certificat doit la décrire exactement. La décision consiste à savoir si cette adresse est assez stable pour être une identité, ou si un nom d’hôte serait plus facile à maintenir. Le VPN répond à l’accessibilité ; il ne répond pas à cette question.

Si l’identité et la confiance sont justes, une URL fondée sur l’IP est une conception légitime.

Ce que le client valide réellement

Le client compare l’identité de référence de l’URL aux noms alternatifs du sujet du certificat. Pour une adresse IP, cela signifie une entrée iPAddress égale à l’adresse. Un nom commun convivial ne la remplace pas.

RFC 9525 sépare les identités d’adresse IP des noms DNS et définit la règle de correspondance. Placer l’adresse uniquement dans l’étiquette du sujet, ou comme entrée de type DNS, ne produit aucune correspondance. C’est pourquoi le SAN est le champ à inspecter lorsqu’un avertissement apparaît.

La confiance est une seconde vérification, indépendante. Une correspondance de nom ne corrige pas une chaîne non fiable, un certificat expiré ou un certificat émis pour un autre usage.

Décision un : l’adresse est-elle assez stable pour être une identité

Si l’adresse est fixe pendant toute la durée du déploiement, un certificat SAN d’IP est simple et honnête. Si le service peut se déplacer, chaque déplacement devient un remplacement de certificat et une mise à jour coordonnée des clients.

Un nom d’hôte stable réduit ce couplage. Les clients utilisent le nom, le DNS approuvé le fait correspondre à l’adresse actuelle, et un changement d’adresse cesse d’être un changement d’identité. Le certificat doit toujours être renouvelé, mais l’URL ne change pas.

Une entrée gérée dans le fichier hosts peut fournir la correspondance dans un petit environnement. Elle ajoute une responsabilité de distribution ; elle ne remplace pas la vérification TLS.

Décision deux : comment le client fera confiance à l’émetteur

Pour une CA privée, distribuez l’ancre de confiance aux appareils prévus par un mécanisme approuvé. N’entraînez pas les utilisateurs à ignorer les avertissements ni à installer un certificat remis par une page de connexion. Si vous voulez un certificat publiquement approuvé, vérifiez les règles actuelles de l’émetteur pour les adresses privées avant de planifier autour. La plupart des émetteurs publics ne valideront pas une IP privée comme identité publique.

Examinez le navigateur ou l’application réel. Son magasin de confiance et son comportement de validation comptent davantage que la documentation générale du système d’exploitation sur les certificats. Vérifiez-le sur l’appareil réel, pas seulement dans la console.

La passerelle VPN n’est peut-être pas la machine qui exécute l’application web, donc ne supposez pas que le certificat du tunnel ait quoi que ce soit à voir avec celui-ci.

Planifiez le changement d’adresse avant qu’il n’ait lieu

Si 10.60.0.25 devient 10.60.0.40, l’ancien certificat ne décrit plus l’URL. Planifiez le remplacement et la mise à jour des clients ensemble, et ne désactivez jamais la vérification pendant le déplacement.

Choisissez l’identité que les utilisateurs saisiront ou que les applications configureront, puis alignez l’émission, la confiance, le déploiement et le renouvellement autour d’elle. Une page accessible avec un avertissement ignoré n’est pas le même résultat qu’un service dont le client vérifie l’identité.