סקירה כללית של TLS מאומת בשרת העורפי ו-mTLS בשרת העורפי

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

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

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

mTLS בקצה הקדמי ובבק-אנד (לחצו כדי להגדיל).

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

במסמך הזה מפורטת סקירה כללית על TLS מאומת בשרת העורפי ועל mTLS בשרת העורפי. מידע נוסף על mTLS בקצה הקדמי זמין במאמר סקירה כללית של Mutual TLS (mTLS).

אפשר להגדיר TLS מאומת לקצה העורפי ו-mTLS לקצה העורפי במשאב שירות הקצה העורפי של מאזני העומסים הבאים:

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

תכונות

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

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

• מאזן העומסים יכול לאמת אישורי TLS של שרתי קצה מול שורשי מהימנות ציבוריים (web PKI).

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

• אתם יכולים להגדיר שם מארח של TLS Server Name Indication ‏ (SNI) לשירות הקצה העורפי. במהלך לחיצת היד של TLS, מאזן העומסים כולל את שם המארח של SNI בהודעה ClientHello שהוא שולח לקצה העורפי. הקצה העורפי מגיב עם אישור ה-TLS שלו, ומאזן העומסים מוודא שלפחות אחד משדות Subject Alternative Name‏ (SAN) באישור הזה תואם לשם המארח או לאחד משדות ה-SAN שהוגדרו לשירות הקצה העורפי.

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

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

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

• כלים מודרניים לקריפטוגרפיה מהווים את הבסיס לאימות mTLS. האישורים חייבים להשתמש באלגוריתמים RSA או ECDSA לחילופי מפתחות. אלגוריתמים לגיבוב (hashing) צריכים להשתמש ב-SHA-256 או בפונקציית גיבוב (hash) קריפטוגרפית חזקה יותר. אין תמיכה באלגוריתמים לגיבוב כמו MD4,‏ MD5 ו-SHA-1.

• אישורי שרת עלים שמסופקים על ידי ה-Backend צריכים לעמוד בדרישות הבאות:

  • התוסף basic constraints must not contain CA=true.
  • התוסף extended key usage חייב להכיל את serverAuth.
  • התוסף extended key usage אסור שיכיל את השדות codeSigning, timeStamping או OCSPSigning.
  • אסור שתוקף האישור יפוג.

• עבור אישורי לקוח (מאזן עומסים) מסוג עלה שמשמשים ב-mTLS של קצה העורף, האישור צריך להיות משאב של Certificate Manager. ההיקף של האישור הזה צריך להיות client-auth, שמציין שהאישור הזה משמש כאישור לקוח ב-mTLS של השרת העורפי.

  • התוסף basic constraints must not contain CA=true.
  • התוסף extended key usage חייב להכיל את clientAuth.
  • התוסף extended key usage אסור שיכיל את השדות codeSigning, timeStamping או OCSPSigning.
  • אסור שתוקף האישור יפוג.

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

  • תוסף basic constraints חייב להכיל את CA=true.
  • תוסף השימוש במפתח חייב להיות מוגדר ל-keyCertSign.
  • תוסף השימוש המורחב במפתח חייב להכיל את השדה serverAuth.
  • אסור שתוקף האישור יפוג.

רכיבים מרכזיים של TLS מאומת בבקאנד ו-mTLS בבקאנד

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

כדי להגדיר TLS מאומת בשרת העורפי, צריך לבצע את הפעולות הבאות:

• יוצרים משאב של הגדרת אמון.
• יוצרים משאב של הגדרות אימות לקצה העורפי.
• מעדכנים את מאפיין הגדרת ה-TLS בשירות לקצה העורפי ומפנים אותו למשאב ההגדרות של אימות העורף.

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

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

רכיבי TLS מאומתים בבק-אנד ו-mTLS בבק-אנד (לחצו להגדלה).

בהמשך מופיעה סקירה כללית של הרכיבים השונים האלה שמשמשים להגדרת TLS מאומת בקצה העורפי ו-mTLS בקצה העורפי.

