שימוש באישורי 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 עבור מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) או מאזן עומסי רשת חיצוני בשרת 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 צריך להיות משויך למאזן עומסים, ובאופן ספציפי לפרוקסי היעד של מאזן העומסים.

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

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

המסוף

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

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

gcloud

כדי לשייך אישור SSL לשרת proxy של HTTPS ליעד עבור מאזן עומסים חיצוני גלובלי של אפליקציות (ALB), משתמשים בפקודה 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: השם של שרת היעד של מאזן העומסים

  • ‫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
  ]
}

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

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

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

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

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

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

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

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

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

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

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 ‏ (GFE)
  5. מעדכנים שוב את שרת ה-proxy של היעד ומסירים את משאב האישור בניהול עצמי. אם אין יותר הפניות למשאב של אישור SSL בניהול עצמי מפרוקסי יעד כלשהו, אפשר למחוק אותו.

מחיקת אישור 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 למאזן עומסים של אפליקציות חיצוני.