Les applications accédant à un hôte spécifié par l'utilisateur via HTTPS doivent-elles tenter de fournir une assistance en recherchant son nom de domaine complet ?

L'accès aux applications sur des hôtes spécifiés par l'utilisateur via HTTPS est une exigence courante, mais vous pouvez rencontrer une certaine confusion dans les applications pratiques. Pour ce problème, l'éditeur PHP Banana pense que nous devrions essayer d'aider en recherchant le nom de domaine complet. FQDN (Fully Qualified Domain Name) est un nom de domaine complet, comprenant le nom d'hôte et le nom de domaine. En recherchant le nom de domaine complet, vous pouvez vous assurer que l'hôte spécifié par l'utilisateur est localisé avec précision, fournissant ainsi une aide et des services précis. Par conséquent, la recherche du nom de domaine complet est une stratégie bénéfique lors de l’accès HTTPS.

Contenu de la question

J'utilise une application Golang qui communique avec le serveur via HTTPS sur un autre hôte. Plus précisément, si le contexte est important : communiquez avec un cluster Dataproc à partir d'une instance GCE dans le même projet Google Cloud (aucune configuration de domaine spéciale n'est requise).

Le serveur génère un certificat auto-signé, que j'ai installé manuellement sur le client.

Le serveur et le client sont des instances GCE sur mon projet Google Cloud (leur FQDN est <hostname>.c.<project_id>.internal)

Si j'essaie de me connecter au serveur à partir du client en utilisant le http.Client de Golang, j'obtiens une erreur comme celle-ci :

failed to verify certificate: x509: certificate is valid for *.c.<project_id>.internal, not <server_hostname>

Mais si je lui transmets son FQDN (<server_hostname>.c.<project_id>.internal), cela fonctionne immédiatement.

Pour information, ce comportement est cohérent avec ce que je vois lors de l'exécution de cURL :

curl: (60) SSL: no alternative certificate subject name matches target host name '<server_hostname>'

Ma question est donc :

1. Pourquoi cela ne fonctionne-t-il pas avec les noms d'hôtes courts/partiels ? C'est dans le même domaine, donc ça fait partie de *.c.<project_id>.internal et ça fonctionne immédiatement, n'est-ce pas ? Ou nécessite-t-il toujours que la chaîne transmise soit utilisée pour correspondre réellement à la chaîne générique (ce qui signifie qu'elle n'effectue pas de recherche et ne fonctionne que si vous transmettez un nom de domaine complet) ?
2. Quelles sont les meilleures pratiques lors de la création d'applications à distribuer ? Dois-je ajouter un peu de logique pour qu'il calcule le nom de domaine complet afin qu'il puisse convertir le nom court en un nom long plus susceptible d'être utilisé avec un certificat auto-signé, ou laisser à l'appelant le soin de découvrir l'erreur cryptique message? Li>

REMARQUE : je ne veux pas sauter la validation - je veux juste mieux comprendre ce qui se passe et savoir quelles sont les meilleures pratiques ici.

Merci !

Solution

1. Les certificats sont comparés aux domaines/hôtes en fonction des noms qu'ils contiennent, donc même si <server_hostname> et <server_hostname> 和 <server_hostname>.c.<project_id>.internal résolvent le même contenu, le certificat ne contient que le second (ou le caractère générique qu'il contient). allumettes). Comme ceux-ci sont auto-générés, vous pouvez y ajouter des noms courts en tant que SAN (Subject Alternative Names). Indicateurs supplémentaires pour OpenSSL :

-addext "subjectAltName = DNS:localhost,DNS:<server_hostname>"

Il est peu probable que les autorités de certification publiques vous fournissent un certificat avec un SAN qui ne peut pas être résolu publiquement. (Quelques possibilités, je ne l'ai pas essayé)

À titre d'exemple, vous ne voulez pas commencer par google.com.someevildomain.org 提供或信任 google.com, il s'agit donc d'une fonctionnalité de sécurité.

1. Cela dépend de la situation. Si vous contrôlez le certificat, ajoutez simplement le nom que vous souhaitez utiliser. Cela peut finir par être un certificat unique avec plusieurs SAN, auquel cas il peut être plus propre de faire parler tout le monde en utilisant un FQDN. Si vous pouvez importer de nombreux certificats, il est préférable que chaque service ait son propre certificat avec un nom de domaine complet et un nom court.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!