פתרון בעיות ב-Certificate Manager

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

לקבלת עזרה בפתרון בעיות שקשורות לאישורי TLS ‏ (SSL), אפשר לעיין במאמר בנושא פתרון בעיות שקשורות לאישורי SSL.

שגיאות שקשורות לאישורים של Certificate Manager

בקטע הזה מופיע מידע לפתרון בעיות שקשורות לשדה authorizationAttemptInfo של אישורים מ-Certificate Manager שמנוהלים על ידי Google. השגיאות מוצגות בקטע managed.authorizationAttemptInfo.troubleshooting רק אם השדות הבאים מכילים את הערכים האלה:

  • managed.authorizationAttemptInfo.state = FAILED
  • managed.authorizationAttemptInfo.failureReason = CONFIG

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

שגיאה תיאור
CNAME_MISMATCH השגיאה הזו מתרחשת רק בהרשאות DNS כשהערך של רשומת CNAME הצפויה לא תואם לערך של רשומת CNAME שנפתרה.

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

RESOLVED_TO_NOT_SERVING השגיאה הזו מתרחשת כשהדומיין מכיל רשומות DNS A ו-AAAA שמפנות לכתובות IP מסוימות שבהן האישור לא מצורף לאף מאזן עומסים.

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

כדי לפתור את הבעיה, צריך לעדכן את רשומות ה-DNS A ו-AAAA של הדומיין כך שיפנו לכתובת ה-IP של מאזן העומסים. כתובות ה-IP שמתקבלות מרשומות ה-DNS A ו-AAAA של הדומיין מאוחסנות בפרמטר ips.resolved, וכתובות ה-IP של מאזן העומסים שאליו מצורף האישור הזה מאוחסנות בפרמטר ips.serving.

רשומות ה-DNS A ו-AAAA של הדומיין צריכות להפנות רק לכתובת ה-IP של מאזן העומסים. לדוגמה, אם רשומת A של DNS מפנה לכתובת ה-IP של מאזן העומסים, אבל רשומת AAAA של DNS מפנה לכתובת IP אחרת, תופיע השגיאה RESOLVED_TO_NOT_SERVING.

בנוסף, צריך לוודא שרשומות ה-DNS A ו-AAAA של הדומיין מתורגמות בצורה נכונה ועקבית בכל העולם. מידע נוסף זמין בקטע כשלים באימות דומיין מנקודות מבט שונות.

NO_RESOLVED_IPS השגיאה הזו מתרחשת כשהדומיין לא מכיל רשומות DNS A ו-AAAA.

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

כדי לפתור את הבעיה, מוסיפים רשומות DNS A ו-AAAA לדומיין הזה ומוודאים שהרשומות מפנות לכתובת ה-IP של שרת ה-proxy של HTTPS או של שירות ה-cache של Media CDN.

בנוסף, צריך לוודא שרשומות ה-DNS A ו-AAAA של הדומיין מתורגמות בצורה נכונה ועקבית בכל העולם. מידע נוסף זמין בקטע כשלים באימות דומיין מנקודות מבט שונות.

RESOLVED_TO_SERVING_ON_ALT_PORTS השגיאה הזו מתרחשת כשהדומיין שמכיל רשומות DNS A ו-AAAA מפנה לכתובות IP של איזון עומסים שבהן האישור הזה מצורף, אבל היציאה 443 לא פתוחה בכתובות ה-IP האלה.

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

כדי לפתור את הבעיה, צריך לוודא שמאזן העומסים עם האישור המצורף מאזין ליציאה 443. הפרמטר ips.serving_on_alt_ports מאחסן את רשימת כתובות ה-IP של איזון העומסים שבהן היציאה 443 לא פתוחה.

בנוסף, צריך לוודא שרשומות ה-DNS A ו-AAAA של הדומיין מתורגמות בצורה נכונה ועקבית בכל העולם. מידע נוסף זמין בקטע כשלים באימות דומיין מנקודות מבט שונות.

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

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

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

שגיאה כשמבטלים את הצירוף של מיפוי אישורים לשרת proxy ליעד

כשמנתקים מפת אישורים משרת proxy ליעד, מופיעה השגיאה הבאה:

"There must be at least one certificate configured for a target proxy."

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

שגיאה בשיוך של רשומה במפת אישורים לאישור

