פתרון בעיות שקשורות לאישורי SSL

נוהלי פתרון הבעיות משתנים בהתאם לסוג אישורי ה-SSL שבהם משתמשים.

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

יש שני סוגים של סטטוסים לגבי אישורים בניהול Google:

סטטוס מנוהל
סטטוס הדומיין

סטטוס מנוהל

כדי לבדוק את סטטוס האישור, מריצים את הפקודה הבאה:

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
    --global \
    --format="get(name,managed.status)"

הערכים של סטטוס מנוהל הם:

סטטוס מנוהל	הסבר
`PROVISIONING`	האישור שמנוהל על ידי Google נוצר ופועל עם רשות האישורים כדי לחתום עליו. Google Cloud יכול להיות שיעברו עד 60 דקות מרגע שהשינויים בהגדרות ה-DNS ומאזן העומסים יתעדכנו באינטרנט, עד שהמערכת של Google תקצה אישור. אם עדכנתם לאחרונה את הגדרות ה-DNS, יכול להיות שיעבור זמן רב עד שהשינויים יתעדכנו באופן מלא. לפעמים ההפצה נמשכת עד 72 שעות ברחבי העולם, אבל בדרך כלל היא נמשכת כמה שעות. מידע נוסף על הפצת DNS זמין במאמר בנושא הפצת שינויים. אם האישור נשאר במצב `PROVISIONING`, צריך לוודא שהאישור הנכון משויך לשרת ה-Proxy של היעד. כדי לבדוק את זה, מריצים את הפקודה `gcloud compute target-https-proxies describe` או את הפקודה `gcloud compute target-ssl-proxies describe`.
`ACTIVE`	אישור ה-SSL שמנוהל על ידי Google מתקבל מרשות האישורים. יכול להיות שיעברו עוד 30 דקות עד שהאישור יהיה זמין לשימוש על ידי מאזן עומסים.
`PROVISIONING_FAILED`	יכול להיות שתראו לזמן קצר את ההודעה `PROVISIONING_FAILED` גם אם התעודה שלכם היא `ACTIVE`. בודקים שוב את הסטטוס. אם הסטטוס נשאר `PROVISIONING_FAILED`, האישור שמנוהל על ידי Google נוצר, אבל רשות האישורים לא יכולה לחתום עליו. מוודאים שהשלמתם את כל השלבים במאמר בנושא שימוש באישורי SSL בניהול Google. Google Cloud retries provisioning until successful or the status changes to `PROVISIONING_FAILED_PERMANENTLY`.
`PROVISIONING_FAILED_PERMANENTLY`	האישור שמנוהל על ידי Google נוצר, אבל רשות האישורים לא יכולה לחתום עליו בגלל בעיה בהגדרת DNS או איזון עומסים. במצב הזה, Google Cloud לא מנסה שוב להקצות משאבים. יוצרים אישור SSL חלופי שמנוהל על ידי Google, ומוודאים שהאישור החלופי משויך לשרת ה-proxy של מאזן העומסים. מוודאים או משלימים את כל השלבים במאמר בנושא שימוש באישורי SSL בניהול Google. אחרי כן, תוכלו למחוק את האישור שהקצאת ההרשאות שלו נכשלה באופן סופי.
`RENEWAL_FAILED`	חידוש האישור שמנוהל על ידי Google נכשל בגלל בעיה במאזן העומסים או בהגדרת ה-DNS. אם אחד מהדומיינים או מהתת-דומיינים באישור מנוהל לא מפנה לכתובת ה-IP של מאזן העומסים באמצעות רשומת A/AAAA, תהליך החידוש ייכשל. האישור הקיים ממשיך לפעול, אבל התוקף שלו יפוג בקרוב. בודקים את ההגדרה. אם הסטטוס נשאר `RENEWAL_FAILED`, צריך להקצות אישור חדש, לעבור לשימוש באישור החדש ולמחוק את האישור הקודם. מידע נוסף על חידוש אישורים זמין במאמר בנושא חידוש אישורי SSL בניהול Google.

סטטוס הדומיין

כדי לבדוק את סטטוס הדומיין, מריצים את הפקודה הבאה:

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
    --global \
    --format="get(managed.domainStatus)"

הערכים של סטטוס הדומיין מפורטים בטבלה הזו.

