מי שולח את תעודת הלקוח דרך פרוקסי?
הפרידו את פרטי ה-mTLS של היעד מפרטי הפרוקסי ומהתעודות ש-Apache משתמש בהן כשהוא יוצר בעצמו הפעלת TLS במעלה הזרם.
ב-HTTPS דרך CONNECT רגיל, היישום שולח את תעודת הלקוח של האתר במהלך לחיצת ה-TLS שלו עצמו עם היעד. הפרוקסי רק מעביר בתים; הוא אינו הופך אוטומטית ללקוח ה-TLS של האתר.
| פרט זיהוי | בעלים/חיבור |
|---|---|
| שם משתמש/סיסמת פרוקסי | גישת הלקוח לפרוקסי. |
| תעודת לקוח ומפתח פרטי של האתר | הפעלת ה-TLS של היישום עם היעד. |
| תעודת לקוח במעלה הזרם של שרת הפרוקסי | הפעלת TLS שהפרוקסי עצמו יוזם. |
תפקידים אלה יכולים להתקיים יחד. אין צורך להעלות את המפתח הפרטי של האתר לפרוקסי מנהרה פשוט כדי ש-mTLS ליעד יעבוד. לאחר מסירת CONNECT, השתמשו בהגדרת תעודת הלקוח הרגילה של היעד ביישום והמשיכו לאמת את תעודת שרת האתר.
SSLProxyMachineCertificateFile של Apache מספק פרטי זיהוי כאשר Apache יוצר בעצמו הפעלת TLS במעלה הזרם. עצה לגבי הקובץ הזה אינה מוכיחה שכל לקוח שמשתמש במנהרת העברה אטומה חייב להגדיר אותו.
יירוט TLS מסיים הפעלה אצל מתווך ומשנה את הבעלות הזו. קבעו אם זהות הלקוח הנדרשת יכולה לעבור דרך הסידור הזה, במקום להניח שהעתקת תעודה משמרת אימות מקצה לקצה.
בכשל, רשמו אם הבקשה נעצרה בכניסה לפרוקסי, ב-TLS של היעד או בהחלפת היישום המאוחרת. הציבו את פרט הזיהוי בחיבור שבאמת דורש אותו.