כשמשייכים רשומת מיפוי לאישורים לאישור, מוצגת השגיאה הבאה:

"certificate can't be used more than 100 times"

השגיאה הזו מתרחשת כשמנסים לשייך רשומה במפת אישורים לאישור שכבר משויך ל-100 רשומות במפת אישורים. כדי לפתור את הבעיה:

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

בעיות שקשורות לאישורים שהונפקו על ידי מופע של שירות CA

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

אם קיבלתם את השגיאה Failed to create Certificate Issuance Config resources, בדקו את הדברים הבאים:

  • משך החיים. ערכי משך החיים החוקיים של האישור הם בין 21 ל-30 ימים.
  • אחוז חלון הרוטציה. האחוזים התקינים של חלון הסיבוב הם מ-1 עד 99 אחוז. צריך להגדיר את אחוז חלון הרוטציה ביחס לזמן החיים של האישור, כך שחידוש האישור יתרחש לפחות 7 ימים אחרי שהאישור הונפק ולפחות 7 ימים לפני שהוא יפוג.
  • אלגוריתם המפתח. הערכים התקינים של אלגוריתם המפתח הם: RSA_2048 ו-ECDSA_P256.
  • מאגר הרשות שמנפיקה את האישורים (CA). מאגר אישורי ה-CA לא קיים או שההגדרה שלו שגויה. מאגר רשויות האישורים צריך להכיל לפחות רשות אישורים אחת שמופעלת, ולמתקשר צריכה להיות הרשאת privateca.capools.use בפרויקט היעדGoogle Cloud . באישורים אזוריים, צריך ליצור את משאב ההגדרה של הנפקת האישור באותו מיקום שבו נמצא מאגר ה-CA.

אם מופיעה השגיאה Failed to create a managed certificate, צריך לבדוק את הדברים הבאים:

  • משאב ההגדרה של הנפקת האישור שציינתם כשנוצר האישור קיים.
  • למתקשר יש הרשאה certificatemanager.certissuanceconfigs.use במשאב ההגדרה של הנפקת האישור שציינתם כשנוצר האישור.
  • האישור נמצא באותו מיקום כמו משאב ההגדרה של הנפקת האישור.

אם מופיעה שגיאה Failed to renew certificate או Failed to provision certificate, צריך לבדוק את הדברים הבאים:

  • לחשבון השירות של Certificate Manager יש את ההרשאה roles/privateca.certificateRequester במאגר ה-CA שצוין במשאב של הגדרת הנפקת האישורים שמשמש לאישור הזה.

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

    gcloud privateca pools get-iam-policy CA_POOL
    --location REGION
    

    מחליפים את מה שכתוב בשדות הבאים:

    • CA_POOL: הנתיב המלא של המשאב והשם של מאגר CA היעד
    • REGION: אזור היעד Google Cloud
  • מדיניות הנפקת אישורים בתוקף. מידע נוסף מופיע במאמר בנושא בעיות שקשורות להגבלות של מדיניות הנפקה.

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

אם Certificate Manager לא תומך בשינויים באישור שבוצעו על ידי מדיניות הנפקת האישורים, הקצאת האישורים תיכשל והמצב של האישור המנוהל ישתנה ל-Failed. כדי לפתור את הבעיה, צריך לוודא את הדברים הבאים:

  • מגבלות הזהות של האישור מאפשרות העברה של בעלים (subject) ושם חלופי של בעלים (subject) (SAN).
  • האילוץ maximum lifetime של האישור גדול יותר ממשך החיים של משאב ההגדרה של הנפקת האישור.

במקרים של הבעיות הקודמות, מכיוון ש-CA Service כבר הנפיק את האישור, תחויבו בהתאם לתמחור של CA Service.

אם מופיעה השגיאה Rejected for issuing certificates from the configured CA Pool, המשמעות היא שמדיניות הנפקת האישורים חסמה את האישור המבוקש. כדי לפתור את השגיאה, צריך לבדוק את הפרטים הבאים:

במקרים הקודמים, לא נחייב אתכם על ידי שירות ה-CA כי שירות ה-CA לא הנפיק את האישור.

בעיות שקשורות להתאמה של שם מארח ב-IAP