הגדרת אמון

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

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

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

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

מאגר האישורים לא מכיל מפתחות פרטיים, כי רק האישורים נדרשים כדי לאמת שרשרת של אמון.

משאב להגדרת אימות בקצה העורפי

הגדרת האימות של הקצה העורפי (משאב BackendAuthenticationConfig) מצורפת לשירות הקצה העורפי של מאזן העומסים ומבצעת את הפונקציות הבאות:

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

כדי להפעיל TLS מאומת בבקשות לשרת העורפי ו-mTLS בבקשות לשרת העורפי, משאב התצורה של אימות השרת העורפי מצביע על המשאבים הבאים:

• הגדרת אמון (trustConfig): הגדרת האמון המצורפת שמשמשת לאימות אישור השרת שמסופק על ידי ה-Backend. אין צורך בהגדרת אמון אם הגדרת האימות של ה-Backend משתמשת בשורשי האמון הציבוריים כדי לאמת את אישור השרת.

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

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

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

שירות לקצה העורפי

בשירות לקצה העורפי, המאפיין tlsSettings מצביע על המשאבים הבאים כדי לאמת את האישור לקצה העורפי.

• הגדרת אימות קצה עורפי (authenticationConfig)
• שם המארח ב-SNI (sni)
• שמות SAN שהתקבלו (subjectAltNames)

הערה: הגדרה של שם המארח של SNI ושל שמות נושא חלופיים (SAN) שאושרו בשירות לקצה העורפי כדי לאמת את האישור העורפי היא אופציונלית. עם זאת, אי אפשר לאמת את האישור של הקצה העורפי בלי להגדיר את משאב התצורה של אימות הקצה העורפי בשירות הקצה העורפי. במילים אחרות, צריך לאמת את אישור הבק-אנד באמצעות שרשרת אישורים מהימנה, שמוגדרת באמצעות הגדרת מהימנות.

השדות SNI ‏ (sni) ו-SAN ‏ (subjectAltNames) במאפיין tlsSettings קובעים איך מאזן העומסים מאמת את האישור של ה-Backend על סמך ערכי ה-SAN של האישור. השדות האלה משפיעים על תהליך האימות, בלי קשר לשאלה אם מוגדר TLS מאומת בשרת העורפי.

כשהשדה SNI מוגדר (tlsSettings.sni), מאזן העומסים מבצע את הפעולות הבאות:

• שולח את שם המארח של SNI לשרת העורפי במהלך לחיצת היד של TLS.
• בודק שאישור ה-TLS של ה-Backend כולל SAN שתואם לשם המארח של SNI.

כברירת מחדל, מאזן העומסים בודק שאישור ה-TLS של ה-Backend כולל SAN שתואם לשם המארח של SNI. עם זאת, אם כתובות ה-SAN מוגדרות בשירות לקצה העורפי (tlsSettings.subjectAltNames), מאזן העומסים מבצע את הפעולות הבאות:

• מערכת מתעלמת משם המארח של SNI לצורך אימות SAN.
• בודק שאישור ה-TLS של ה-Backend כולל SAN שתואם לאחד מה-SAN המקובלים (subjectAltNames) שהוגדרו בשירות ה-Backend.

אישור לקוח

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

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

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

אין תמיכה באישורים מנוהלים של PKI ציבורי, וכל אישורי הלקוח צריכים להיות עם היקף client-auth ולעמוד בדרישות האישורים.

אם ה-backend מבקש אישור לקוח, צריך להגדיר אותו כך שיקבל את אישור הלקוח. אם הבק-אנד דוחה את החיבור למאזן העומסים, מאזן העומסים מחזיר קוד סטטוס 502 של HTTP לבקשות שהוא מעביר דרך ה-proxy, ומתעד סטטוס כללי ב-Cloud Logging.

הגדרת TLS מאומת בקצה העורפי ו-mTLS בקצה העורפי במאזן העומסים

