‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

openssl x509 -in CERTIFICATE_FILE -text -noout

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

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

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

ב-Google Cloud נדרש שלאישור יהיה מאפיין של שם נפוץ (CN) או שם חלופי של בעלים (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: הנתיב שבו רוצים לשמור עותק של המפתח הפרטי בטקסט פשוט

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

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

כשתוקף של אישור ביניים פג, יכול להיות שאישור הקצה שמשמש ב-Google Cloud לא יהיה תקף. ההגדרה תלויה בלקוח ה-SSL, כמו שמתואר בהמשך:

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

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

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

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

המעריך הציבורי של 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 יחיד שמצורף לשרת ה-proxy ל-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: השם של משאב ה-Proxy ל-HTTPS עם יעד.
‫SSL_CERT_NAME: השם של אישור ה-SSL.

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