שימוש באישורי SSL בניהול Google

בדף הזה נסביר איך ליצור אישורי SSL בניהול Google ב-Compute Engine ולהשתמש בהם.

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

אישורי SSL שמנוהלים על ידי Google הם אישורים של אימות דומיין (DV) ש-Google Cloud מקבלת ומנהלת עבור הדומיינים שלכם. הם תומכים במספר שמות מארחים בכל אישור, ו-Google מחדשת את האישורים באופן אוטומטי.

יש תמיכה באישורים שמנוהלים על ידי Google במאזני העומסים הבאים:

  • מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
  • מאזן עומסים קלאסי של אפליקציות (ALB)
  • מאזן עומסי רשת חיצוני לשרת proxy (עם שרת proxy של SSL ביעד)

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

אפשר גם להשתמש באישורי SSL מנוהלים עם Google Kubernetes Engine. מידע נוסף זמין במאמר שימוש באישור SSL בניהול Google.

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

לפני שמתחילים

הרשאות

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

  • אתם מוגדרים כבעלים או כעורכים (roles/owner או roles/editor) של הפרויקט.
  • יש לכם בפרויקט את התפקידים אדמין לענייני אבטחה ב-Compute (compute.securityAdmin) ואדמין רשת ב-Compute (compute.networkAdmin).
  • יש לכם תפקיד בהתאמה אישית לפרויקט שכולל את ההרשאות compute.sslCertificates.* ואחת או יותר מההרשאות compute.targetHttpsProxies.* ו-compute.targetSslProxies.*, בהתאם לסוג איזון העומסים שבו אתם משתמשים.

שלב 1. יצירת אישור SSL בניהול Google

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

אם כבר יצרתם אישור SSL בניהול Google, אתם יכולים לדלג על השלב הזה.

המסוף

אפשר לעבוד עם אישורי SSL גלובליים בכרטיסייה אישורים קלאסיים בדף Certificate Manager.

  1. עוברים לכרטיסייה Classic Certificates במסוף Google Cloud .
    מעבר לגרסה הקלאסית של הכלי 'אישורים'
  2. לוחצים על Create SSL certificate (יצירת אישור SSL).
  3. מזינים שם לאישור, ואפשר גם להוסיף תיאור.
  4. בוחרים באפשרות Create Google-managed certificate (יצירת אישור בניהול Google).
  5. מוסיפים את הדומיינים.
  6. לוחצים על יצירה.

gcloud

כדי ליצור אישור SSL גלובלי שמנוהל על ידי Google עבור מאזן עומסים גלובלי חיצוני של אפליקציות או מאזן עומסי רשת חיצוני בשרת proxy, משתמשים בפקודה gcloud compute ssl-certificates create:

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --description=DESCRIPTION \
    --domains=DOMAIN_LIST \
    --global

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

  • ‫CERTIFICATE_NAME: שם לאישור SSL גלובלי
  • ‫DESCRIPTION: תיאור של אישור ה-SSL הגלובלי
  • ‫DOMAIN_LIST: שם דומיין יחיד או רשימה של שמות דומיין שמופרדים בפסיקים, לשימוש באישור הזה

Terraform

כדי ליצור את אישור ה-SSL שמנוהל על ידי Google, משתמשים במשאב google_compute_managed_ssl_certificate.

resource "google_compute_managed_ssl_certificate" "lb_default" {
  provider = google-beta
  name     = "myservice-ssl-cert"

  managed {
    domains = ["example.com"]
  }
}

api

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

POST https://compute.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/global/sslCertificates
{
  "name": "ssl-certificate-name",
  "managed": {
    "domains": [
      "www.example.com"
    ]
  },
  "type": "MANAGED"
}

בדיקת הסטטוס של אישור SSL בניהול Google

המסוף

