作為最終用戶，如何讓我的共享Docker運行程式信任內部簽名的SSL證書？

我有一個專案，該專案具有通過 HTTP 從自托管 GitLab 服務器中提取的依賴項，例如：

{
  "name": "Project",
  "version": "1.0.0",
  "main": "index.js",
  "dependencies": {
    "some-dependency": "git http://user:[email protected]/group/project.git"
  }
}

GitLab 服務器的 SSL 證書由連接到公司 Active Directory 基礎設施的內部證書頒發機構簽名。在域計算機上，Chrome 和 Microsoft Edge 通過策略自動信任它。

Git 不會：

fatal: unable to access 'https://server.tld/group/project.git': server certificate verification failed.

在 Windows 上，我可以使用Schannel SSL 后端來制作由內部 CA 簽名的 Git 信任證書：

git config --global http.sslBackend schannel

由于schannelSSL 后端僅在 Windows 上可用，因此對于我在 GitLab CI 上的 Docker 運行器中運行的測驗來說，這不是一個選項。

如何在不完全禁用證書檢查的情況下在 GitLab CI 上安裝專案的依賴項？

編輯：我沒有對我正在使用的共享運行器的管理員訪問權限，因此我無法直接在它們上安裝受信任的 SSL 證書。

uj5u.com熱心網友回復：

從受信任的來源檢索證書的副本

驗證證書是否真實非常重要。由于 Chrome 已經通過策略信任證書，我們可以安全地從 Chrome 檢索證書：

1. 在 Chrome 中導航到 GitLab Web 界面
2. 點擊地址左側地址欄中的鎖
3. 單擊連接是安全的
4. 點擊證書有效
5. 在打開的新視窗中，轉到詳細資訊選項卡
6. 單擊復制到檔案...并將證書檔案保存在某處，例如在名為server-name.crt

server-cert.crt應該包含類似的東西

-----BEGIN CERTIFICATE-----
MIIJKoHjzstDxgmHL2j/LQ46PHAbnVYz/JlflAQl3AAjoy9VdtY1hkiG9otrEQmF
...
tMn95/0eWw3lqeduiv5ux982PpepGY3aozPyTzt/1P==
-----END CERTIFICATE-----

如果您更喜歡以其他方式檢索證書，例如通過opensslCLI 工具，請確保根據可靠來源檢查其指紋。您可以像這樣查看下載的證書的指紋：

openssl x509 -in server-cert.crt -noout -fingerprint

如果您需要另一種型別的指紋，您可以請求一個，例如通過添加一個引數，如-sha256.

使用容器中的證書

現在我們有了證書的副本，我們需要讓 Git 在 CI 作業期間意識到它。至少有兩種選擇。

選項 1：讓 Git 直接信任它。

Git對此有一個設定：

http.sslCAInfo

包含證書的檔案，用于在通過 HTTPS 獲取或推送時驗證對等方。可以被GIT_SSL_CAINFO環境變數覆寫。

將 CI 變數添加到專案中：

1. 在 Web 界面中導航到設定→ CI/CD并展開變數部分。
2. 單擊添加變數
3. 將變數的 Key 設定為GIT_SSL_CAINFO（Git 將查找的環境變數）
4. 將 的內容粘貼server-name.crt到值欄位中
5. 將其型別從變數更改為檔案

During jobs, GitLab CI will now create a temporary file, put the text of the certificate into that file, and set the GIT_SSL_CAINFO environment variable to the file's path. Git will pick it up automatically.

This has the benefit of (probably) not requiring any code changes. Your existing GitLab CI job should "just work". This means you should be able to set the variable at the group level in case you have multiple projects that are affected.

Option 2: Get the operating system in the container to trust it.

I'll show one way to do this with a Debian- or Ubuntu-based image. Alpine, Fedora, etc. images may require a few tweaks.

1. Create a file variable as shown in the first part of Option 1 above, but give it a different Key. I'll use TRUSTED_CERTS here.

2. Update your gitlab-ci.yml to pull the cert into the OS-level certificate store. One way to do that is shown here:

   default:
     before_script:
       # Add certificates contained in $TRUSTED_CERTS to OS-level certificate store
       - >
         [ -f "$TRUSTED_CERTS" ] &&
           ln -s "$TRUSTED_CERTS" /usr/local/share/ca-certificates/trusted.crt &&
           update-ca-certificates
       - yarn install  # Installing dependencies should work now
   

   If $TRUSTED_CERTS is set, this creates a symlink to that file in /usr/local/share/ca-certificates/ and then runs update-ca-certificates to update the OS-level certificate store.

This option should make most tools trust the certificate at the expense of some additional complexity in the CI job.

Since the gitlab-ci.yml file must be modified, it also can't be implemented at the group level as easily. A custom Docker base image that includes updated certificates could mitigate that.

標籤：混帐 GitLab ssl 证书 gitlab-ci

上一篇：如何修復10個最新git提交中的電子郵件？

下一篇：如何在Windows上將超過4GB的檔案推送到GitHub(LFS)？