fatal: unable to access 'https://git.example.com/team/app.git/': SSL: certificate subject name (www.example.com) does not match target hostname 'git.example.com'

括弧内と引用符内の名前は、それぞれ証明書とリモート URL から取られています。libcurl 7.x は「target host name」、libcurl 8.x は「target hostname」と出力します。OpenSSL でビルドされた git（Git for Windows、Alpine）は「SSL: no alternative certificate subject name matches target hostname '…'」と出力します。

このエラーの意味

Git サーバーの証明書は信頼されていますが、リモート URL のホストとは別の名前に対して発行されています。libcurl-gnutls は、証明書のサブジェクト名を括弧内に、git が接続したホストを末尾に示します。認証情報は送信されていません。接続は HTTP リクエストを送る前に停止しています。

発生する理由

• 証明書に Git ホストの名前が記載されていない

  よくある

  Git サーバーが証明書を再発行しないまま、新しい名前に移行した（gitlab.example.com ではなく git.example.com）か、2 つ目の名前を追加した場合です。

• リモート URL がエイリアスや IP アドレスを使っている

  よくある

  社内のエイリアス、IP アドレス、古いホスト名で clone したリポジトリは、正式な名前に対して証明書が発行された後も、長い間その URL を設定ファイル .git/config に保持し続けます。

• Git サーバーの前段にあるプロキシがデフォルトの証明書を送信している

  ときどき

  要求された名前に対するルールがないリバースプロキシや Ingress は、別の仮想ホストの証明書を提示します。

修正方法

1. 1.

   リモート URL と証明書を比較する

   リモート URL と、証明書のサブジェクトおよび SAN のリストを出力してください。たいていは不一致がすぐにわかります。

   git remote get-url origin
   echo | openssl s_client -connect git.example.com:443 -servername git.example.com 2>/dev/null \
     | openssl x509 -noout -subject -ext subjectAltName

2. 2.

   証明書がカバーする名前をリモートに指定する

   git remote set-url を使うと、clone し直さずに、リポジトリの設定に保存された URL を変更できます。

   # Use the name the certificate was issued for
   git remote set-url origin https://gitlab.example.com/team/app.git

3. 3.

   サーバー運営者：公開している名前に対して証明書を発行する

   証明書の SAN のリストを、Git サーバーが clone 用に提示する URL（GitLab の external_url、Gitea の ROOT_URL）と一致させてください。そうすれば、ユーザーがコピーする URL で検証が成功します。

   # GitLab Omnibus: the external URL decides the certificate name and the clone URLs
   external_url "https://git.example.com"
   # then: sudo gitlab-ctl reconfigure

← 署名エラーデータベースをすべて見る