אפשר לבדוק את הסטטוס של אישורי SSL גלובליים בכרטיסייה אישורים קלאסיים בדף Certificate Manager.

  1. עוברים לכרטיסייה Classic Certificates במסוף Google Cloud .
    מעבר לגרסה הקלאסית של הכלי 'אישורים'
  2. אופציונלי: מסננים את רשימת אישורי ה-SSL.
  3. בודקים את העמודה סטטוס.
  4. כדי לראות פרטים נוספים, לוחצים על שם האישור.

gcloud

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

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

כדי לראות את רשימת אישורי ה-SSL שמנוהלים על ידי Google, משתמשים בפקודה gcloud compute ssl-certificates list עם הדגל --global .

gcloud compute ssl-certificates list \
   --global

אפשר להשתמש בפקודה gcloud compute ssl-certificates describe ולהחליף את CERTIFICATE_NAME:

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

בשלב הזה, סטטוס האישור וסטטוס הדומיין הם PROVISIONING. אחרי שמבצעים את השלבים בדף הזה, הסטטוסים משתנים ל-ACTIVE.

מידע נוסף על הסטטוסים מופיע בדף פתרון הבעיות.

שלב 2: יצירה או עדכון של מאזן העומסים

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

אחרי שיוצרים אישור SSL והוא במצב PROVISIONING, אפשר להשתמש בו במהלך יצירת מאזן העומסים, כמו שמתואר במדריכים הבאים:

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

המסוף

כשמעדכנים מאזן עומסים חיצוני גלובלי של אפליקציות (ALB) או מאזן עומסי רשת בשרת proxy חיצוני באמצעותGoogle Cloud המסוף Google Cloud ,אישור ה-SSL משויך אוטומטית לשרת ה-proxy של היעד הנכון.

  1. נכנסים לדף איזון עומסים במסוף Google Cloud .
    כניסה לדף איזון עומסים
  2. לוחצים על השם של מאזן העומסים.
  3. לוחצים על Edit ‏.
  4. לוחצים על Frontend configuration.
  5. לוחצים על ממשק הקצה הנכון (חייב להיות HTTPS,‏ HTTP/2 או SSL).
  6. לוחצים על אישורים נוספים ובוחרים את האישור שמנוהל על ידי Google מהרשימה הנפתחת.
  7. לוחצים על יצירה.

gcloud

כדי לשייך אישור SSL לשרת proxy של HTTPS ליעד עבור מאזן עומסים של אפליקציות חיצוני גלובלי, משתמשים בפקודה gcloud compute target-https-proxies update עם הדגלים --global-ssl-certificates ו---global:

gcloud compute target-https-proxies update TARGET_PROXY_NAME \
    --ssl-certificates SSL_CERTIFICATE_LIST \
    --global-ssl-certificates \
    --global

כדי לשייך אישור SSL לשרת ה-proxy של SSL היעד עבור מאזן עומסי רשת חיצוני בשרת proxy, משתמשים בפקודה gcloud compute target-ssl-proxies update:

gcloud compute target-ssl-proxies update TARGET_PROXY_NAME \
    --ssl-certificates SSL_CERTIFICATE_LIST

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

  • ‫TARGET_PROXY_NAME: השם של שרת ה-proxy של היעד של מאזן העומסים

  • ‫SSL_CERTIFICATE_LIST: רשימה מופרדת בפסיקים של משאבי אישורי SSL

    מוודאים שרשימת האישורים שאליהם יש הפניות כוללת את כל אישורי ה-SSL הישנים התקפים וגם את אישור ה-SSL החדש. הפקודה gcloud compute target-ssl-proxies update מחליפה את הערכים המקוריים של --ssl-certificates בערך החדש.

Terraform

כדי ליצור את ה-proxy של יעד HTTPS, משתמשים במשאב google_compute_target_https_proxy.

כדי ליצור את שרת ה-proxy של SSL, משתמשים במשאב google_compute_target_ssl_proxy.

resource "google_compute_target_https_proxy" "lb_default" {
  provider = google-beta
  name     = "myservice-https-proxy"
  url_map  = google_compute_url_map.lb_default.id
  ssl_certificates = [
    google_compute_managed_ssl_certificate.lb_default.name
  ]
  depends_on = [
    google_compute_managed_ssl_certificate.lb_default
  ]
}

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

