סקירה כללית של Mutual TLS

פרוטוקול TLS בו-זמני (mTLS) הוא פרוטוקול מקובל בתחום לאימות בו-זמני בין לקוח לשרת. הוא מוודא שהלקוח והשרת מאמתים זה את זה על ידי בדיקה שלכל אחד מהם יש אישור תקף שהונפק על ידי רשות אישורים (CA) מהימנה. בניגוד ל-TLS רגיל, שבו רק השרת עובר אימות, ב-mTLS הלקוח והשרת צריכים להציג אישורים כדי לאשר את הזהויות של שני הצדדים לפני יצירת התקשורת.

‫mTLS מוגדר במשאב של שרת proxy של HTTPS ביעד של כל מאזני העומסים של האפליקציות:

• מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
• מאזן עומסים קלאסי של אפליקציות (ALB)
• מאזן עומסים חיצוני אזורי של אפליקציות (ALB)
• מאזן עומסים פנימי אזורי של אפליקציות (ALB)
• מאזן עומסים פנימי של אפליקציות (ALB) שפועל בכמה אזורים

ב-mTLS נעשה שימוש בתשתית של מפתח ציבורי (PKI) כדי לאמת את הזהות של הישויות שמתקשרות ברשת. התשתית כוללת שלושה רכיבים: לקוח, שרת ורשות אישורים (CA). פרוטוקול mTLS למאזני עומסים תומך בתכונות הבאות:

• לוודא שללקוח שמציג את האישור יש מפתח פרטי.

• אפשר לאמת את אישורי הלקוח באחד משני המצבים הבאים:

  • דחיית אישורים לא תקפים: מאפשרת אימות קפדני על ידי דחיית בקשות אם אי אפשר לאמת את שרשרת אישורי הלקוח.

  • ‫Allow invalid or missing certificates (התרת אישורים לא תקינים או חסרים): מאפשר גמישות על ידי העברת כל הבקשות אל ה-Backend, גם אם אישור הלקוח חסר או לא תקין.

• אימות של אישורי לקוח מול עוגן PKI שהועלה (אישור בסיס), עם אפשרות להוסיף כמה עוגנים בנפרד כדי לאפשר מעבר חלק מ-PKI ישן ל-PKI חדש ללא השבתה.

• צריך לספק אישורי ביניים נוספים כדי לעזור לבנות את נתיב האימות של אישור הלקוח מול עוגני PKI שצוינו (אישורי בסיס). אישורי הביניים האלה מאפשרים ל-mTLS לעבוד עם לקוחות שלא מספקים את שרשרת האישורים המלאה.

• יוצרים טביעת אצבע של האישור ומעבירים אותה לשרת העורפי ככותרת בקשה בהתאמה אישית.

• העברת השדות שנבחרו שחולצו מהאישור אל ה-backend באמצעות כותרות מותאמות אישית.

• מעבירים את תוצאת האימות ואת שגיאות האימות אל ה-backend באמצעות כותרות מותאמות אישית.

דרישות לאישורים

כשמגדירים אישורים ל-mTLS, צריך לוודא שהם עומדים בדרישות הבאות:

• האימות ב-mTLS מבוסס על כלים מודרניים של קריפטוגרפיה. האישורים חייבים להשתמש באלגוריתמים RSA או ECDSA לחילופי מפתחות. אלגוריתמים לגיבוב (hashing) צריכים להשתמש ב-SHA-256 או בפונקציית גיבוב קריפטוגרפית חזקה יותר. אלגוריתמים לגיבוב כמו MD4,‏ MD5 ו-SHA-1 לא נתמכים.
• עבור אישורי לקוח (עלה):
  • התוסף Basic Constraints לא יכול להכיל את CA=true.
  • התוסף Extended Key Usage חייב להכיל את clientAuth.
  • התוסף Extended Key Usage לא יכול לכלול את השדות codeSigning, timeStamping או OCSPSigning.
  • האישור צריך להיות בתוקף.
  • אישור הלקוח לא יכול להיות אישור עם חתימה עצמית.
