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־הינטערגרונט בײַם פֿאַרגלײַכן סבֿיבֿות.
האַלט די באַשטעטיקונג אײַנגעשאַלטן. זי גיט די אידענטיטעט־קאָנטראָל וואָס מע דאַרף כּדי צו אונטערשיידן די געצילטע דינסט פֿון אַן איבערפֿיר וואָס גייט בלויז ווײַטער.