שלב 3: מאמתים את השיוך של שרת ה-proxy של היעד

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

אם אתם לא יודעים את השם של שרת ה-proxy של היעד, אתם יכולים להשתמש בפקודות gcloud compute target-https-proxies list ו-gcloud compute target-ssl-proxies list כדי להציג את רשימת שרתי ה-proxy של היעד בפרויקט.

מריצים את הפקודה הבאה כדי לאמת את השיוך בין אישור ה-SSL לבין שרת ה-proxy של היעד.

למאזני עומסים גלובליים חיצוניים של אפליקציות:

gcloud compute target-https-proxies describe TARGET_HTTPS_PROXY_NAME \
    --global \
    --format="get(sslCertificates)"

למאזנים חיצוניים של עומסי רשת בשרת proxy:

gcloud compute target-ssl-proxies describe TARGET_SSL_PROXY_NAME \
    --format="get(sslCertificates)"

בשלב הזה, סטטוס האישור שמנוהל על ידי Google עדיין יכול להיות PROVISIONING. Google Cloud פועלת עם רשות האישורים כדי להנפיק את האישור. הקצאת אישור שמנוהל על ידי Google עשויה להימשך עד 60 דקות.

שלב 4: מעדכנים את רשומות ה-DNS מסוג A ו-AAAA כך שיפנו לכתובת ה-IP של מאזן העומסים

יכול להיות שרשומות ה-DNS מנוהלות באתר של הרשם, מארח ה-DNS או ספק האינטרנט.

במהלך ניהול הרשומות, חשוב לשים לב לדברים הבאים:

  • מוודאים שרשומות DNS A (ל-IPv4) ורשומות DNS AAAA (ל-IPv6) של הדומיינים ושל כל תת-הדומיינים מפנות לכתובת ה-IP שמשויכת לכלל כללי ההעברה של מאזן העומסים.

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

  • אם אתם משתמשים ב-Cloud DNS, אתם צריכים להגדיר את הדומיינים ולעדכן את שרתי השמות.

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

  • חשוב לוודא שספק ה-DNS מגיב באופן עקבי לכל בקשות האימות של הדומיין הגלובלי.

הקצאת אישורים מנוהלים מתבצעת בהצלחה אם מתקיימים התנאים הבאים:

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

כדי לבדוק את ההגדרה, מריצים את הפקודה dig. לדוגמה, נניח שהדומיין שלכם הוא www.example.com. מריצים את הפקודה הבאה dig:

dig www.example.com

; <<>> DiG 9.10.6 <<>> www.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31748
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.example.com.           IN  A

;; ANSWER SECTION:
www.example.com. 1742    IN      CNAME   example.net.
example.net.      12     IN      A       34.95.64.10

;; Query time: 43 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jun 03 16:54:44 PDT 2020
;; MSG SIZE  rcvd: 193

בדוגמה הזו, 34.95.64.10 היא כתובת ה-IP של מאזן העומסים.

מקודדי DNS באינטרנט לא נמצאים בשליטה שלGoogle Cloud. הם שומרים במטמון את קבוצות רשומות המשאבים בהתאם לאורך החיים (TTL) שלהן, כלומר פקודה dig או nslookup עשויה להחזיר ערך ששמור במטמון. אם אתם משתמשים ב-Cloud DNS, כדאי לעיין במאמר הפצה של שינויים.

זמן ההפצה של רשומת DNS

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

מריצים מחדש את הפקודה הבאה:

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

אם סטטוס הדומיין הוא FAILED_NOT_VISIBLE, יכול להיות שהסיבה לכך היא שההפצה לא הושלמה.

מידע מפורט אפשר למצוא בקטע סטטוס הדומיין של אישור SSL שמנוהל על ידי Google בדף פתרון הבעיות.

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

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).

שלב 5: בדיקה באמצעות OpenSSL

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

