SSLをLinuxパッケージインストール用に設定する

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

Linuxパッケージは、SSLの設定に関する一般的なユースケースをいくつかサポートしています。

デフォルトでは、HTTPSは有効になっていません。HTTPSを有効にするには、次のいずれかの手順を実行します:

Let’s Encryptを使用して無料の自動HTTPSを利用する。
独自の証明書を使用してHTTPSを手動で設定する。

プロキシ、ロードバランサー、またはその他の外部デバイスを使用してGitLabホスト名のSSLを終端する場合、外部、プロキシ、およびロードバランサーのSSL終端を参照してください。

次の表は、各GitLabサービスがサポートする方法を示しています。

サービス	手動SSL	Let’s Encryptのインテグレーション
GitLabインスタンスのドメイン	はい	はい
コンテナレジストリ	はい	はい
Mattermost	はい	はい
GitLab Pages	はい	はい

OpenSSL 3へのアップグレード

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

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

GitLab 17.7にアップグレードした後、次のコマンドでGitLabがOpenSSL 3を使用していることを確認できます:

/opt/gitlab/embedded/bin/openssl version

Let’s Encryptインテグレーションを有効にする

external_urlがHTTPSプロトコルで設定され、他の証明書が設定されていない場合、Let’s Encryptはデフォルトで有効になります。

前提条件:

検証チェックを実行する公開Let’s Encryptサーバーから、ポート80および443にアクセスできる必要があります。検証は、標準以外のポートでは機能しません。環境がエアギャップ環境またはプライベート環境の場合、certbot（Let’s Encryptで使用されるツール）は、Let’s Encrypt証明書をインストールするための手動の方法を提供しています。

Let’s Encryptを有効にするには:

/etc/gitlab/gitlab.rbを編集し、次のエントリを追加または変更します:
```
## GitLab instance
external_url "https://gitlab.example.com"         # Must use https protocol
letsencrypt['contact_emails'] = ['foo@email.com'] # Optional

## Container Registry (optional), must use https protocol
registry_external_url "https://registry.example.com"
#registry_nginx['ssl_certificate'] = "path/to/cert"      # Must be absent or commented out

## Mattermost (optional), must use https protocol
mattermost_external_url "https://mattermost.example.com"

## GitLab Pages (optional), must use https protocol
pages_external_url "https://pages.example.com"
gitlab_pages['namespace_in_path'] = true      # Required to enable single-domain sites
```
- 証明書の有効期限は90日ごとに切れます。有効期限が近づくと、contact_emailsに指定したメールアドレス宛てにアラートが送信されます。
- GitLabインスタンスは、証明書上のプライマリドメイン名です。コンテナレジストリなどの追加サービスは、同じ証明書の代替ドメイン名として追加されます。上記の例では、プライマリドメインはgitlab.example.comであり、コンテナレジストリのドメインはregistry.example.comです。ワイルドカード証明書をセットアップする必要はありません。
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

Let’s Encryptが証明書の発行に失敗した場合は、考えられる解決策についてトラブルシューティングセクションを参照してください。

証明書を自動的に更新する

デフォルトのインストールでは、毎月4日の午前0時以降に更新がスケジュールされます。実行される分は、アップストリームLet’s Encryptサーバーへの負荷を分散するために、external_urlの値によって決定されます。

更新時間を明示的に設定するには:

/etc/gitlab/gitlab.rbを編集します:

# Renew every 7th day of the month at 12:30
letsencrypt['auto_renew_hour'] = "12"
letsencrypt['auto_renew_minute'] = "30"
letsencrypt['auto_renew_day_of_month'] = "*/7"

GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

証明書は30日以内に期限切れになる場合にのみ更新されます。たとえば、毎月1日の午前00:00に更新するように設定し、証明書の有効期限が31日である場合、証明書は更新前に期限切れになります。

自動更新はgo-crondで管理されます。必要に応じて、/etc/gitlab/gitlab.rbを編集して、CLI引数をgo-crondに渡すことができます:

crond['flags'] = {
  'log.json' = true,
  'server.bind' = ':8040'
}

自動更新を無効にするには:

/etc/gitlab/gitlab.rbを編集します:
```
letsencrypt['auto_renew'] = false
```
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

証明書を手動で更新する

次のいずれかのコマンドを使用して、Let’s Encrypt証明書を手動で更新します:

