CA-пакети во Cargo за проксито и серверот за пакети
Применете ги cainfo и proxy-cainfo на Cargo на правилната TLS-врска, наместо сите грешки во прокси-сертификати да ги сметате за ист проблем со довербата.
Со HTTPS-прокси и HTTPS-извор на пакети, Cargo може да проверува две TLS-врски со различни CA-пакети:
[http]
proxy = "https://proxy.example:8443"
proxy-cainfo = "/path/to/proxy-ca.pem"
cainfo = "/path/to/origin-ca.pem"Заменете ги крајната точка и патеките со одобрени вредности. Ова прокси намерно има TLS-слушател; обично HTTP-прокси не станува HTTPS затоа што изворот на пакети користи HTTPS.
| Фаза на грешката | Поставка за доверба што треба да се провери |
|---|---|
| TLS на проксито, пред да постои тунел до одредиштето | http.proxy-cainfo, што користи http.cainfo ако не е поставено одделно. |
| Сертификат на одредиштето по воспоставување на тунелот | http.cainfo за патеката на доверба до одредиштето. |
Соодветните променливи се CARGO_HTTP_PROXY_CAINFO и CARGO_HTTP_CAINFO. Користете го соодветниот одобрен орган за сертификација; копирањето случаен сертификат во двете датотеки не покажува која врска е погрешна.
Нешифрирано HTTP-прокси што пренесува CONNECT нема TLS-сертификат на прокси-слушателот за проверка. Грешка на одредиштето во тој случај не се поправа со измислена CA-датотека за прокси. Проверете и дали поставената патека постои во вистинскиот контејнер или CI-задача и земете го предвид однесувањето на оперативниот систем и TLS-заднината кога споредувате околини.
Оставете ја проверката вклучена. Таа ја обезбедува проверката на идентитет потребна за разликување на саканата услуга од пренос што само продолжува.