SSLのトラブルシューティング

このページでは、GitLabの使用中に発生する可能性のある、一般的なSSL関連のエラーとシナリオの一覧を示します。これは、SSLに関する主なドキュメントの追加として役立ちます:

• LinuxパッケージインストールのSSLを設定します。
• GitLab Runnerの自己署名証明書またはカスタム認証局を参照してください。
• HTTPSを手動で設定します。

OpenSSLのデバッグに役立つコマンド

ソースで直接表示することで、SSL証明書チェーンの全体像を把握できると役立つ場合があります。これらのコマンドは、診断とデバッグを行うための標準のOpenSSLライブラリツールの一部です。

• HTTPS経由でホストへのテスト接続を実行します。HOSTNAMEをGitLabのURL（HTTPSを除く）に置き換え、portをHTTPS接続を提供するポート（通常は443）に置き換えます:

  echo | /opt/gitlab/embedded/bin/openssl s_client -connect HOSTNAME:port

  echoコマンドは、サーバーにヌルリクエストを送信し、追加の入力を待機するのではなく、接続を閉じさせます。同じコマンドを使用して、リモートホスト（たとえば、外部リポジトリをホストするサーバー）をテストできます。HOSTNAME:portをリモートホストのドメインとポート番号に置き換えます。

  このコマンドの出力は、証明書チェーン、サーバーが提示するパブリック証明書、および発生した場合の検証または接続エラーを示します。これにより、SSL設定に関する直接的な問題をすばやく確認できます。

• x509を使用して、証明書の詳細をテキスト形式で表示します。必ず/path/to/certificate.crtを証明書のパスに置き換えてください:

  /opt/gitlab/embedded/bin/openssl x509 -in /path/to/certificate.crt -text -noout

  たとえば、GitLabはLet’s Encryptから取得した証明書を自動的に/etc/gitlab/ssl/hostname.crtに配置します。そのパスでx509コマンドを使用すると、証明書の情報を（たとえば、ホスト名、発行者、有効期限などを）すばやく表示できます。

  証明書に問題がある場合は、エラーが発生します。

• サーバーから証明書をフェッチし、デコードします。これにより、上記のコマンドの両方が組み合わされて、サーバーのSSL証明書をフェッチし、テキストにデコードされます:

  echo | /opt/gitlab/embedded/bin/openssl s_client -connect HOSTNAME:port | /opt/gitlab/embedded/bin/openssl x509 -text -noout

一般的なSSLエラー

1. SSL certificate problem: unable to get local issuer certificate

   このエラーは、クライアントがルート認証局を取得できないことを示します。この問題を解決するには、クライアントで接続しようとしているサーバーのルート認証局を信頼するか、証明書を修正して、接続しようとしているサーバーで完全なチェーン証明書を提示します。

   クライアントが接続するときにSSLエラーを防ぐために、完全な証明書チェーンを使用することをお勧めします。完全な証明書チェーンの順序は、最初にサーバー証明書、次いで全ての中間証明書、最後にルート認証局で構成される必要があります。

2. unable to verify the first certificate

   このエラーは、不完全な証明書チェーンがサーバーによって提示されていることを示します。このエラーを解決するには、サーバーの証明書を、完全なチェーン証明書に置き換える必要があります。完全な証明書チェーンの順序は、最初にサーバー証明書、次いで全ての中間証明書、最後にルート認証局で構成される必要があります。

   /opt/gitlab/embedded/bin/opensslユーティリティの代わりにシステムのOpenSSLユーティリティを実行中にこのエラーが発生した場合は、OSレベルでCA証明書を更新して修正してください。

3. certificate signed by unknown authority

   このエラーは、クライアントが証明書または認証局を信頼していないことを示します。このエラーを解決するには、サーバーに接続するクライアントは、証明書または認証局を信頼する必要があります。

4. SSL certificate problem: self signed certificate in certificate chain

   このエラーは、クライアントが証明書または認証局を信頼していないことを示します。このエラーを解決するには、サーバーに接続するクライアントは、証明書または認証局を信頼する必要があります。

5. x509: certificate relies on legacy Common Name field, use SANs instead

   このエラーは、SAN（subjectAltName）が証明書で構成されている必要があることを示します。詳細については、このイシューを参照してください。

証明書が原因で再構成に失敗する

ERROR: Not a certificate: /opt/gitlab/embedded/ssl/certs/FILE. Move it from /opt/gitlab/embedded/ssl/certs to a different location and reconfigure again.

/opt/gitlab/embedded/ssl/certsを確認し、有効なX.509証明書ではないREADME.md以外のファイルをすべて削除します。

カスタム証明書が見つからないかスキップされました