• לאישורי בסיס ולאישורי ביניים:
  • תוסף Basic Constraints חייב להכיל את CA=true.
  • ההרחבה Key Usage חייבת להיות מוגדרת ל-keyCertSign.
  • התוסף Extended Key Usage צריך להכיל את השדה clientAuth.
  • האישור צריך להיות בתוקף.

ארכיטקטורה של פריסת mTLS

עם mTLS, אפשר להגדיר משאב של הגדרת אמון, שמכיל מאגר אמון. מאגר אישורים כולל עוגן אמון (אישור בסיס) וגם, באופן אופציונלי, אישור ביניים אחד או יותר. כשמאזן העומסים מקבל אישור לקוח, הוא מאמת אותו על ידי יצירת שרשרת אמינות מאישור הלקוח בחזרה לישות העוגן האמינה שהוגדרה.

בהמשך מופיע סקירה קצרה של המשאבים השונים שצריך להגדיר כדי להגדיר mTLS למאזן העומסים:

• הגדרת אמון. מכיל משאב יחיד של מאגר אישורים, שבתורו מכיל ישות עוגן אמינה (אישור בסיס) ואופציונלית, אישור ביניים אחד או יותר. הגדרת האמון משמשת ליצירת שרשרת אמון בין אישור הלקוח לבין נקודת האמון. מידע נוסף זמין במאמר הגדרות אמון.

  אופציונלית, אם אתם צריכים להשתמש באישור עם חתימה עצמית, באישור שפג תוקפו או באישור לא תקין, או אם אין לכם גישה לאישורים הבסיסיים ולאישורי הביניים, אתם יכולים להוסיף את האישור הזה להגדרת האמון בשדה allowlistedCertificates. לא צריך מאגר אישורים כדי להוסיף אישור לרשימת ההיתרים.

  הוספת אישור לרשימת ההיתרים פירושה שהאישור תמיד ייחשב כתקף כל עוד אפשר לנתח אותו, יש הוכחה לבעלות על המפתח הפרטי והאילוצים בשדה SAN של האישור מתקיימים.

• מאגר אישורים. מכיל את נקודת העוגן של המהימנות ואת אישורי הביניים של רשות האישורים (CA) שמשמשים ליצירת שרשרת מהימנות ולאימות אישור הלקוח. רשות אישורים (CA) משמשת להנפקת אישורים מהימנים ללקוח. רשות האישורים מזוהה על ידי ישות עוגן אמינה של מאזן העומסים (אישור בסיס) או על ידי אישורי הביניים של רשות האישורים.

  אפשר להעלות את סוגי האישורים הבאים של שורש וביניים אל מאגר האישורים:

  • אישורים שהונפקו על ידי רשויות אישורים של צד שלישי לפי בחירתכם.
  • אישורים שהונפקו על ידי רשויות אישורים פרטיות שבשליטתכם, כפי שמתואר במאמר הגדרת Mutual TLS (mTLS) עם רשות אישורים פרטית.
  • אישורים שסופקו על ידי משתמשים, כפי שמתואר במאמר הגדרת TLS הדדי עם אישורים שסופקו על ידי משתמשים.

• אימות לקוח (נקרא גם ServerTLSPolicy). המדיניות הזו מציינת את מצב האימות של הלקוח ואת משאב הגדרות האמון שבו יש להשתמש בעת אימות אישורי לקוח. כשלקוח מציג מאזן עומסים עם אישור לא תקין או ללא אישור, מצב אימות הלקוח מציין איך לטפל בחיבור של הלקוח. אפשר לציין את כל הפרמטרים שקשורים לאימות mTLS במדיניות TLS של השרת. משאב אימות הלקוח (ServerTLSPolicy) מצורף למשאב פרוקסי היעד של HTTPS.