sudo gitlab-ctl reconfigure

sudo gitlab-ctl renew-le-certs

前述のコマンドは、証明書が有効期限に近い場合にのみ更新を生成します。更新中にエラーが発生した場合は、アップストリームのレート制限を考慮してください。

Let’s Encrypt以外のACMEサーバーを使用する

Let’s Encrypt以外のACMEサーバーを使用し、それを使用して証明書をフェッチするようにGitLabを設定できます。独自のACMEサーバーを提供するサービスには、次のものがあります:

カスタムACMEサーバーを使用するようにGitLabを設定するには:

/etc/gitlab/gitlab.rbを編集し、ACMEエンドポイントを設定します:
```
external_url 'https://example.com'
letsencrypt['acme_staging_endpoint'] = 'https://ca.internal/acme/acme/directory'
letsencrypt['acme_production_endpoint'] = 'https://ca.internal/acme/acme/directory'
```
カスタムACMEサーバーが提供している場合は、ステージングエンドポイントも使用してください。先にステージングエンドポイントをチェックしておくと、ACME本番環境にリクエストを送信する前に、ACME設定が正しいことを確認できます。設定作業中にACMEのレート制限を回避するために、この手順を実施してください。
デフォルト値は次のとおりです:
```
https://acme-staging-v02.api.letsencrypt.org/directory
https://acme-v02.api.letsencrypt.org/directory
```
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

証明書に代替ドメインを追加する

デフォルトでは、GitLabは証明書の共通名（CN）とサブジェクトの代替名（SAN）をexternal_urlで指定されたホスト名に設定します。

追加の代替ドメイン（またはサブジェクト代替名）をLet’s Encrypt証明書に追加できます。これは、バンドルされたNGINXを他のバックエンドアプリケーション向けのリバースプロキシとして使用する場合に役立ちます。

代替ドメインのDNSレコードは、GitLabインスタンスを指している必要があります。external_urlのホスト名は、サブジェクト代替名のリストに含まれている必要があります。

代替ドメインをLet’s Encrypt証明書に追加するには:

/etc/gitlab/gitlab.rbを編集し、代替ドメインを追加します:

# Separate multiple domains with commas
letsencrypt['alt_names'] = ['gitlab.example.com', 'another-application.example.com']

GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

その結果、メインのGitLabアプリケーション用に生成されたLet’s Encrypt証明書には、指定した代替ドメインが含まれます。生成されたファイルは、次の場所にあります:

キーは/etc/gitlab/ssl/gitlab.example.com.key。
証明書は/etc/gitlab/ssl/gitlab.example.com.crt。

HTTPSを手動で設定する

NGINXの設定は、ブラウザとクライアントに対し、今後365日間、GitLabインスタンスと安全な接続のみで通信するよう、HSTSを使用して指示します。詳細な設定オプションについては、HTTP Strict Transport Securityを設定するを参照してください。HTTPSを有効にする場合は、少なくとも今後24か月間、インスタンスへの安全な接続を提供する必要があります。

HTTPSを有効にするには:

/etc/gitlab/gitlab.rbを編集します:
1. お使いのドメインをexternal_urlに設定します。URLのhttpsに注意してください:
```
external_url "https://gitlab.example.com"
```
2. Let’s Encryptインテグレーションを無効にします:
```
letsencrypt['enable'] = false
```
  GitLabは、再設定を実行するたびにLet’s Encrypt証明書の更新を試みます。手動で作成した独自の証明書を使用する予定がある場合は、Let’s Encryptインテグレーションを無効にする必要があります。そうしないと、自動更新により証明書が上書きされる可能性があります。
