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

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

אישורים בניהול עצמי יכולים להיות כל שילוב של סוגי האישורים הבאים:

• אימות דומיין (DV)
• אימות הארגון (OV)
• אימות מורחב (EV)

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

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

בדף הזה מתואר התהליך של קבלת אישור תקף של Compute Engine, ואז העלאת האישור כדי ליצור משאב של אישור SSL. Cloud de Confiance

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

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

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

הרשאות

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

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

שלב 1: יצירת מפתח פרטי ותעודה

אם כבר יש לכם מפתח פרטי ואישור מרשות אישורים (CA), אפשר לדלג על הקטע הזה ולעבור אל יצירת משאב של אישור SSL.

בחירה או יצירה של מפתח פרטי

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

• הקובץ צריך להיות בפורמט PEM.
• אי אפשר להגן עליו באמצעות ביטוי גישה. Cloud de Confiance שומר את המפתח הפרטי בפורמט מוצפן משלו.
• אלגוריתם ההצפנה שלו חייב להיות RSA או ECDSA. כדי לדעת באילו סוגי מפתחות אפשר להשתמש, אפשר לעיין במאמר בנושא סוגי מפתחות נתמכים.

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

• יוצרים מפתח פרטי RSA-2048:

  openssl genrsa -out PRIVATE_KEY_FILE 2048
  

• יוצרים מפתח פרטי מסוג ECDSA P-256:

  openssl ecparam -name prime256v1 -genkey -noout -out PRIVATE_KEY_FILE
  

מחליפים את PRIVATE_KEY_FILE בנתיב ובשם הקובץ של המפתח הפרטי החדש.

יצירת בקשת חתימה על אישור (CSR)

אחרי שיש לכם מפתח פרטי, אתם יכולים ליצור בקשה לחתימת אישור (CSR) בפורמט PEM באמצעות OpenSSL. בקשת החתימה (CSR) צריכה לעמוד בקריטריונים הבאים:

• הקובץ צריך להיות בפורמט PEM.
• חייב להיות לו שם נפוץ (CN) או מאפיין של שם חלופי של בעלים (subject) (SAN). מבחינה מעשית, התעודה צריכה להכיל גם את המאפיין CN וגם את המאפיין SAN, גם אם היא מיועדת לדומיין יחיד. לקוחות מודרניים, כמו הגרסאות הנוכחיות של macOS ו-iOS, לא מסתמכים רק על המאפיין CN.

כדי ליצור CSR, פועלים לפי השלבים הבאים:

1. יוצרים קובץ תצורה של OpenSSL. בדוגמה הבאה, השמות החלופיים לנושא מוגדרים ב-[sans_list].

   cat <<'EOF' >CONFIG_FILE
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   
   [extension_requirements]
   basicConstraints          = CA:FALSE
   keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
   subjectAltName            = @sans_list
   
   [dn_requirements]
   countryName               = Country Name (2 letter code)
   stateOrProvinceName       = State or Province Name (full name)
   localityName              = Locality Name (eg, city)
   0.organizationName        = Organization Name (eg, company)
   organizationalUnitName    = Organizational Unit Name (eg, section)
   commonName                = Common Name (e.g. server FQDN or YOUR name)
   emailAddress              = Email Address
   
   [sans_list]
   DNS.1                     = SUBJECT_ALTERNATIVE_NAME_1
   DNS.2                     = SUBJECT_ALTERNATIVE_NAME_2
   
   EOF
   

2. מריצים את פקודת OpenSSL הבאה כדי ליצור קובץ של בקשת חתימה על אישור (CSR). הפקודה היא אינטראקטיבית. תתבקשו להזין מאפיינים חוץ מהשמות החלופיים של הנושא, שהגדרתם ב-[sans_list] של CONFIG_FILE בשלב הקודם.

   openssl req -new -key PRIVATE_KEY_FILE \
       -out CSR_FILE \
       -config CONFIG_FILE
   

בשני השלבים, מחליפים את הערכים הבאים:

• ‫CONFIG_FILE: הנתיב, כולל שם הקובץ, לקובץ ההגדרות של OpenSSL (אפשר למחוק את הקובץ אחרי שמסיימים את התהליך הזה)