/opt/gitlab/embedded/ssl/certs/にシンボリックリンクが作成されず、gitlab-ctl reconfigureの実行後に「cert.pemをスキップしています」というメッセージが表示される場合は、4つの問題のいずれかが存在している可能性があります:

1. /etc/gitlab/trusted-certs/内のファイルはシンボリックリンクです
2. ファイルが有効なPEMまたはDERエンコード証明書ではありません
3. 証明書に文字列TRUSTEDが含まれています

次のコマンドを使用して、証明書の有効性をテストします:

/opt/gitlab/embedded/bin/openssl x509 -in /etc/gitlab/trusted-certs/example.pem -text -noout
/opt/gitlab/embedded/bin/openssl x509 -inform DER -in /etc/gitlab/trusted-certs/example.der -text -noout

無効な証明書ファイルは、次の出力を生成します:

• unable to load certificate
  140663131141784:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: TRUSTED CERTIFICATE

• cannot load certificate
  PEM_read_bio_X509_AUX() failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: TRUSTED CERTIFICATE)

これらのいずれの場合も、証明書が次のもの以外で開始および終了する場合は:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

それらはGitLabと互換性がありません。それらを証明書のコンポーネント（サーバー、中間、ルート）に分離し、互換性のあるPEM形式に変換する必要があります。

証明書自体を検査する場合は、文字列TRUSTEDを探します:

-----BEGIN TRUSTED CERTIFICATE-----
...
-----END TRUSTED CERTIFICATE-----

上記の例のようにそれがある場合は、文字列TRUSTEDを削除して、gitlab-ctl reconfigureを再度実行してみてください。

カスタム証明書が検出されない

gitlab-ctl reconfigureを実行した後:

1. /opt/gitlab/embedded/ssl/certs/にシンボリックリンクが作成されていません。
2. /etc/gitlab/trusted-certs/にカスタム証明書を配置しました。そして
3. スキップされたカスタム証明書メッセージまたはシンボリックリンクされたカスタム証明書メッセージは表示されません

Linuxパッケージのインストールで、カスタム証明書が既に追加されていると認識される問題が発生している可能性があります。

解決するには、信頼できる証明書ディレクトリのハッシュを削除します:

rm /var/opt/gitlab/trusted-certs-directory-hash

次に、gitlab-ctl reconfigureを再度実行します。再構成でカスタム証明書が検出され、シンボリックリンクされるはずです。

Let’s Encrypt証明書が不明な認証局によって署名されました

Let’s Encryptインテグレーションの最初の実装では、完全な証明書チェーンではなく、証明書のみが使用されていました。

バージョン10.5.4以降では、完全な証明書チェーンが使用されます。証明書を既に使用しているインストールの場合、切り替えは、更新ロジックが証明書の有効期限が近いことを示すまで行われません。すぐに強制するには、以下を実行します

rm /etc/gitlab/ssl/HOSTNAME*
gitlab-ctl reconfigure

HOSTNAMEは証明書のホスト名です。

Let’s Encryptが再構成に失敗しました

再構成すると、Let’s Encryptが失敗する可能性がある一般的なシナリオがあります:

• サーバーがLet’s Encrypt検証サーバーに到達できない場合、またはその逆の場合、Let’s Encryptが失敗する可能性があります:

  letsencrypt_certificate[gitlab.domain.com] (letsencrypt::http_authorization line 3) had an error: RuntimeError: acme_certificate[staging]  (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: RuntimeError: [gitlab.domain.com] Validation failed for domain gitlab.domain.com

  Let’s Encryptが原因でGitLabの再構成で問題が発生した場合は、必ずポート80および443が開いていてアクセスできることを確認してください。

• ドメインの認証局認可（CAA）レコードでは、Let’s Encryptがドメインの証明書を発行することを許可していません。再構成出力で次のエラーを探します:

  letsencrypt_certificate[gitlab.domain.net] (letsencrypt::http_authorization line 5) had an error: RuntimeError: acme_certificate[staging]   (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 25) had an error: RuntimeError: ruby_block[create certificate for gitlab.domain.net] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/acme/resources/certificate.rb line 108) had an error: RuntimeError: [gitlab.domain.com] Validation failed, unable to request certificate

• gitlab.example.comなどのテストドメインを証明書なしで使用している場合は、上記のunable to request certificateエラーが表示されます。その場合は、/etc/gitlab/gitlab.rbでletsencrypt['enable'] = falseを設定して、Let’s Encryptを除外します。

