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

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

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

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

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

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

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

openssl x509 -in CERTIFICATE_FILE -text -noout

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

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

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

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

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

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

Cloud de Confiance נדרשים מפתחות פרטיים בפורמט 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 מבקש סיסמה, צריך להסיר את הסיסמה מהמפתח הפרטי לפני שמשתמשים בו עם Cloud de Confiance. אפשר להשתמש בפקודת OpenSSL הבאה:

openssl rsa -in PRIVATE_KEY_FILE \
    -out REPLACEMENT_PRIVATE_KEY_FILE

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

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

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

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

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

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

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

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

יכול להיות שרשות האישורים שלכם תאפשר גם חתימה צולבת לאישורי ביניים. כדאי לבדוק את זה מול הרשות שמנפיקה את האישורים (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:

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

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

  2. עורכים את הקובץ /tmp/proxy ומסירים את השורות הבאות:

    sslCertificates:
-   https://www.googleapis.com/compute/v1/projects/...

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

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

  4. אופציונלי: מוחקים את אישור ה-SSL.

    gcloud compute ssl-certificates delete SSL_CERT_NAME

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

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