• ‫SUBJECT_ALTERNATIVE_NAME_1 ו-SUBJECT_ALTERNATIVE_NAME_2: שמות חלופיים של נושא האישור

  אם האישור שלכם הוא רק לשם מארח אחד, צריך להגדיר רק שם חלופי של בעלים (subject) אחד שזהה לשם הנפוץ. אם אתם צריכים יותר משני שמות חלופיים לנושא, מוסיפים אותם לקובץ ההגדרות ומגדילים את המספר אחרי DNS (DNS.3,‏ DNS.4 וכו').

• ‫PRIVATE_KEY_FILE: הנתיב לקובץ המפתח הפרטי

• ‫CSR_FILE: הנתיב, כולל שם הקובץ, של ה-CSR

חתימה על ה-CSR

כשסמכות אישורים (CA) חותמת על ה-CSR שלכם, היא משתמשת במפתח הפרטי שלה כדי ליצור אישור. משתמשים באחת מהשיטות הבאות כדי לחתום על ה-CSR:

שימוש ב-CA מהימן באופן ציבורי

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

שימוש ב-CA פנימי משלכם

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

שימוש באישור עם חתימה עצמית

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

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

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

openssl x509 -req \
    -signkey PRIVATE_KEY_FILE \
    -in CSR_FILE \
    -out CERTIFICATE_FILE \
    -extfile CONFIG_FILE \
    -extensions extension_requirements \
    -days TERM

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

• ‫PRIVATE_KEY_FILE: הנתיב למפתח הפרטי של רשות האישורים. אם יוצרים אישור עם חתימה עצמית לצורך בדיקה, המפתח הפרטי הזה זהה למפתח שמשמש ליצירת בקשת חתימה על אישור (CSR).
• ‫CSR_FILE: הנתיב ל-CSR
• ‫CERTIFICATE_FILE: הנתיב לקובץ האישור שרוצים ליצור
• ‫TERM: מספר הימים מעכשיו שבהם הלקוחות שמאמתים את האישור צריכים להתייחס אליו כאל אישור תקף

תווים כלליים בשמות נפוצים

באפשרותכם להשתמש בתו כללי בשם הנפוץ של אישורי ה-SSL שמנוהלים באופן עצמאי. לדוגמה, אישור עם השם הנפוץ *.example.com. תואם לשמות המארחים www.example.com ו-foo.example.com, אבל לא ל-a.b.example.com או ל-example.com. כשמאזן העומסים בוחר אישור, הוא תמיד מעדיף להתאים שם מארח לאישורים ללא תווים כלליים על פני אישורים עם תווים כלליים.

אין תמיכה באישורים עם מקטעי תו כללי לחיפוש, כמו f*.example.com.

שלב 2: יצירת משאב של אישור SSL בניהול עצמי

כדי ליצור Cloud de Confiance משאב של אישור SSL, צריך שיהיו לכם מפתח פרטי ואישור. אם עדיין לא יצרתם או קיבלתם מפתח פרטי ותעודה, תוכלו לעיין במאמר בנושא יצירת מפתח פרטי ותעודה.

אחרי שיוצרים אישור, אי אפשר לשנות את ההיקף שלו מגלובלי לאזורי או מאזורי לגלובלי.

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --certificate=CERTIFICATE_FILE \
    --private-key=PRIVATE_KEY_FILE \
    --region=REGION

import com.google.cloud.compute.v1.InsertRegionSslCertificateRequest;
import com.google.cloud.compute.v1.RegionSslCertificatesClient;
import com.google.cloud.compute.v1.SslCertificate;
import java.io.IOException;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;

public class CreateRegionalCertificate {
  public static void main(String[] args)
          throws IOException, InterruptedException, ExecutionException, TimeoutException {
    // TODO(developer): Replace these variables before running the sample.
    // Project ID or project number of the Google Cloud project you want to use.
    String project = "your-project-id";
    // The certificate you want to create in your project.
    String certificate = "your-certificate";
    // The private key you used to sign the certificate with.
    String privateKey = "your-private-key";
    // Name for the certificate once it's created in your project.
    String certificateName = "your-certificate-name";
    // Name of the region you want to use.
    String region = "your-region";

    createRegionCertificate(project, certificate, region, privateKey, certificateName);
  }

  // Create a regional SSL self-signed certificate within your Google Cloud project.
  public static SslCertificate createRegionCertificate(String project, String certificate,
                                                       String region, String privateKey,
                                                       String certificateName)
          throws IOException, ExecutionException, InterruptedException, TimeoutException {
    // Initialize client that will be used to send requests. This client only needs to be created
    // once, and can be reused for multiple requests.
    try (RegionSslCertificatesClient client = RegionSslCertificatesClient.create()) {
      SslCertificate certificateResource = SslCertificate.newBuilder()
              .setCertificate(certificate)
              .setPrivateKey(privateKey)
              .setName(certificateName)
              .build();

      InsertRegionSslCertificateRequest request = InsertRegionSslCertificateRequest.newBuilder()
              .setProject(project)
              .setRegion(region)
              .setSslCertificateResource(certificateResource)
              .build();

      client.insertCallable().futureCall(request).get(60, TimeUnit.SECONDS);

      // Wait for server update
      TimeUnit.SECONDS.sleep(1);

      SslCertificate sslCert = client.get(project, region, certificateName);

      System.out.printf("Regional cert '%s' has been created successfully", sslCert.getName());

      return sslCert;
    }
  }
}

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_regional_certificate(
    project_id: str,
    region: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a regional SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

        Returns:
        Dictionary with information about the new regional SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.regionSslCertificates().insert(
        project=project_id, region=region, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)

    return response

שלב 3: משייכים אישור SSL לשרת proxy של יעד

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

gcloud compute target-https-proxies update TARGET_PROXY_NAME \
    --region=REGION \
    --ssl-certificates=SSL_CERTIFICATE_LIST \
    --ssl-certificates-region=REGION

POST https://compute.s3nsapis.fr/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-xlb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"region": "us-west1"
"sslCertificates": /projectsPROJECT_IDregions/us-west1/sslCertificates/SSL_CERT_NAME
}

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

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

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

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

אחרי שמחכים שהפצת ה-DNS תושלם, אפשר לאמת את ההגדרה באמצעות הפעלת הפקודה 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   www.example.com.edgekey.net.
www.example.com.edgekey.net. 21330 IN   CNAME   www.example.com.edgekey.net.globalredir.akadns.net.
www.example.com.edgekey.net.globalredir.akadns.net. 3356 IN CNAME   e6858.dsce9.akamaiedge.net.
e6858.dsce9.akamaiedge.net. 19  IN  A   203.0.113.5

;; 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

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

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

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

כדי לבדוק, מריצים את פקודת 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 בניהול עצמי

בקטעים הבאים מוסבר איך לרשום, לראות, למחוק ולהחליף משאבי אישורים מסוג SSL.

הצגת רשימת אישורי SSL

gcloud compute ssl-certificates list \
   --filter="region:(REGION ...)"

תיאור של אישורי SSL

gcloud compute ssl-certificates describe CERTIFICATE_NAME \
   --region=REGION

מחיקת אישורי SSL

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

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

gcloud compute ssl-certificates delete CERTIFICATE_NAME \
    --region=REGION

החלפה או חידוש של אישור SSL לפני שתוקפו פג

אם צריך להחליף, לחדש או להחליף אישור SSL:

1. מריצים את הפקודה gcloud compute ssl-certificates describe עבור האישור הנוכחי כדי לבדוק אם תוקף האישור עומד לפוג.

2. יוצרים משאב חדש של אישור SSL. לכל אישור SSL חדש צריך להיות שם ייחודי בפרויקט.

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

   כדי למנוע השבתה, מריצים פקודה אחת של gcloud עם הדגל --ssl-certificates. לדוגמה:

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

   משתמשים בפקודה gcloud compute target-https-proxies update עם הדגל --region.

   gcloud compute target-https-proxies update TARGET_PROXY_NAME \
      --region=REGION \
      --ssl-certificates=new-ssl-cert,other-certificates \
      --ssl-certificates-region=REGION
   

4. מריצים את פקודת OpenSSL הבאה כדי לוודא שמאזן העומסים מציג את אישור ההחלפה:

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

5. ממתינים 15 דקות כדי לוודא שפעולת ההחלפה הועברה לכל ממשקי הקצה של Google‏ (GFE).

6. (אופציונלי) מחיקת אישור ה-SSL הישן.

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

• כדי לפתור בעיות שקשורות לאישורי SSL, אפשר לעיין במאמר פתרון בעיות שקשורות לאישורי SSL.