סטטוס הדומיין	הסבר
`PROVISIONING`	נוצר אישור בניהול Google לדומיין. ‫ Google Cloud פועל מול רשות האישורים כדי לחתום על האישור.
`ACTIVE`	הדומיין אומת בהצלחה לצורך הקצאת האישור. אם אישור ה-SSL הוא עבור כמה דומיינים, אפשר להקצות את האישור רק אחרי שכל הדומיינים מקבלים סטטוס `ACTIVE` וגם הסטטוס המנוהל של האישור הוא `ACTIVE`.
`FAILED_NOT_VISIBLE`	הקצאת האישורים לדומיין לא הושלמה. הבעיה יכולה להיות אחת מהסיבות הבאות: רשומת ה-DNS של הדומיין לא מתפרשת ככתובת ה-IP של מאזן העומסים Google Cloud . כדי לפתור את הבעיה, צריך לעדכן את רשומות ה-DNS A ו-AAAA כך שיפנו לכתובת ה-IP של מאזן העומסים. ה-DNS לא יכול להפנות לכתובת IP אחרת מלבד כתובת ה-IP של איזון העומסים. לדוגמה, אם רשומת A מפנה למאזן העומסים הנכון, אבל רשומת AAAA מפנה למשהו אחר, סטטוס הדומיין הוא `FAILED_NOT_VISIBLE`. יכול לעבור הרבה זמן עד שהשינויים ברשומות DNS A ו-AAAA יתעדכנו באופן מלא. לפעמים לוקח עד 72 שעות עד שהשינויים מופיעים באינטרנט ברחבי העולם, אבל בדרך כלל זה קורה תוך כמה שעות. סטטוס הדומיין יישאר `FAILED_NOT_VISIBLE` עד לסיום ההפצה. אישור ה-SSL לא מצורף לפרוקסי היעד של מאזן העומסים. כדי לפתור את הבעיה, צריך לעדכן את ההגדרות של מאזן העומסים. יציאות הקצה הקדמי של כלל ההעברה לא כוללות את יציאה 443 למאזני עומסים של אפליקציות (גלובליים או קלאסיים) או למאזני עומסי רשת בשרת proxy חיצוני. כדי לפתור את הבעיה, צריך להוסיף כלל העברה חדש עם יציאה 443. מפת אישורים של Certificate Manager מצורפת לשרת ה-proxy של היעד. מפת האישורים המצורפת מקבלת עדיפות, והמערכת מתעלמת מאישורים שמצורפים ישירות. כדי לפתור את הבעיה, צריך לנתק את מיפוי האישורים מה-proxy. אם הסטטוס המנוהל הוא `PROVISIONING`, Google Cloud המערכת ממשיכה לנסות להקצות את השירות, גם אם סטטוס הדומיין הוא `FAILED_NOT_VISIBLE`.
`FAILED_CAA_CHECKING`	הקצאת האישור נכשלה בגלל בעיה בהגדרות של רשומת ה-CAA בדומיין. עליכם לוודא ש פעלתם לפי ההליך הנכון.
`FAILED_CAA_FORBIDDEN`	הקצאת האישור נכשלה כי ברשומת ה-CAA של הדומיין לא צוינה רשות אישורים ש- Google Cloud צריכה להשתמש בה. חשוב לוודא שפעלתם לפי ההליך הנכון.
`FAILED_RATE_LIMITED`	הקצאת הרשאות ידנית של אישורים נכשלה כי רשות אישורים הגבילה את קצב יצירת הבקשות לחתימה על אישורים. אפשר להקצות אישור חדש, לעבור לשימוש באישור החדש ולמחוק את האישור הקודם, או לפנות אלGoogle Cloud התמיכה.

חידוש אישור מנוהל

כדי לוודא שהאישורים שלכם לא ייכשלו בשלב אימות הדומיין בתהליך החידוש, כדאי לעיין בדרישות לרשומות DNS מסוג A ו-AAAA.

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

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 של מאזן העומסים.
צריך לציין במפורש את כתובות ה-IP של איזון העומסים בהגדרות ה-DNS. שכבות ביניים, כמו CDN, עלולות לגרום להתנהגות בלתי צפויה. כתובת ה-IP צריכה להיות נגישה ישירות ללא הפניות אוטומטיות, חומות אש או רשתות CDN בנתיב הבקשה. מידע נוסף זמין בקטע מאזני עומסים מאחורי CDN במאמר הזה.
מומלץ להשתמש בכלי לבדיקת הפצת DNS גלובלית לפי בחירתכם כדי לוודא שכל רשומות ה-DNS הרלוונטיות מתורגמות בצורה נכונה ועקבית בכל העולם.

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

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

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

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

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

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

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

פתרון בעיות שקשורות לאישורי SSL בניהול עצמי

במדריך הזה מוסבר איך לפתור בעיות בהגדרות של אישורי SSL בניהול עצמי.