אפשר להגדיר TLS מאומת בשרת העורפי ו-mTLS בשרת העורפי במאזן העומסים באמצעות PKI פרטי או שורשי אמון ציבוריים.

שימוש ב-PKI פרטי

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

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

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

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

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

שימו לב לנקודות הבאות:

• אי אפשר לשלוח אישור לקוח לבק-אנד בלי להגדיר קודם TLS מאומת לבק-אנד.

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

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

• הגדרת TLS מאומת בשרת העורפי

• הגדרה של mTLS בקצה העורפי

שימוש ב-roots of trust ציבוריים

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

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

ההגדרה PUBLIC_ROOTS משתמשת בקבוצה של רשויות אישורי בסיס, בדומה לקבוצה של רשויות אישורי בסיס שמהימנות על דפדפנים, שמנוהלת על ידי Google ויכולה להשתנות לאורך זמן. השינוי הזה עלול לגרום לכך שהאישורים של ה-backend יהפכו ללא תקפים. אם אתם צריכים לאמת אישורים שהונפקו באופן ציבורי, כדאי לבחור רשות אישורים (CA) מוכרת ומהימנה, שמשתמשת בחתימה צולבת ביניים כדי להנפיק את אישורי ה-Backend שלכם. כך תוכלו לצמצם את הסיכון שאישור בסיס יפוג או יבוטל.

שימוש בזהויות מנוהלות של עומסי עבודה

אפשר להשתמש ב-mTLS באמצעות זהויות מנוהלות של עומסי עבודה.

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

• הגדרת אמון ב-Certificate Manager
• אישור זהות מנוהל של Certificate Manager
• הגדרות אימות בקצה העורפי

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

שלבים באימות אישור השרת

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

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

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

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

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

   בדיקות האימות כוללות את הפעולות הבאות:

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

3. יצירת חיבור עם ה-Backend.

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

   עם זאת, אם אימות האישור נכשל, מאזן העומסים מסיים את החיבור לבק-אנד, שולח קוד סטטוס HTTP 502 ללקוח ומתעד את סיבת הסיום ב-Cloud Logging. במקרה של שגיאה באימות האישור, בקשות נכנסות שמתקבלות לאחר מכן גורמות למאזן העומסים להפעיל מחדש את החיבור לעורף השרת.

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

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

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

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

הסטטוס של אישור השרת	שגיאה שנרשמה ביומן
שרשרת אישורי השרת ארוכה מדי (יותר מ-10 אישורי ביניים כלולים באישור השרת).	server_cert_chain_exceeded_limit
לשרת או לאישור ביניים יש מפתח RSA לא תקין בגודל מסוים. לא מתבצע אימות. מפתחות RSA יכולים להיות באורך של 2048 עד 4096 ביט.	server_cert_invalid_rsa_key_size
שרת או אישור ביניים משתמשים בעקומה אליפטית שלא נתמכת. לא מתבצע אימות. העקומות התקפות הן P-256 ו-P-384.	server_cert_unsupported_elliptic_curve_key
שרת או אישור ביניים משתמשים באלגוריתם שאינו RSA או ECDSA. לא מתבצע אימות.	server_cert_unsupported_key_algorithm
תשתית ה-PKI שתשמש לאימות מכילה יותר מעשרה אישורים ביניים שמשותפים להם אותו נושא ופרטי מפתח ציבורי של הנושא. לא מתבצע אימות.	server_cert_pki_too_large
באישור ביניים שסופק לצורך אימות היו יותר מ-10 מגבלות שם.	server_cert_chain_max_name_constraints_exceeded
לאישור השרת יש שדה תוסף Extended Key Usage (EKU), אבל השדה הזה לא כולל את serverAuth.	server_cert_chain_invalid_eku
הזמן הקצוב פג במהלך הניסיון לאמת את שרשרת האישורים.	server_cert_validation_timed_out
הגעתם למגבלת העומק או האיטרציה בזמן הניסיון לאמת את שרשרת האישורים. העומק המקסימלי של שרשרת אישורים הוא עשרה, כולל אישורי הבסיס והשרת. מספר האיטרציות המקסימלי הוא 100 (האישורים שנבדקו כדי לאמת את שרשרת אישורי השרת).	server_cert_validation_search_limit_exceeded
הגדרתם mTLS בלי להגדיר משאב TrustConfig.	server_cert_validation_not_performed
השרת לא סיפק את האישור המבוקש במהלך הלחיצת יד.	server_cert_not_provided
אימות אישור השרת נכשל עם המשאב TrustConfig.	ssl_certificate_verification_failed
השירות לא יכול לבצע אימות של שרשרת האישורים.	server_cert_validation_unavailable
שגיאה פנימית באימות שרשרת האישורים.	server_cert_validation_internal_error
לא נמצא TrustConfig תואם.	server_cert_trust_config_not_found
המטען הייעודי (payload) של אישור השרת (כולל אישורי ביניים) גדול מדי (יותר מ-16KB).	server_cert_exceeded_size_limit