בתרשימים הבאים מוצגים הרכיבים השונים של mTLS שמצורפים למשאב היעד של פרוקסי HTTPS של איזון עומסים גלובליים ואזוריים של אפליקציות.

גלובלי

הדיאגרמה הבאה מציגה את הרכיבים של פריסת מאזן עומסים חיצוני של אפליקציות. הארכיטקטורה הזו חלה גם על מאזן עומסים פנימי של אפליקציות (ALB) בין אזורים, שהוא מאזן עומסים פנימי של אפליקציות שמשתמש ברכיבים גלובליים.

Mutual TLS עם רכיבים של מאזן עומסים גלובלי חיצוני לאפליקציות (לוחצים כדי להגדיל).

אזורי

בתרשים הבא מוצגים הרכיבים של פריסה של מאזן עומסים פנימי אזורי של אפליקציות (ALB). הארכיטקטורה הזו חלה גם על מאזן עומסים חיצוני אזורי של אפליקציות (ALB), שהוא מאזן עומסים חיצוני של אפליקציות שמשתמש ברכיבים אזוריים.

‫

TLS דו-כיווני עם רכיבים אזוריים פנימיים של מאזן עומסים של אפליקציות (לחצו כדי להגדיל).

מצב אימות לקוח

כשלקוח מציג אישור לא תקין או לא מציג אישור למאזן העומסים, מאפיין clientValidationMode במשאב Client Authentication ‏(ServerTLSPolicy) מציין איך מאזן העומסים מטפל בחיבור של הלקוח.

הערכים של מצב האימות בצד הלקוח הם:

• ‫ALLOW_INVALID_OR_MISSING_CLIENT_CERT. מאפשרת את החיבור מהלקוח גם אם האימות של אישור הלקוח נכשל או אם לא הוצג אישור לקוח. במצב הזה, מאזן העומסים מאפשר את החיבור מהלקוח ומעביר את כל הבקשות אל ה-Backend, בלי קשר לשאלה אם אפשר ליצור שרשרת אמון.

  ההוכחה לבעלות על המפתח הפרטי נבדקת תמיד כשמוצג אישור הלקוח. אם הלקוח לא יכול להוכיח שהוא מחזיק במפתח הפרטי, לחיצת היד בפרוטוקול TLS מסתיימת גם אם מצב האימות של הלקוח מאפשר אישור לקוח לא תקין או חסר.

• REJECT_INVALID. דוחה את החיבור אם הלקוח לא מספק אישור או אם אימות האישור נכשל. במצב הזה, מאזן העומסים מסיים את החיבור מהלקוח אם הוא לא מצליח ליצור שרשרת אמון מהאישור של הלקוח בחזרה לישות עוגן האמון.

הגדרת mTLS במאזן העומסים

מוצגת כאן סקירה כללית של השלבים העיקריים שצריך לבצע כדי להגדיר mTLS במאזן העומסים:

1. יוצרים משאב של הגדרת אמון שכולל את עוגן האמון (אישור הבסיס) ואת אישורי הביניים שמשמשים כ-Root of Trust.

2. מקשרים את הגדרת האמון למשאב Client Authentication (ServerTLSPolicy), שמגדיר את מצב האימות של הלקוח כ-ALLOW_INVALID_OR_MISSING_CLIENT_CERT או כ-REJECT_INVALID.

3. מצרפים את משאב אימות הלקוח (ServerTLSPolicy) למשאב ה-Proxy ל-HTTPS של מאזן העומסים.

4. אופציונלי: אתם יכולים להשתמש בכותרות mTLS מותאמות אישית כדי להעביר מידע על חיבור ה-mTLS לשירות לקצה העורפי או למפת URL.

במדריכים הבאים אפשר למצוא מידע נוסף על ההגדרה הזו:

• הגדרה של TLS הדדי עם אישורים שסופקו על ידי משתמשים
• הגדרה של Mutual TLS (mTLS) עם רשות אישורים פרטית