/etc/gitlab/sslディレクトリを作成し、キーと証明書をそこにコピーします。
```
sudo mkdir -p /etc/gitlab/ssl
sudo chmod 755 /etc/gitlab/ssl
sudo cp gitlab.example.com.key gitlab.example.com.crt /etc/gitlab/ssl/
sudo chmod 644 /etc/gitlab/ssl/gitlab.example.com.crt
sudo chmod 600 /etc/gitlab/ssl/gitlab.example.com.key
```
この例では、ホスト名はgitlab.example.comであるため、Linuxパッケージインストールは、/etc/gitlab/ssl/gitlab.example.com.keyという秘密キーファイルと/etc/gitlab/ssl/gitlab.example.com.crtという公開証明書ファイルをそれぞれ検索します。必要に応じて、別の場所や別の証明書名を使用することもできます。
クライアント接続時のSSLエラーを防ぐため、完全な証明書チェーンを正しい順序で使用する必要があります。最初にサーバー証明書、次に中間証明書、最後にルート認証局を配置してください。
オプション。certificate.keyファイルがパスワードで保護されている場合、GitLabを再設定するときに、NGINXはパスワードを要求しません。その場合、Linuxパッケージインストールはエラーメッセージを表示せずにサイレントに失敗します。
キーファイルのパスワードを指定するには、パスワードをテキストファイル（例: /etc/gitlab/ssl/key_file_password.txt）に保存し、/etc/gitlab/gitlab.rbに以下を追加します:
```
nginx['ssl_password_file'] = '/etc/gitlab/ssl/key_file_password.txt'
```
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

オプション。ファイアウォールを使用している場合は、受信HTTPSトラフィックを許可するためにポート443を開放する必要がある場合があります:

# UFW example (Debian, Ubuntu)
sudo ufw allow https

# lokkit example (RedHat, CentOS 6)
sudo lokkit -s https

# firewall-cmd (RedHat, Centos 7)
sudo firewall-cmd --permanent --add-service=https
sudo systemctl reload firewalld

既存の証明書を更新する場合は、別の手順に従ってください。

`HTTP`リクエストを`HTTPS`にリダイレクトする

デフォルトでは、httpsで始まるexternal_urlを指定すると、NGINXはポート80で暗号化されていないHTTPトラフィックをリッスンしなくなります。すべてのHTTPトラフィックをHTTPSにリダイレクトするには:

/etc/gitlab/gitlab.rbを編集します:
```
nginx['redirect_http_to_https'] = true
```
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

この動作は、Let’s Encryptインテグレーションを使用する場合、デフォルトで有効になります。

デフォルトのHTTPSポートを変更する

デフォルト（443）以外のHTTPSポートを使用する必要がある場合は、external_urlの一部として指定します:

/etc/gitlab/gitlab.rbを編集します:

external_url "https://gitlab.example.com:2443"

GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

デフォルトのSSL証明書の場所を変更する

ホスト名がgitlab.example.comの場合、Linuxパッケージインストールは、/etc/gitlab/ssl/gitlab.example.com.keyという秘密キーと、/etc/gitlab/ssl/gitlab.example.com.crtという公開証明書をデフォルトで検索します。

SSL証明書の場所を変更するには:

ディレクトリを作成し、適切な権限を付与して、そのディレクトリに.crtファイルと.keyファイルを配置します:
```
sudo mkdir -p /mnt/gitlab/ssl
sudo chmod 755 /mnt/gitlab/ssl
sudo cp gitlab.key gitlab.crt /mnt/gitlab/ssl/
```
クライアント接続時のSSLエラーを防ぐため、完全な証明書チェーンを正しい順序で使用する必要があります。最初にサーバー証明書、次に中間証明書、最後にルート認証局を配置してください。

/etc/gitlab/gitlab.rbを編集します:

nginx['ssl_certificate'] = "/mnt/gitlab/ssl/gitlab.crt"
nginx['ssl_certificate_key'] = "/mnt/gitlab/ssl/gitlab.key"

GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

SSL証明書を更新する

SSL証明書の内容が更新されていても、/etc/gitlab/gitlab.rbに設定の変更が加えられていない場合、GitLabを再設定してもNGINXには反映されません。代わりに、NGINXに既存の設定と新しい証明書を正常に再読み込みさせる必要があります:

sudo gitlab-ctl hup nginx
sudo gitlab-ctl hup registry

リバースプロキシまたはロードバランサーのSSL終端を設定する

デフォルトでは、external_urlにhttps://が含まれている場合、LinuxパッケージインストールはSSLを使用するかどうかを自動検出し、NGINXをSSL終端用に設定します。ただし、リバースプロキシまたは外部ロードバランサーの背後で実行するようにGitLabを設定する場合、一部の環境ではGitLabアプリケーションの外部でSSLを終端したいことがあります。

バンドルされたNGINXがSSL終端を処理しないようにするには:

/etc/gitlab/gitlab.rbを編集します:

nginx['listen_port'] = 80
nginx['listen_https'] = false

GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

外部ロードバランサーでは、200ステータスコードを返すGitLabエンドポイントへのアクセスが必要になる場合があります（ログインが必要なインストールでは、ルートページがログインページへの302リダイレクトを返します）。その場合は、ヘルスチェックエンドポイントを利用することをおすすめします。

コンテナレジストリ、GitLab Pages、Mattermostなど、バンドルされている他のコンポーネントも、プロキシ経由のSSLに同様の戦略を使用します。特定のコンポーネントの*_external_urlをhttps://で設定し、nginx[...]の設定にはコンポーネント名のプレフィックスを付けます。たとえば、GitLabコンテナレジストリの設定には、registry_をプレフィックスとして使用します:

/etc/gitlab/gitlab.rbを編集します:
```
registry_external_url 'https://registry.example.com'

registry_nginx['listen_port'] = 80
registry_nginx['listen_https'] = false
```
同じ形式をPages（pages_プレフィックス）およびMattermost（mattermost_プレフィックス）でも使用できます。
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```
オプション。特定のヘッダー（たとえば、Host、X-Forwarded-Ssl、X-Forwarded-For、X-Forwarded-Port）をGitLab（およびMattermostを使用している場合はMattermost）に転送するよう、リバースプロキシまたはロードバランサーを設定する必要がある場合があります。この手順を忘れると、不適切なリダイレクトや、「422 Unprocessable Entity」や「Can’t verify CSRF token authenticity」といったエラーが表示されることがあります。

AWS Certificate Manager（ACM）などの一部のクラウドプロバイダーサービスでは、証明書のダウンロードが許可されていません。そのため、GitLabインスタンス上でそれらを使用してSSLを終端させることができません。そのようなクラウドプロバイダーサービスとGitLabの間でSSLが必要な場合は、GitLabインスタンスで別の証明書を使用する必要があります。

カスタムSSL暗号スイートを使用する

デフォルトでは、Linuxパッケージは、https://gitlab.comでのテストと、GitLabコミュニティが提供するさまざまなベストプラクティスを組み合わせたSSL暗号スイートを使用します。

SSL暗号スイートを変更するには:

/etc/gitlab/gitlab.rbを編集します:
```
nginx['ssl_ciphers'] = "CIPHER:CIPHER1"
```
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

ssl_dhparamディレクティブを有効にするには:

dhparams.pemを生成します:

openssl dhparam -out /etc/gitlab/ssl/dhparams.pem 2048

/etc/gitlab/gitlab.rbを編集します:

nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparams.pem"

GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

HTTP/2プロトコルを設定する

デフォルトでは、GitLabインスタンスにHTTPS経由で到達できるよう指定すると、HTTP/2プロトコルも有効になります。

Linuxパッケージは、HTTP/2プロトコルと互換性のある必要なSSL暗号スイートを設定します。

独自のカスタムSSL暗号スイートを指定し、その中にHTTP/2暗号ブラックリストに含まれるものがある場合、GitLabインスタンスにアクセスしようとすると、ブラウザにINADEQUATE_SECURITYエラーが表示されます。その場合は、問題のある暗号スイートを暗号リストから削除することを検討してください。暗号スイートの変更が必要になるのは、非常に特殊なカスタム構成の場合のみです。

HTTP/2プロトコルを有効にする理由の詳細については、NGINX HTTP/2ホワイトペーパーを参照してください。

暗号スイートの変更という選択肢がとれない場合は、HTTP/2サポートを無効にできます:

/etc/gitlab/gitlab.rbを編集します:
```
nginx['http2_enabled'] = false
```
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

HTTP/2設定は、mainのGitLabアプリケーションでのみ機能し、GitLab Pages、コンテナレジストリ、Mattermostなどの他のサービスでは機能しません。

双方向SSLクライアント認証を有効にする

Webクライアントに信頼できる証明書で認証させる必要がある場合は、双方向SSLを有効にできます:

/etc/gitlab/gitlab.rbを編集します:

nginx['ssl_verify_client'] = "on"
nginx['ssl_client_certificate'] = "/etc/pki/tls/certs/root-certs.pem"

オプション。クライアントに有効な証明書がないと判断する前に、証明書チェーンのどの深さまでNGINXが検証するかを設定できます（デフォルトは1です）。/etc/gitlab/gitlab.rbを編集します:
```
nginx['ssl_verify_depth'] = "2"
```
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

HTTP Strict Transport Security（HSTS）を設定する

HSTS設定は、mainのGitLabアプリケーションでのみ機能し、GitLab Pages、コンテナレジストリ、Mattermostなどの他のサービスでは機能しません。

HTTP Strict Transport Security（HSTS）はデフォルトで有効になっており、HTTPSのみを使用してWebサイトにアクセスする必要があることをブラウザに通知します。ブラウザがGitLabインスタンスに1回でもアクセスすると、ユーザーがプレーンなHTTP URL（http://）を明示的に入力している場合でも脆弱な接続を試行しないように記憶します。プレーンなHTTP URLは、ブラウザによってhttps://バリアントに自動的にリダイレクトされます。

デフォルトでは、max_ageは2年に設定されており、これはブラウザがHTTPS経由でのみ接続することを記憶する期間です。

max_ageの値を変更するには:

/etc/gitlab/gitlab.rbを編集します:
```
nginx['hsts_max_age'] = 63072000
nginx['hsts_include_subdomains'] = false
```
max_ageを0に設定すると、HSTSが無効になります。
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

HSTSとNGINXの詳細については、https://blog.nginx.org/blog/http-strict-transport-security-hsts-and-nginxを参照してください。

カスタム公開証明書をインストールする

一部の環境では、さまざまなタスクのために外部リソースに接続しており、GitLabではこれらの接続にHTTPSを使用でき、自己署名証明書を使用した接続もサポートしています。GitLabには独自のCA証明書バンドルがあり、/etc/gitlab/trusted-certsディレクトリに個別のカスタム証明書を配置することで証明書を追加できます。その後、それらはバンドルに追加されます。追加にはopenssl rehashコマンドが使用されますが、このコマンドは単一の証明書でのみ機能します。

Linuxパッケージには、証明書の信頼性を検証するために使用される、Mozilla公式の信頼できるルート認証局コレクションが付属しています。

自己署名証明書を使用するインストールの場合、Linuxパッケージはこれらの証明書を管理する方法を提供します。この仕組みの技術的な詳細については、このページの下部にある詳細を参照してください。

カスタム公開証明書をインストールするには:

秘密キー証明書から、PEMまたはDERエンコードされた公開証明書を生成します。
公開証明書ファイルのみを/etc/gitlab/trusted-certsディレクトリにコピーします。マルチノードインストールの場合は、必ずすべてのノードに証明書をコピーしてください。
- カスタム公開証明書を使用するようにGitLabを設定する場合、GitLabはデフォルトで、GitLabドメイン名に.crt拡張子を付けた名前の証明書があることを想定します。たとえば、サーバーアドレスがhttps://gitlab.example.comの場合、証明書の名前はgitlab.example.com.crtにする必要があります。
- GitLabがカスタム公開証明書を使用する外部リソースに接続する必要がある場合は、その証明書を.crt拡張子付きで/etc/gitlab/trusted-certsディレクトリに保存します。この場合、関連する外部リソースのドメイン名に基づいてファイル名を付ける必要はありませんが、一貫した命名規則を使用することをおすすめします。
別のパスとファイル名を指定するには、デフォルトのSSL証明書の場所を変更できます。
GitLabを再設定します:
```
sudo gitlab-ctl reconfigure
```

カスタム証明書チェーンを使用する

既知の問題により、カスタム証明書チェーンを使用する場合は、サーバー証明書、中間証明書、ルート証明書は、/etc/gitlab/trusted-certsディレクトリ内の別々のファイルに配置する必要があります。

これは、GitLab自体がカスタム証明書チェーンを使用する場合にも、GitLabが接続する必要がある外部リソースがカスタム証明書チェーンを使用する場合にもあてはまります。

たとえば、GitLab自体の場合、次を使用できます:

/etc/gitlab/trusted-certs/example.gitlab.com.crt
/etc/gitlab/trusted-certs/example.gitlab.com_intermediate.crt
/etc/gitlab/trusted-certs/example.gitlab.com_root.crt

GitLabが接続する必要がある外部リソースの場合は、次を使用できます:

/etc/gitlab/trusted-certs/external-service.gitlab.com.crt
/etc/gitlab/trusted-certs/external-service.gitlab.com_intermediate.crt
/etc/gitlab/trusted-certs/external-service.gitlab.com_root.crt

GitLabとSSLの仕組みの詳細

Linuxパッケージには独自のOpenSSLライブラリが含まれており、コンパイル済みのプログラム（Ruby、PostgreSQLなど）はすべてこのライブラリにリンクされています。このライブラリは、/opt/gitlab/embedded/ssl/certs内の証明書を参照するようにコンパイルされています。

Linuxパッケージは、openssl rehashツールを使用して、/etc/gitlab/trusted-certs/に追加された証明書を/opt/gitlab/embedded/ssl/certsにシンボリックリンクすることにより、カスタム証明書を管理します。たとえば、customcacert.pemを/etc/gitlab/trusted-certs/に追加するとします:

$ sudo ls -al /opt/gitlab/embedded/ssl/certs

total 272
drwxr-xr-x 2 root root   4096 Jul 12 04:19 .
drwxr-xr-x 4 root root   4096 Jul  6 04:00 ..
lrwxrwxrwx 1 root root     42 Jul 12 04:19 7f279c95.0 -> /etc/gitlab/trusted-certs/customcacert.pem
-rw-r--r-- 1 root root 263781 Jul  5 17:52 cacert.pem
-rw-r--r-- 1 root root    147 Feb  6 20:48 README

ここでは、証明書のフィンガープリントが7f279c95であり、それがカスタム証明書にリンクされていることがわかります。

HTTPSリクエストを行うと何が起こるのでしょうか。簡単なRubyプログラムを例にとります:

#!/opt/gitlab/embedded/bin/ruby
require 'openssl'
require 'net/http'

Net::HTTP.get(URI('https://www.google.com'))

舞台裏では次のような処理が行われます:

require 'openssl'行により、インタープリターは/opt/gitlab/embedded/lib/ruby/2.3.0/x86_64-linux/openssl.soを読み込みます。
次に、Net::HTTP呼び出しは、/opt/gitlab/embedded/ssl/certs/cacert.pem内のデフォルトの証明書バンドルを読み取ろうとします。
SSLネゴシエーションが行われます。
サーバーがSSL証明書を送信します。
送信された証明書がそのバンドルに含まれていれば、SSLは正常に完了します。
そうでない場合、OpenSSLは、事前定義された証明書ディレクトリ内でフィンガープリントに一致するファイルを探すことにより、他の証明書を検証することがあります。たとえば、証明書のフィンガープリントが7f279c95の場合、OpenSSLは/opt/gitlab/embedded/ssl/certs/7f279c95.0を読み取ろうとします。

OpenSSLライブラリは、SSL_CERT_FILEおよびSSL_CERT_DIR環境変数の定義をサポートしています。前者は読み込むデフォルトの証明書バンドルを定義し、後者は追加の証明書を検索するディレクトリを定義します。証明書をtrusted-certsディレクトリに追加している場合、これらの変数は不要です。ただし、何らかの理由でそれらをセットアップする必要がある場合は、環境変数として定義できます。例:

gitlab_rails['env'] = {"SSL_CERT_FILE" => "/usr/lib/ssl/private/customcacert.pem"}

トラブルシューティング

SSLのトラブルシューティングについては、ガイドを参照してください。

SSLをLinuxパッケージインストール用に設定する

OpenSSL 3へのアップグレード

Let’s Encryptインテグレーションを有効にする

証明書を自動的に更新する

証明書を手動で更新する

Let’s Encrypt以外のACMEサーバーを使用する

証明書に代替ドメインを追加する

HTTPSを手動で設定する

HTTPリクエストをHTTPSにリダイレクトする

デフォルトのHTTPSポートを変更する

デフォルトのSSL証明書の場所を変更する

SSL証明書を更新する

リバースプロキシまたはロードバランサーのSSL終端を設定する

カスタムSSL暗号スイートを使用する

HTTP/2プロトコルを設定する

双方向SSLクライアント認証を有効にする

HTTP Strict Transport Security（HSTS）を設定する

カスタム公開証明書をインストールする

カスタム証明書チェーンを使用する

GitLabとSSLの仕組みの詳細

トラブルシューティング

`HTTP`リクエストを`HTTPS`にリダイレクトする