אם אתם מקבלים באופן לא צפוי את השגיאה The host name provided does not match the SSL certificate on the server כשאתם משתמשים ב-Certificate Manager עם שרת proxy לאימות זהויות (IAP), בדקו שאתם משתמשים באישור שתקף לשם המארח הזה. גם רשומות מיפוי לאישורים שהגדרתם במיפוי האישורים. לכל שם מארח או שם מארח עם wildcard שאתם מתכוונים להשתמש בו עם IAP צריך להיות רשומה ייעודית. אם רשומת המיפוי לאישורים של שם המארח חסרה, צריך ליצור רשומת מיפוי לאישורים.

בקשות שחוזרות לערך הראשי במפת האישורים במהלך בחירת האישור תמיד נדחות על ידי IAP.

כשלים באימות דומיין מנקודות מבט שונות

Google Cloud מחדש מעת לעת את האישורים שמנוהלים על ידי Google על ידי שליחת בקשה לרשויות אישורים (CA). רשויות האישורים ש-Google Cloud עובדת איתן כדי לחדש את האישורים משתמשות בשיטת אימות דומיין מרובת-פרספקטיבות שנקראת Multi-Perspective Issuance Corroboration ‏(MPIC). כחלק מהתהליך הזה, רשויות האישורים מאמתות את השליטה בדומיין על ידי בדיקת הגדרות ה-DNS של הדומיין, ובמקרה של הרשאה של איזון עומסים, על ידי ניסיון ליצור קשר עם השרת שמאחורי כתובת ה-IP של הדומיין. האימותים האלה מתבצעים מכמה נקודות תצפית באינטרנט. אם תהליך האימות נכשל, לא ניתן לחדש את האישורים שמנוהלים על ידי Google. כתוצאה מכך, מאזן העומסים מציג ללקוחות אישור שתוקפו פג, ולכן משתמשים בדפדפן נתקלים בשגיאות באישור ולקוחות API נתקלים בבעיות בחיבור.

כדי למנוע כשלים באימות הדומיין מנקודות מבט שונות בגלל רשומות DNS שהוגדרו בצורה שגויה, חשוב לשים לב לנקודות הבאות:

  • רשומות ה-DNS A (IPv4) ורשומות ה-DNS AAAA (IPv6) של הדומיינים ושל כל תת-הדומיינים מפנות רק לכתובת ה-IP (או לכתובות ה-IP) שמשויכת לכלל ההעברה (או לכללים) של מאזן העומסים. הוספה של כתובות אחרות לרשומה עלולה לגרום לכך שהאימות ייכשל.
  • רשות האישורים (CA), שמבצעת אימות של רשומות DNS, שולחת שאילתות לרשומות DNS מכמה מיקומים. חשוב לוודא שספק ה-DNS מגיב באופן עקבי לכל בקשות האימות של הדומיין הגלובלי.
  • שימוש ב-GeoDNS (החזרת כתובות IP שונות על סמך מיקום הבקשה) או במדיניות DNS מבוססת-מיקום עלול להוביל לתגובות לא עקביות ולגרום לכשל באימות. אם ספק ה-DNS שלכם משתמש ב-GeoDNS, צריך להשבית אותו, או לוודא שכל האזורים מחזירים את אותה כתובת IP של מאזן העומסים.
  • אם אתם משתמשים בשיטה load balancer authorization כדי להקצות אישורים שמנוהלים על ידי Google, אתם צריכים לציין באופן מפורש את כתובות ה-IP של מאזן העומסים בהגדרת ה-DNS. שכבות ביניים, כמו CDN, עלולות לגרום להתנהגות בלתי צפויה. כתובת ה-IP צריכה להיות נגישה ישירות ללא הפניות אוטומטיות, חומות אש או רשתות CDN בנתיב הבקשה. מידע נוסף זמין בקטע מאזני עומסים מאחורי CDN במסמך הזה.
  • מומלץ להשתמש בכלי לבדיקת הפצת DNS גלובלית לפי בחירתכם כדי לוודא שכל רשומות ה-DNS הרלוונטיות מתורגמות בצורה נכונה ועקבית בכל העולם.

אימות שינויים בהגדרות

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

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

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

מאזני עומסים מאחורי CDN

במאזני עומסים שמופעל בהם CDN, יכול להיות שספקי CDN מסוימים של צד שלישי בנתיב הבקשה ימנעו את השלמת בקשות האימות. זה יכול לקרות אם ספק ה-CDN מבצע Proxy באופן פעיל לתנועת HTTP(S).

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

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