כדי לבדוק, מריצים את פקודת OpenSSL הבאה ומחליפים את DOMAIN בשם ה-DNS ואת IP_ADDRESS בכתובת ה-IP של איזון העומסים.

echo | openssl s_client -showcerts -servername DOMAIN -connect IP_ADDRESS:443 -verify 99 -verify_return_error

הפקודה הזו מציגה את האישורים שמאזן העומסים מציג ללקוח. בנוסף למידע מפורט אחר, הפלט צריך לכלול את שרשרת האישורים ואת Verify return code: 0 (ok).

תהליכים נוספים

בקטע הזה מפורטים הליכים נוספים לניהול האישורים.

תמיכה בכמה דומיינים באמצעות אישור SSL בניהול Google

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

אם יש לכם יותר מהמספר המקסימלי של דומיינים, אתם צריכים לבקש כמה אישורים שמנוהלים על ידי Google. לדוגמה, אם מנסים ליצור אישור בניהול Google עם (המספר המקסימלי + 1) דומיינים, Google לא מנפיקה אישורים. במקום זאת, צריך ליצור שני אישורים או יותר שמנוהלים על ידי Google, ולציין במפורש אילו דומיינים משויכים לכל אישור.

‫Google Cloud מיישם את Server Name Indication‏ (SNI), כפי שמוגדר ב-RFC 6066.

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

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

חידוש אישור SSL בניהול Google

‫Google Cloud provisions managed certificates valid for 90 days. תהליך חידוש האישור מתחיל אוטומטית כחודש לפני תאריך התפוגה. לשם כך, בוחרים רשות אישורים (CA) שמופיעה גם ברשומת ה-DNS של הרשאת רשות האישורים (CAA) של הדומיין וגם ברשימת רשויות האישורים.

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

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

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

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

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

כדי לעשות זאת, יוצרים או משנים רשומת CAA כך שתכלול את pki.goog או את letsencrypt.org או את שניהם. אם אין לכם רשומת CAA, התנהגות ברירת המחדל היא לאפשר גם pki.goog וגם letsencrypt.org.

DOMAIN. CAA 0 issue "pki.goog"
DOMAIN. CAA 0 issue "letsencrypt.org"

התמיכה באישור letsencrypt.org ניתנת על בסיס המאמץ הטוב ביותר. כדי להבטיח את המהימנות הכי גבוהה, מומלץ לאפשר גם את pki.goog וגם את letsencrypt.org. אם מציינים רק רשות CA אחת, רק היא תשמש ליצירה ולחידוש של האישור. הגישה הזו לא מומלצת.

כשיוצרים את האישור בפעם הראשונה,המערכת בוחרת בין pki.goog לבין letsencrypt.org ומשתמשת בו כדי להנפיק את האישור. Google Cloud כש-Google מחדשת את האישור שלכם, יכול להיות שהאישור יונפק על ידי רשות האישורים השנייה, בהתאם לרשויות האישורים שציינתם ברשומת ה-CAA (אם יצרתם כזו). יכול להיות שהאישור שלכם יחודש על ידי רשות אישורים אחרת באחד מהמקרים הבאים:

  • אין לכם רשומת CAA DNS לדומיין.
  • כללתם את שני הרשויות המנפיקות ברשומת ה-CAA של ה-DNS.

מידע נוסף זמין ב-RFC, רשומת CAA DNS.

letsencrypt.org בעיות בשמות דומיין בינלאומיים (IDN). ‫pki.goog לא תומך כרגע בשמות דומיין בינלאומיים (IDN).

אם אתם משתמשים ב-Cloud DNS, כדאי לקרוא איך מוסיפים רשומה ולוודא שהגדרתם את הדגל --type לערך CAA.

החלפת אישור SSL קיים