לא ניתן לנתח את האישור

Google Cloud נדרשים אישורים בפורמט PEM. אם האישור הוא בפורמט PEM, צריך לבדוק את הדברים הבאים:

כדי לאמת את האישור, אפשר להשתמש בפקודה הבאה של OpenSSL, ולהחליף את CERTIFICATE_FILE בנתיב לקובץ האישור:

openssl x509 -in CERTIFICATE_FILE -text -noout

אם OpenSSL לא מצליח לנתח את האישור:

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

חסר שם נפוץ או שם חלופי של בעלים (subject)

‫Google Cloud מחייב שהאישור יכלול או שם נפוץ (CN) או מאפיין של שם חלופי של בעלים (subject) (SAN). מידע נוסף זמין במאמר בנושא יצירת בקשת חתימה על אישור (CSR).

אם שני המאפיינים לא מופיעים, Google Cloud מוצגת הודעת שגיאה כמו זו שבהמשך כשמנסים ליצור אישור בניהול עצמי:

ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch resource:
 -   The SSL certificate is missing a Common Name(CN) or Subject Alternative
   Name(SAN).

אי אפשר לנתח את המפתח הפרטי

Google Cloud נדרשים מפתחות פרטיים בפורמט PEM שעומדים בקריטריונים של מפתח פרטי.

כדי לאמת את המפתח הפרטי, אפשר להשתמש בפקודת OpenSSL הבאה ולהחליף את PRIVATE_KEY_FILE בנתיב למפתח הפרטי:

    openssl rsa -in PRIVATE_KEY_FILE -check

התגובות הבאות מציינות שיש בעיה במפתח הפרטי:

unable to load Private Key
Expecting: ANY PRIVATE KEY
RSA key error: n does not equal p q
RSA key error: d e not congruent to 1
RSA key error: dmp1 not congruent to d
RSA key error: dmq1 not congruent to d
RSA key error: iqmp not inverse of q

כדי לפתור את הבעיה, צריך ליצור מפתח פרטי חדש ותעודה.

מפתחות פרטיים עם ביטויי סיסמה

אם OpenSSL מבקש סיסמה, צריך להסיר את הסיסמה מהמפתח הפרטי לפני שמשתמשים בו עם Google Cloud. אפשר להשתמש בפקודת OpenSSL הבאה:

openssl rsa -in PRIVATE_KEY_FILE \
    -out REPLACEMENT_PRIVATE_KEY_FILE

מחליפים את ה-placeholders בערכים תקינים:

‫PRIVATE_KEY_FILE: הנתיב למפתח הפרטי שמוגן באמצעות סיסמה
‫REPLACEMENT_PRIVATE_KEY_FILE: הנתיב שבו רוצים לשמור עותק של המפתח הפרטי בטקסט פשוט

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

אם תוקף של אישור ביניים פג לפני תוקף של אישור השרת (העלה), יכול להיות שרשות האישורים לא פועלת לפי השיטות המומלצות.

כשאישור ביניים פג, יכול להיות שהאישור הסופי שבו אתם משתמשים ב-Google Cloud כבר לא יהיה תקף. הפעולה הזו תלויה בלקוח ה-SSL, באופן הבא:

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

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

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

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

המעריך הציבורי של RSA גדול מדי

הודעת השגיאה הבאה מופיעה כשהמעריך הציבורי של RSA גדול מ-65537. חשוב להשתמש ב-65537, כפי שמצוין ב-RFC 4871.

ERROR: (gcloud.compute.ssl-certificates.create) Could not fetch resource:
 -   The RSA public exponent is too large.

הסרת אישור SSL משרת proxy ליעד

השלבים הבאים מראים איך להסיר אישור SSL יחיד שמצורף לפרוקסי היעד של HTTPS:

מייצאים את ה-target-https-proxy לקובץ זמני.

gcloud compute target-https-proxies export TARGET_PROXY_NAME > /tmp/proxy

עורכים את הקובץ /tmp/proxy ומסירים את השורות הבאות:
```
sslCertificates:
-   https://www.googleapis.com/compute/v1/projects/...
```

מייבאים את הקובץ /tmp/proxy.

gcloud compute target-https-proxies import TARGET_PROXY_NAME \
   --source=/tmp/proxy

אופציונלי: מוחקים את אישור ה-SSL.
```
gcloud compute ssl-certificates delete SSL_CERT_NAME
```

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

‫TARGET_PROXY_NAME: השם של משאב ה-HTTPS proxy של היעד.
‫SSL_CERT_NAME: השם של אישור ה-SSL.

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