透過 HTTPS 存取使用者指定主機的應用程式是否應該嘗試透過尋找其 FQDN 來提供協助？

透過HTTPS存取使用者指定主機的應用程式是一個常見的需求，但在實際應用中可能會遇到一些困惑。對於這個問題，php小編香蕉認為應該嘗試透過尋找FQDN來提供幫助。 FQDN（Fully Qualified Domain Name）是一個完全限定的域名，包含主機名稱和域名。透過尋找FQDN，可以確保準確地定位到使用者指定的主機，從而提供準確的幫助和服務。因此，在進行HTTPS訪問時，尋找FQDN是一個有益的策略。

問題內容

我正在使用一個 golang 應用程序，該應用程式透過另一台主機上的 HTTPS 與伺服器進行通訊。具體來說，如果上下文很重要：從同一 Google Cloud 專案中的 GCE 實例與 Dataproc 叢集進行通訊（無需特殊的網域設定）。

伺服器產生一個自簽名證書，我已在客戶端手動安裝該證書。

伺服器和用戶端都是我的 Google 雲端專案上的 GCE 實例（它們的 FQDN 是 <hostname>.c.<project_id>.internal</project_id></hostname>）

如果我嘗試使用 golang 的 http.Client 從客戶端連接到伺服器，我會收到以下錯誤：

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

但是，如果我將其 FQDN 傳遞給它（<server_hostname>.c.<project_id>.internal</project_id></server_hostname>），則它可以開箱即用。

僅供參考，此行為與我執行 cURL 時看到的一致：

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

所以我的問題是：

1. 為什麼它不適用於短/部分主機名稱？它位於同一網域中，因此它是 *.c.<project_id>.internal</project_id> 的一部分，並且開箱即用，不是嗎？或者它是否總是要求使用傳入的字串來實際匹配通配符字串（這意味著它不進行查找，並且僅在您傳入 fqdn 時才有效）？
2. 建立要分發的應用程式時，最佳實踐是什麼？我是否應該添加一些邏輯來讓它計算 FQDN，以便它可以將短名稱轉換為更可能與自簽名憑證一起使用的長名稱，或者將其留給呼叫者來找出神秘的錯誤訊息？李>

注意：我不想跳過驗證 - 我只是想更好地了解正在發生的事情，並知道這裡的最佳實踐是什麼。

謝謝！

解決方法

1. 憑證根據其中包含的名稱與網域/主機進行匹配，因此即使<server_hostname></server_hostname> 和<server_hostname>.c.<project_id>.internal</project_id></server_hostname> 解析為相同的內容，證書僅包含第二個（或與其匹配的通配符） 。由於這些是自行產生的，因此您可以在其中添加短名稱作為 SAN（主題備用名稱）。 OpenSSL 的附加標誌：

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

公共 CA 不太可能為您提供具有不可公開解析的 SAN 的憑證。 （有些可能，我沒試過）

作為範例，您不希望從 google.com.someevildomain.org 提供或信任 google.com，因此這是一項安全功能。

1. 這要看情況。如果您可以控制證書，則只需新增您希望使用的名稱即可。這可能最終成為具有許多 SAN 的單一證書，在這種情況下，讓每個人都使用 FQDN 進行交談可能會更乾淨。如果您可以匯入許多證書，那麼最好讓每個服務都有自己的帶有 FQDN 和短名稱的證書。

以上是透過 HTTPS 存取使用者指定主機的應用程式是否應該嘗試透過尋找其 FQDN 來提供協助？的詳細內容。更多資訊請關注PHP中文網其他相關文章！