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 реализацията при сравняване на среди.
Оставете проверката включена. Тя предоставя проверката за идентичност, която различава желаната услуга от прехвърляне, което просто продължава.