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

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

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

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

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

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

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

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

• חשוב לקרוא את הסקירה הכללית על אישורי SSL.
• מוודאים שיש לכם את שמות הדומיינים שאתם רוצים להשתמש בהם לאישור ה-SSL בניהול Google. אם אתם משתמשים ב-Cloud Domains, קראו את המאמר רישום דומיין.

• מוודאים שהפעלתם את Compute Engine API בפרויקט.

  להפעלת Compute Engine API

הרשאות

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

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

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

הערה: מידע על אישורים בניהול Google ל-GKE Ingress זמין במאמר בנושא שימוש באישור SSL בניהול Google.

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

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

המסוף

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

הערה: התהליך הבא יעביר אתכם ישירות לכרטיסייה אישורים קלאסיים. הכרטיסייה אישורים קלאסיים נמצאת בדף Certificate Manager שמקושר מדף האבטחה ברמה העליונה.

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

יוצרים את משאב האישור שמנוהל על ידי Google באמצעות השיטה sslCertificates.insert, ומחליפים את 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 הגלובליים בכרטיסייה Classic Certificates בדף 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) עם קצה עורפי של Compute Engine
• הגדרת מאזן עומסים קלאסי של אפליקציות (ALB) עם קצה עורפי של Compute Engine
• הגדרת מאזן עומסי רשת חיצוני בשרת proxy עם שרת proxy של SSL

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

המסוף

כשמעדכנים מאזן עומסים חיצוני גלובלי של אפליקציות או מאזן עומסי רשת בשרת proxy חיצוני באמצעותGoogle Cloud המסוף 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. לוחצים על Additional certificates ובוחרים את האישור בניהול 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: השם של שרת ה-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
  ]
}

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

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

‫שלב 3: אימות השיוך של שרת ה-proxy לחלוקת העומס

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

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

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

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

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 או ב-ISP.

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

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

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

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

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

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

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

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

חשוב: מומלץ לוודא שהדומיינים שלכם מפנים ישירות לכתובת ה-IP של מאזן העומסים. במאזני עומסים שמופעל בהם Cloud CDN, יכול להיות שספקי CDN מסוימים של צד שלישי ימנעו את ההצלחה של בקשות אימות. זה יכול לקרות אם ספק ה-CDN מעביר באופן פעיל תנועת HTTP(S)‎ דרך שרת proxy.

כדי לוודא שההגדרה בוצעה, מריצים את הפקודה 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 הוא תהליך אוטומטי שבודק מעת לעת את רשומות A ו-רשומת AAAA של דומיין כדי למצוא את כתובת ה-IP התואמת של מאזן עומסים Google Cloud. התהליך הזה כולל השהיה מעריכית (exponential backoff) אוטומטית לפני ניסיון חוזר, שקובעת את זמן ההמתנה בין בדיקות האימות. אם הפריסה מוכנה מראש וזמן המעבר החד למערכת אחרת (cutover) מתוכנן לחלון זמן ספציפי לתחזוקה, יום או יותר אחרי הפריסה הראשונית, מומלץ ליצור או ליצור מחדש את האישורים זמן קצר לפני חלון הזמן לתחזוקה או במהלכו, ולא להסתמך על אימות הדומיין שפועל בזמן מסוים (בגלל השהיית הטיימר).

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

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

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

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

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

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

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

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

אישורי SSL של Compute Engine תומכים רק ברשות האישורים הציבורית (pki.goog) וברשות האישורים Let's Encrypt‏ (letsencrypt.org) להנפקת אישורים בניהול Google שמהימנים באופן ציבורי. Google Cloud מספקת אישורים בניהול Google עם תקופת תוקף של 45 ימים או 90 ימים, בהתאם לרשות האישורים (CA) המנפיקה:

• אישורים שהונפקו על ידי Public Certificate Authority עוברים בהדרגה מתקופת תוקף של 90 יום לתקופת תוקף של 45 יום. אישורים קיימים ל-90 יום יישארו בתוקף למשך 90 יום עד לחידוש הבא שלהם.
• תוקף האישורים שהונפקו על ידי רשות האישורים Let's Encrypt הוא 90 יום.

Google Cloud מתחיל אוטומטית את תהליך החידוש כשנותר בערך שליש מתקופת התוקף של האישור. החידוש מתחיל כ-15 ימים לפני תאריך התפוגה של אישורים ל-45 ימים, וכ-30 ימים לפני תאריך התפוגה של אישורים ל-90 ימים.

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

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

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

letsencrypt.org מנפיקה שמות דומיינים בינלאומיים (IDN). בשלב הזה, pki.goog לא תומך בשמות דומיינים בינלאומיים (IDN).

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

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

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

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

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

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

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

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

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

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

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

   • עדכון של שרת proxy ל-HTTPS עם יעד
   • עדכון של שרת proxy יעד ל-SSL

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

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

מחיקת אישור SSL

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

• מוחקים את שרתי ה-proxy לטירגוט שמפנים לאישור הזה.

• מעדכנים את שרתי ה-proxy של היעד שמפנים לאישור הזה כדי להחריג אותו. השלבים משתנים בהתאם לשיטה:

  • עדכון של שרת proxy לחלוקת העומס מסוג HTTPS
  • עדכון של שרת proxy לחלוקת העומס של 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).