סקירה כללית של 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 קודמת למערכת חדשה בלי השבתה.

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

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

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

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

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

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

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

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

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

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

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

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

  • תוסף basic constraints חייב להכיל את CA=true.
  • תוסף השימוש במפתח חייב להיות מוגדר ל-keyCertSign.
  • התוסף extended key usage חייב להכיל את השדה 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. הגדרת האמון לא נדרשת כשבהגדרת האימות של השרת העורפי נעשה שימוש בשורשי האמון הציבוריים כדי לאמת את אישור השרת.

• שורשים ציבוריים של אמון (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 של העורף כולל SAN שתואם לשם המארח של SNI.

כברירת מחדל, מאזן העומסים בודק שאישור ה-TLS של ה-Backend כולל SAN שתואם לשם המארח של SNI. עם זאת, אם מוגדרים שמות חלופיים לנושא בשירות לקצה העורפי (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 במשאב של הגדרת האימות בקצה העורפי. עם זאת, אתם יכולים גם ליצור הגדרת מהימנות שכוללת באופן מפורש את הבסיסים של האישורים שהונפקו לכם באופן ציבורי, בנוסף לאישורים שהוגדרו כמהימנים בהגדרת המהימנות.

ההגדרה 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. יצירת חיבור לקצה העורפי.

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

   עם זאת, אם אימות האישור נכשל, מאזן העומסים מסיים את החיבור לבק-אנד, שולח קוד סטטוס 502‏ HTTP ללקוח ומתעד את סיבת הסיום ב-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) של אישור השרת (כולל אישורי ביניים) גדול מדי (יותר מ-‎16 KB).	server_cert_exceeded_size_limit

מגבלות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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