כדי להחליף אישור SSL קיים:

  1. מתחילים את התהליך ליצירת אישור SSL חלופי בניהול Google. האישור הזה לא הופך לפעיל בשלב הזה.

  2. מעדכנים את שרת ה-proxy של היעד כך שרשימת האישורים המופנים תכלול את אישור ה-SSL החלופי לצד אישורי ה-SSL הנוכחיים. השלבים לעדכון שרת ה-proxy לטירגוט משתנים, כמו שמתואר בהמשך:

  3. ממתינים לסיום הקצאת אישור ה-SSL החלופי. הקצאת ההרשאות עשויה להימשך עד 60 דקות. כשהקצאת ההרשאות מסתיימת, סטטוס האישור משתנה ל-ACTIVE.

  4. צריך להמתין עוד 30 דקות כדי לוודא שהאישור החלופי זמין לכל ממשקי הקצה של Google ‏ (GFE).

  5. מעדכנים את שרת ה-proxy של היעד כדי להסיר את אישור ה-SSL שרוצים להחליף מהרשימה של האישורים שמפנים אליהם. השלבים לעדכון של שרת proxy ליעד משתנים בהתאם למצב:

  6. מחכים 10 דקות ומוודאים שמאזן העומסים משתמש באישור ה-SSL החדש במקום באישור הישן.

  7. מעדכנים שוב את שרת ה-proxy של היעד ומסירים את משאב אישור ה-SSL הישן. אתם יכולים למחוק את משאב אישור ה-SSL אם הוא כבר לא מפנה לאף שרת proxy ליעד.

אם לא מוחקים את אישור ה-SSL הישן, הוא נשאר פעיל עד שתוקפו פג.

מעבר מאישורי SSL בניהול עצמי לאישורי SSL בניהול Google

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

  1. יוצרים אישור חדש שמנוהל על ידי Google.
  2. משייכים אישור חדש שמנוהל על ידי Google לשרת ה-proxy הנכון של היעד, תוך שמירה על השיוך של שרת ה-proxy של היעד לאישור הקיים שמנוהל באופן עצמאי.
  3. ממתינים עד שהסטטוס של האישור שמנוהל על ידי Google יהיה ACTIVE.
  4. מחכים 30 דקות כדי לאפשר לאישור החדש להתפשט ל-Google Front Ends‏ (GFE) שמציגים את התוכן
  5. מעדכנים שוב את שרת ה-proxy של היעד ומסירים את משאב האישור בניהול עצמי. אם אין יותר הפניה למשאב אישור SSL בניהול עצמי משרת proxy ליעד, אפשר למחוק אותו.

מחיקת אישור SSL

לפני שמוחקים אישור SSL, צריך לוודא שאף פרוקסי יעד של HTTPS או SSL לא מפנה לאישור הזה. יש שתי דרכים לעשות את זה:

כדי למחוק אישור SSL אחד או יותר:

המסוף

אפשר למחוק אישורי SSL גלובליים בכרטיסייה אישורים קלאסיים בדף Certificate Manager.

  1. עוברים לכרטיסייה Classic Certificates במסוף Google Cloud .
    מעבר לגרסה הקלאסית של הכלי 'אישורים'
  2. בוחרים את אישור ה-SSL שרוצים למחוק.
  3. לוחצים על מחיקה.
  4. כדי לאשר, לוחצים שוב על מחיקה.

gcloud

כדי למחוק אישור SSL גלובלי (למאזני עומסים גלובליים חיצוניים של אפליקציות או למאזני עומסי רשת חיצוניים לשרת proxy), משתמשים בפקודה gcloud compute ssl-certificates delete עם הפקודה --global:

gcloud compute ssl-certificates delete CERTIFICATE_NAME \
    --global

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

  • ‫CERTIFICATE_NAME: השם של אישור ה-SSL

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

  • כדי לפתור בעיות שקשורות לאישורי SSL, אפשר לעיין במאמר פתרון בעיות שקשורות לאישורי SSL.
  • כדי להשתמש בסקריפט Terraform שיוצר אישור בניהול Google, אפשר לעיין בדוגמה של Cloud Run בדף דוגמאות למודולים של Terraform למאזן עומסים חיצוני של אפליקציות (ALB).