שלבים לאימות אישור לקוח

כשמאמתים את אישור הלקוח, מאזן העומסים מבצע את הפעולות הבאות:

1. מוודאים שללקוח יש את המפתח הפרטי.

   הלקוח מוכיח שהוא מחזיק במפתח הפרטי שמשויך למפתח הציבורי באישור על ידי יצירת חתימה במהלך תהליך לחיצת היד. מאזן העומסים מאמת את החתימה הזו באמצעות המפתח הציבורי של הלקוח. אם אימות החתימה נכשל, זה אומר שהלקוח לא הבעלים של האישור. במקרה כזה, לחיצת היד של TLS מסתיימת גם אם ההגדרה שלכם מאפשרת אישור לקוח לא תקין או חסר. לא מתבצע רישום ביומן של שגיאות במאזני עומסים גלובליים חיצוניים של אפליקציות, אבל שגיאת TLS נרשמת ביומן בשדה proxyStatus במאזני עומסים אזוריים חיצוניים של אפליקציות ובמאזני עומסים פנימיים של אפליקציות.

2. אימות שרשרת האמון.

   מאזן העומסים מאמת את שרשרת האמון בין אישור הלקוח לבין הגדרת האמון שהוגדרה. בדיקות האימות כוללות את הדברים הבאים:

   • האישורים של הלקוח, הביניים והבסיס עומדים בדרישות האישורים.
   • השדה 'נושא' באישור ההורה תואם לשדה 'הרשות המנפיקה' באישור הצאצא. האימות הזה מבטיח שהזהות (הנושא) של אישור האב זהה לזהות שמופיעה כמנפיק באישור הבן.
   • מזהה המפתח של הנושא (SKID) של אישור האב תואם למזהה המפתח של הרשות (AKID) באישור הצאצא. ההתאמה הזו מאשרת שאישור הצאצא הונפק על ידי רשות הבסיס הנכונה, ושאפשר לסמוך עליו כי המפתח הציבורי של הבסיס מוזכר ב-AKID לצורך אימות התוקף של האישור.
   • השם החלופי של בעלים (subject) (SAN) באישור צאצא לא מפר את השדה NameConstraints באישור ההורה.
   הערה: אישורי לקוח בחתימה עצמית לא יוצרים שרשרת אמון תקינה ותמיד נדחים.

3. העברת הבקשה אל השרת העורפי.

   אם אימות אישור הלקוח מצליח, הבקשה מועברת אל ה-Backend באמצעות כותרות mTLS מותאמות אישית.

   עם זאת, אם האימות נכשל, הפעולה שתתבצע תלויה בערך של מצב האימות של הלקוח:

   • ‫ALLOW_INVALID_OR_MISSING_CLIENT_CERT: הבקשה מועברת עם כותרות mTLS מותאמות אישית שמציינות את הסיבה לכישלון האימות. במאזני עומסים פנימיים של אפליקציות חוצי-אזורים, במאזני עומסים חיצוניים אזוריים של אפליקציות ובמאזני עומסים פנימיים אזוריים של אפליקציות, בנוסף לכותרות mTLS מותאמות אישית, אפשר להגדיר שדות אופציונליים של mTLS כדי לבדוק את הסיבה לכשל.

   • ‫REJECT_INVALID: החיבור מסתיים והשגיאות נרשמות ב-Cloud Logging.

כותרות mTLS מותאמות אישית שמועברות לשרת העורפי

בטבלה הבאה מפורטים משתני הכותרת המותאמים אישית של mTLS שאפשר להעביר אל ה-Backend, גם כשהאימות של אישור הלקוח עובר בהצלחה וגם כשהוא נכשל. אם אימות אישור הלקוח נכשל, הבקשות מועברות אל ה-Backend רק אם מצב אימות הלקוח מוגדר ל-ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