• Let’s Encryptのレート制限が適用され、最上位ドメインにあります。たとえば、クラウドプロバイダーのホスト名をexternal_urlとして使用している場合（たとえば、*.cloudapp.azure.com）、Let’s Encryptはazure.comに制限を適用するため、証明書の作成が不完全になる可能性があります。

  その場合は、Let’s Encrypt証明書の手動更新を試すことができます:

  sudo gitlab-ctl renew-le-certs

GitLabで内部認証局証明書を使用する

内部認証局証明書を使用してGitLabインスタンスを構成した後、さまざまなCLIツールを使用してアクセスできない場合があります。次の問題が発生する可能性があります:

• curlが失敗します:

  curl "https://gitlab.domain.tld"
  curl: (60) SSL certificate problem: unable to get local issuer certificate
  More details here: https://curl.haxx.se/docs/sslcerts.html

• Railsコンソールを使用したテストも失敗します:

  uri = URI.parse("https://gitlab.domain.tld")
  http = Net::HTTP.new(uri.host, uri.port)
  http.use_ssl = true
  http.verify_mode = 1
  response = http.request(Net::HTTP::Get.new(uri.request_uri))
  ...
  Traceback (most recent call last):
        1: from (irb):5
  OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate))

• このGitLabインスタンスからのミラーを設定すると、エラーSSL certificate problem: unable to get local issuer certificateが表示されます。

• 証明書のパスを指定すると、opensslが機能します:

  /opt/gitlab/embedded/bin/openssl s_client -CAfile /root/my-cert.crt -connect gitlab.domain.tld:443

以前に説明した問題が発生した場合は、証明書を/etc/gitlab/trusted-certsに追加し、sudo gitlab-ctl reconfigureを実行します。

X.509キー値が一致しないエラー

証明書バンドルを使用してインスタンスを構成すると、NGINXに次のエラーメッセージが表示される場合があります:

SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

このエラーメッセージは、指定したサーバー証明書とキーが一致しないことを意味します。これを確認するには、次のコマンドを実行して出力を比較します:

openssl rsa -noout -modulus -in path/to/your/.key | openssl md5
openssl x509 -noout -modulus -in path/to/your/.crt | openssl md5

次は、一致するキーと証明書の間にあるmd5出力の例です。一致するmd5ハッシュに注意してください:

$ openssl rsa -noout -modulus -in private.key | openssl md5
4f49b61b25225abeb7542b29ae20e98c
$ openssl x509 -noout -modulus -in public.crt | openssl md5
4f49b61b25225abeb7542b29ae20e98c

これは、一致しないキーと証明書を使用した反対の出力で、異なるmd5ハッシュを示しています:

$ openssl rsa -noout -modulus -in private.key | openssl md5
d418865077299af27707b1d1fa83cd99
$ openssl x509 -noout -modulus -in public.crt | openssl md5
4f49b61b25225abeb7542b29ae20e98c

2つの出力が前の例のように異なる場合、証明書とキーの間に不一致があります。詳細については、SSL証明書のプロバイダーにお問い合わせください。

エラー: certificate signed by unknown authority

GitLabで内部認証局証明書を使用するで言及されているエラーが発生するだけでなく、CIパイプラインがPendingステータスで停止する可能性があります。Runnerログに次のエラーメッセージが表示される場合があります:

Dec  6 02:43:17 runner-host01 gitlab-runner[15131]: #033[0;33mWARNING: Checking for jobs... failed
#033[0;m  #033[0;33mrunner#033[0;m=Bfkz1fyb #033[0;33mstatus#033[0;m=couldn't execute POST against
https://gitlab.domain.tld/api/v4/jobs/request: Post https://gitlab.domain.tld/api/v4/jobs/request:
x509: certificate signed by unknown authority

GitLab Runnerの自己署名証明書またはカスタム認証局の詳細に従ってください。

自己署名SSL証明書を使用するリモートGitLabリポジトリをミラーリングする

自己署名証明書を使用するリモートGitLabインスタンスからリポジトリをミラーリングするようにローカルのGitLabインスタンスを構成すると、ユーザーインターフェースにSSL certificate problem: self signed certificateエラーメッセージが表示される場合があります。

問題の原因は、以下を確認することで確認できます:

• curlが失敗します:

  $ curl "https://gitlab.domain.tld"
  curl: (60) SSL certificate problem: self signed certificate
  More details here: https://curl.haxx.se/docs/sslcerts.html

• Railsコンソールを使用したテストも失敗します:

  uri = URI.parse("https://gitlab.domain.tld")
  http = Net::HTTP.new(uri.host, uri.port)
  http.use_ssl = true
  http.verify_mode = 1
  response = http.request(Net::HTTP::Get.new(uri.request_uri))
  ...
  Traceback (most recent call last):
        1: from (irb):5
  OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate))

この問題を修正するには、以下を実行します:

• リモートのGitLabインスタンスからの自己署名証明書をローカルのGitLabインスタンスの/etc/gitlab/trusted-certsディレクトリに追加し、カスタムパブリック証明書のインストールの手順に従ってsudo gitlab-ctl reconfigureを実行します。
• Helmチャートを使用してローカルのGitLabインスタンスをインストールした場合は、自己署名証明書をGitLabインスタンスに追加できます。

自己署名証明書を使用するリモートGitLabインスタンスからリポジトリをミラーリングしようとすると、別のエラーメッセージが表示されることもあります:

2:Fetching remote upstream failed: fatal: unable to access 'https://gitlab.domain.tld/root/test-repo/':
SSL: unable to obtain common name from peer certificate

この場合、問題は証明書自体に関連している可能性があります:

1. 自己署名証明書に共通名が欠落していないことを検証します。そうである場合は、有効な証明書を再生成します
2. 証明書を/etc/gitlab/trusted-certsに追加します。
3. sudo gitlab-ctl reconfigureを実行します。

内部証明書または自己署名証明書が原因でGit操作を実行できない

GitLabインスタンスが自己署名証明書を使用している場合、または証明書が内部認証局（CA）によって署名されている場合は、Git操作を実行しようとすると、次のエラーが発生する可能性があります:

$ git clone https://gitlab.domain.tld/group/project.git
Cloning into 'project'...
fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': SSL certificate problem: self signed certificate

$ git clone https://gitlab.domain.tld/group/project.git
Cloning into 'project'...
fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

この問題を修正するには、以下を実行します:

• 可能であれば、すべてのGit操作にSSHリモートを使用します。これは、より安全で使いやすいと考えられています。
• HTTPSリモートを使用する必要がある場合は、以下を試すことができます:

  • 自己署名証明書または内部ルートCA証明書をローカルディレクトリ（たとえば、~/.ssl）にコピーし、証明書を信頼するようにGitを構成します:

    git config --global http.sslCAInfo ~/.ssl/gitlab.domain.tld.crt

  • GitクライアントでSSL検証を無効にします。これは、セキュリティリスクと見なされる可能性があるため、一時的な手段として意図されています。

    git config --global http.sslVerify false

SSL_connectの間違ったバージョン番号

設定ミスにより、次の結果になる可能性があります:

• 次の内容を含むgitlab-rails/exceptions_json.logエントリ:

  "exception.class":"Excon::Error::Socket","exception.message":"SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)",
  "exception.class":"Excon::Error::Socket","exception.message":"SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)",

• 次の内容を含むgitlab-workhorse/current:

  http: server gave HTTP response to HTTPS client
  http: server gave HTTP response to HTTPS client

• 次の内容を含むgitlab-rails/sidekiq.logまたはsidekiq/current:

  message: SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)
  message: SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)

これらのエラーの一部はExcon Ruby gemから発生しており、GitLabがHTTPのみをサービスしているリモートサーバーへのHTTPSセッションを開始するように構成されている状況で生成される可能性があります。

1つのシナリオは、HTTPSで提供されていないオブジェクトストレージを使用していることです。GitLabは設定ミスされており、TLSハンドシェイクを試みますが、オブジェクトストレージはプレーンHTTPで応答します。

schannel: SEC_E_UNTRUSTED_ROOT

Windowsを使用している場合に、次のエラーが発生した場合:

Fatal: unable to access 'https://gitlab.domain.tld/group/project.git': schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted."

GitがOpenSSLを使用するように指定する必要があります:

git config --system http.sslbackend openssl

または、次を実行してSSL検証を無視できます:

git config --global http.sslVerify false

OpenSSL 3へのアップグレード

バージョン17.7以降、GitLabはOpenSSL 3を使用します。古いTLSプロトコルや暗号スイート、または外部インテグレーションに使用する脆弱なTLS証明書の一部は、OpenSSL 3のデフォルトと互換性がない場合があります。

OpenSSL 3へのアップグレードにより、以下が必要になります:

• すべての受信および発信TLS接続には、TLS 1.2以上が必要です。
• TLS証明書には、少なくとも112ビットのセキュリティが必要です。2048ビット未満のRSA、DSA、DHキー、および224ビット未満のECCキーは禁止されています。

次のいずれかのエラーメッセージが発生する可能性があります:

• TLS接続でTLS 1.2より前のプロトコルを使用すると、no protocols availableが表示されます。
• TLS証明書のセキュリティが112ビット未満の場合、certificate key too weakが表示されます。
• レガシー暗号がリクエストされると、unsupported cipher algorithmが表示されます。

外部インテグレーションの互換性を特定して評価するには、OpenSSL 3ガイドを使用してください。