מגבלות

• ‫TLS מאומת בשרת העורפי ו-mTLS בשרת העורפי לא נתמכים במאזני עומסים קלאסיים של אפליקציות.

• אין תמיכה ב-TLS מאומת וב-mTLS מאומת בשרת העורפי לסוגי השרתים העורפיים הבאים:

  • קצוות עורפיים של קבוצת נקודות קצה ברשת האינטרנט (NEG) גלובלית

  • עורפי קצה של App Engine

• בדיקות תקינות לא תומכות באימות TLS או ביכולות mTLS. הכלי לבדיקת תקינות לא יכול להציג אישורי לקוח, והוא גם לא מאמת אישורי שרת מול הגדרות מהימנות. אם השרתים העורפיים שלכם דורשים אישורי לקוח לתעבורת HTTPS, ודאו שניתן להפעיל בדיקות תקינות ללא mTLS. למשל, באמצעות בדיקות תקינות של TCP, או על ידי הגדרת נקודת קצה או יציאה ייעודית לבדיקות תקינות שלא דורשת אימות לקוח.

• מאזן העומסים לא מעביר את שם המארח SNI של הלקוח מחיבור ה-TLS של קצה ה-frontend כשמתחברים לקצה ה-backend. עם זאת, לשרתי קצה עורפיים יש גישה לשם המארח של SNI של הלקוח באמצעות כותרת בקשה בהתאמה אישית.

• ב-mTLS של ה-Backend, מפתחות אישור הלקוח מוגבלים לערכים הבאים:

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

• ב-TLS מאומת בשרת העורפי אין תמיכה בבדיקות של ביטול אישורים.

מכסות ומגבלות

• מאגר אישורים יחיד יכול להכיל עד 200 ישויות עוגן אמינות ואישורי ביניים ביחד, עם מגבלה נפרדת של 100 אישורי ביניים. לכל היותר שלושה אישורים ביניים יכולים לכלול את אותם פרטים של נושא ושל מפתח ציבורי של נושא.

• העומק המקסימלי של שרשרת אישורים הוא 10 אישורים, כולל אישורי הבסיס והקצה. המספר המקסימלי של אישורים ביניים שאפשר להעריך בניסיון לבנות את שרשרת האמון הוא 100.

• ב-TLS עם אימות בקצה העורפי, שרשרת האישורים שמתקבלת מהקצה העורפי מוגבלת ל-16 KB ול-10 אישורים.

• אישורים בסיסיים שמשמשים לאימות לא יכולים להכיל יותר מ-10 מגבלות שם.

• מספר השמות החלופיים לנושא המקסימלי שמותר להזין בשדה tlsSettings.subjectAltNames[] הוא 5.

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

• הגדרה של TLS מאומת בבק-אנד באמצעות אישורים בניהול עצמי