אפשר להגדיר את המשתנים האלה גם במפת URL.

סטטוס אישור הלקוח	מצב אימות לקוח	כותרות מותאמות אישית
שרשרת אישורי הלקוח ארוכה מדי (יותר מ-10 אישורי ביניים כלולים באישור הלקוח).	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_chain_exceeded_limit client_cert_sha256_fingerprint: <cert hash>
גודל מפתח ה-RSA של לקוח או של אישור ביניים לא תקין. לא מתבצע אימות. מפתחות RSA יכולים להיות באורך של 2048 עד 4096 ביט.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_invalid_rsa_key_size client_cert_sha256_fingerprint: <cert hash>
לקוח או אישור ביניים משתמשים בעקומה אליפטית שלא נתמכת. לא מתבצע אימות. העקומות האליפטיות התקפות הן P-256 ו-P-384.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_unsupported_elliptic_curve_key client_cert_sha256_fingerprint: <cert hash>
לקוח או אישור ביניים משתמשים באלגוריתם שאינו RSA או ECDSA. לא מתבצע אימות.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_unsupported_key_algorithm client_cert_sha256_fingerprint: <cert hash>
תשתית ה-PKI שתשמש לאימות כוללת יותר מעשרה אישורים ביניים עם אותו נושא ופרטי מפתח ציבורי של הנושא. לא מתבצע אימות.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_pki_too_large client_cert_sha256_fingerprint: <cert hash>
באישור ביניים שסופק לצורך אימות היו יותר מ-10 מגבלות שם.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_chain_max_name_constraints_exceeded client_cert_sha256_fingerprint: <cert hash>
לאישור הלקוח אין תוסף Extended Key Usage (EKU) שכולל את clientAuth.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_chain_invalid_eku client_cert_sha256_fingerprint: <cert hash>
הזמן הקצוב פג במהלך הניסיון לאמת את שרשרת האישורים.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_timed_out client_cert_sha256_fingerprint: <cert hash>
הגעתם למגבלת העומק או האיטרציה במהלך הניסיון לאמת את שרשרת האישורים. העומק המקסימלי של שרשרת אישורים הוא עשרה, כולל אישורי הבסיס והלקוח. מספר האיטרציות המקסימלי הוא 100 (האישורים שנבדקו כדי לאמת את שרשרת אישורי הלקוח).	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_search_limit_exceeded client_cert_sha256_fingerprint: <cert hash>
הגדרתם mTLS בלי להגדיר משאב TrustConfig. לא ניתן לבצע אימות, אבל הגיבוב של האישור מועבר אל ה-backend.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_not_performed client_cert_sha256_fingerprint: <cert hash>
אין אישור לקוח.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: false client_cert_chain_verified: false client_cert_error: client_cert_not_provided client_cert_sha256_fingerprint: <empty>
האימות של אישור הלקוח נכשל מול המשאב TrustConfig.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_failed client_cert_sha256_fingerprint: <cert hash>
אישור הלקוח עובר את האימות של כלי האימות.	לא רלוונטי	client_cert_present: true client_cert_chain_verified: true client_cert_error: <empty> client_cert_sha256_fingerprint: <cert hash> client_cert_serial_number: <serial_number> client_cert_valid_not_before: <date> client_cert_valid_not_after: <date> client_cert_uri_sans: <list> client_cert_dnsname_sans: <list> client_cert_issuer_dn: <issuer> client_cert_subject_dn: <subject> client_cert_leaf: <certificate> client_cert_chain: <list>

ניתוח של ערכי משתנים של כותרות מותאמות אישית שמועברים אל ה-backend

חלק מהערכי המשתנים של כותרות mTLS מותאמות אישית הם ייצוגים של מחרוזות בקידוד Base64 של נתוני אישורים בינאריים של כללי קידוד מובחנים (DER). אפשר לפענח מחרוזות בקידוד Base64 באמצעות כלים או ספריות תוכנה לפי בחירתכם. הנה כמה דוגמאות:

• במערכות macOS ו-Linux אפשר להשתמש בכלי שורת הפקודה base64, שהוא כלי ליבה שכלול בשתי מערכות ההפעלה. כדי לפענח מחרוזות בקידוד Base64 באמצעות כלי השירות base64, מעבירים את המחרוזת המקודדת כקלט סטנדרטי (stdin) לפקודה base64 ומשתמשים בדגל -d כדי לפענח את המחרוזת באופן הבא:

  echo BASE_64_ENCODED_STRING | base64 -d
  

• ‫Python כולל את מודול base64, שאפשר להשתמש בו כדי לפענח מחרוזות בקידוד Base64 באופן הבא:

  import base64
  encoded_string=BASE_64_ENCODED_STRING
  decoded_string=base64.b64decode(encoded_string).decode()
  print(decoded_string) # Note that a newline character (\n) is added to the end of the string.
  

טיפול בשגיאות ורישום ביומן

מאזני עומסים של אפליקציות מספקים יכולות מפורטות של רישום ביומן, שמאפשרות לכם לעקוב אחרי אימות של אישורי לקוח, לזהות בעיות פוטנציאליות ולפתור בעיות בחיבור. בקטע הזה מפורטים סוגי השגיאות שיכולות להתרחש במהלך אימות mTLS, ומוסבר איך השגיאות מתועדות.

שגיאות שנרשמו ביומן במצב REJECT_INVALID

אם אימות אישור הלקוח נכשל, ומצב אימות הלקוח מוגדר ל-REJECT_INVALID, החיבור מסתיים והשגיאות נרשמות ב-Cloud Logging. השגיאות האלה מתוארות בטבלה הבאה.

סטטוס אישור הלקוח	שגיאה שנרשמה ביומן
שרשרת אישורי הלקוח ארוכה מדי (יותר מ-10 אישורי ביניים כלולים באישור הלקוח).	client_cert_chain_exceeded_limit
ללקוח או לאישור ביניים יש מפתח RSA לא חוקי בגודל מסוים. לא מתבצע אימות. מפתחות RSA יכולים להיות באורך של 2048 עד 4096 ביט.	client_cert_invalid_rsa_key_size
לקוח או אישור ביניים משתמשים בעקומה אליפטית שלא נתמכת. לא מתבצע אימות. העקומות התקפות הן P-256 ו-P-384.	client_cert_unsupported_elliptic_curve_key
לקוח או אישור ביניים משתמשים באלגוריתם שאינו RSA או ECDSA. לא מתבצע אימות.	client_cert_unsupported_key_algorithm
תשתית ה-PKI שתשמש לאימות כוללת יותר מעשרה אישורים ביניים עם אותו נושא ופרטי מפתח ציבורי של הנושא. לא מתבצע אימות.	client_cert_pki_too_large
באישור ביניים שסופק לצורך אימות היו יותר מ-10 מגבלות שם.	client_cert_chain_max_name_constraints_exceeded
באישור הלקוח אין תוסף Extended Key Usage (EKU) שכולל את clientAuth.	client_cert_chain_invalid_eku
הזמן הקצוב פג במהלך הניסיון לאמת את שרשרת האישורים.	client_cert_validation_timed_out
הגעתם למגבלת העומק או האיטרציה במהלך הניסיון לאמת את שרשרת האישורים. העומק המקסימלי של שרשרת אישורים הוא עשרה, כולל אישורי הבסיס והלקוח. מספר האיטרציות המקסימלי הוא 100 (האישורים שנבדקים כדי לאמת את שרשרת אישורי הלקוח).	client_cert_validation_search_limit_exceeded
הגדרתם mTLS בלי להגדיר משאב TrustConfig.	client_cert_validation_not_performed
הלקוח לא סיפק את האישור המבוקש במהלך הלחיצת יד.	client_cert_not_provided
האימות של אישור הלקוח נכשל עם המשאב TrustConfig.	client_cert_validation_failed

שגיאות שנרשמו ביומן לחיבורים סגורים

כשמצב האימות של הלקוח מוגדר ל-ALLOW_INVALID_OR_MISSING_CLIENT_CERT או ל-REJECT_INVALID, שגיאות מסוימות גורמות לסגירת החיבורים ולרישום שלהן ב-Cloud Logging. השגיאות האלה מתוארות בטבלה הבאה.

סטטוס אישור הלקוח	בקשה	שגיאה שנרשמה ביומן
אישור הלקוח לא תואם לחתימה במהלך לחיצת היד.	הפסקת לחיצת היד של SSL	ללא
השירות לא יכול לבצע אימות של שרשרת האישורים.	סיום החיבור	client_cert_validation_unavailable
שגיאה פנימית באימות שרשרת האישורים.	סיום החיבור	client_cert_validation_internal_error
לא נמצאה התאמה ל-TrustConfig.	סיום החיבור	client_cert_trust_config_not_found
המטען הייעודי (payload) של אישור הלקוח (כולל אישורי ביניים) גדול מדי (יותר מ-16KB).	סיום החיבור	client_cert_exceeded_size_limit

אם הרישום ביומן מופעל בשירות לקצה העורפי, אפשר לראות שגיאות שנרשמו ביומן לגבי חיבורים סגורים במהלך אימות אישור לקוח mTLS.

מגבלות

• מאזן העומסים לא מבצע בדיקות ביטול של אישורי לקוח.

• מאזני עומסים של אפליקציות מאפשרים להעלות הגדרת אמון עם חנות אמון אחת, שמכילה לכל היותר: 200 של מספר משולב של עוגני אמון ואישורי ביניים (מספר אישורי הביניים מוגבל ל-100) ו-500 אישורים שנוספו לרשימת ההיתרים. בכל האישורים הביניים לא יכולים להיות יותר משלושה אישורים עם אותו נושא ומידע על מפתח ציבורי של הנושא. למידע נוסף, אפשר לעיין במאמר מכסות ומגבלות.

• העומק המקסימלי של שרשרת אישורים הוא עשרה, כולל אישורי הבסיס והלקוח. המספר המקסימלי של פעמים שאפשר להעריך אישורים ביניים כשמנסים לבנות את שרשרת האמון הוא 100. מידע נוסף זמין במאמר מכסות ומגבלות.

• המפתחות של האישורים שהועלו ועברו מהלקוח מוגבלים ל:

  • מפתחות RSA יכולים להיות באורך של 2048 עד 4096 ביט. מידע נוסף זמין במאמר מכסות ומגבלות.
  • מפתחות ECDSA יכולים להשתמש בעקומות P-256 או P-384.

• שרשרת האישורים הקבילה שמתקבלת מהלקוח מוגבלת ל-16KB ול-10 אישורים. מידע נוסף זמין במאמר מכסות ומגבלות.

• אישורים בסיסיים שמשמשים לאימות לא יכולים להכיל יותר מ-10 מגבלות שם. מידע נוסף זמין במאמר מכסות ומגבלות.

• ממשקי הקצה של Google‏ (GFE) בשכבה 1 אוכפים זמן קצוב לתפוגה של 10 שניות, שלא ניתן להגדרה, כדי שהלקוח יציג את האישור שלו במהלך לחיצת היד בפרוטוקול TLS. בזמן עומס שיא, יכול להיות שזמן ההמתנה הזה יהיה קצר יותר. הלקוחות צריכים להציג את האישור בפרק הזמן הזה כדי ליצור חיבור mTLS בהצלחה.

המאמרים הבאים

• הגדרה של TLS הדדי עם אישורים שסופקו על ידי משתמשים

• הגדרה של TLS הדדי עם רשות אישורים פרטית

• משתנים שיכולים להופיע בערך של הכותרת