‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

יצירת מאגרי מפתחות ו-Truststores באמצעות Edge Management API

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

במאמר הזה מוסבר איך ליצור, לשנות ולמחוק מאגרי מפתחות ומאגרי אישורים ב-Edge for the Cloud וב-Edge for the Private Cloud בגרסה 4.18.01 ואילך.

הערה: בדוגמאות של ה-API שבהמשך מוגשות בקשות לכתובת ה-URL של Edge management API for the Cloud: ‏ https://api.enterprise.apigee.com. במקרים של התקנות בענן פרטי, מחליפים את כתובת ה-URL הזו בכתובת https://MS_IP:8080, כאשר MS_IP היא כתובת ה-IP של שרת הניהול.

מבוא

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

מידע על חנויות מפתחות, חנויות אישורים וכינויים זמין במאמר בנושא חנויות מפתחות וחנויות אישורים.

יצירת מאגר מפתחות

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

כדי ליצור מאגר מפתחות בסביבה:

משתמשים בקריאה ל-API שבקטע הזה כדי ליצור את מאגר המפתחות.
יוצרים כתובת אימייל רשמית ומעלים אליה זוג מפתחות/אישור. הדרך שבה מעלים את האישור ואת המפתח תלויה בפורמט של זוג האישור/המפתח. בקטעים הבאים מוסבר איך להעלות כל סוג של צמד אישורים/מפתחות:
הערה: מומלץ להשתמש בפורמט PEM למפתחות ולאישורים בכל הזדמנות. מידע נוסף זמין במאמר בנושא פורמטים נתמכים של קובצי אישורים.

כדי ליצור מאגר מפתחות, מציינים את שם מאגר המפתחות ב-API‏ Create a Keystore or Truststore. שם מאגר המפתחות יכול להכיל רק תווים אלפאנומריים:

curl -X POST -u orgAdminEmail:password -H "Content-Type: text/xml" \
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores \
-d '<KeyStore name="myKeystore"/>'

דוגמה לתשובה:

{
  "certs" : [ ],
  "keys" : [ ],
  "name" : "myKeystore"
}

העלאה של אישור ומפתח כקובץ JAR

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

/META-INF/descriptor.properties
myCert.pem
myKey.pem

קובץ JAR של חנות מפתחות יכול להכיל רק את שלושת הקבצים האלה. אם יש לכם שרשרת אישורים, צריך להוסיף את כל האישורים בשרשרת לקובץ PEM יחיד, שבו האישור האחרון צריך להיות חתום על ידי רשות אישורים (CA) בסיסית. צריך לצרף את האישורים לקובץ ה-PEM בסדר הנכון, עם שורה ריקה בין כל אישור, כלומר:

cert -> intermediate cert(1) -> intermediate cert(2) -> … -> root

בספרייה שמכילה את זוג המפתחות והאישור, יוצרים ספרייה בשם /META-INF. לאחר מכן, יוצרים קובץ בשם descriptor.properties בתיקייה /META-INF עם התוכן הבא:

certFile={myCertificate}.pem
keyFile={myKey}.pem

יוצרים את קובץ ה-JAR שמכיל את זוג המפתחות והאישור:

jar -cf myKeystore.jar myCert.pem myKey.pem

מוסיפים את descriptor.properties לקובץ ה-JAR:

jar -uf myKeystore.jar META-INF/descriptor.properties

עכשיו אפשר להעלות קובצי JAR שמכילים אישור ומפתח פרטי באמצעות ה-API‏ Create an alias from a JAR or PKCS file:

curl -u orgAdminEmail:password -X POST -H "Content-Type: multipart/form-data" -F file="@myKeystore.jar" -F password={key_pword} \
"https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases?alias={alias_name}&format=keycertjar"

האפשרות ‎-F מציינת את הנתיב לקובץ ה-JAR.

בשיחה הזו מציינים:

‫alias_name – מזהה את האישור והמפתח במאגר המפתחות. כשיוצרים מארח וירטואלי, מציינים את האישור והמפתח באמצעות שם הכינוי שלהם.
‫key_pword – הסיסמה של המפתח הפרטי. משמיטים את הפרמטר הזה אם למפתח הפרטי אין סיסמה.

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

curl -u orgAdminEmail:password -X GET\
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}

דוגמה לתשובה:

{  
 "certs" : [ "myCertificate" ],
 "keys" : [ "myKey" ],
 "name" : "myKeystore"
}

העלאת אישור ומפתח כקובצי PEM

מעלים קובצי PEM שמכילים אישור ומפתח פרטי באמצעות ה-API‏ Create an alias from certificate and key PEM files:

curl -u orgAdminEmail:password -X POST -H "Content-Type: multipart/form-data" -F keyFile="@server.key" -F certFile="@signed.crt" \
-F password={key_pword} \
"https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases?alias={alias_name}&format=keycertfile"

האפשרות -F מציינת את הנתיבים לקובצי ה-PEM.

בשיחה הזו מציינים:

‫alias_name – מזהה את האישור והמפתח במאגר המפתחות. כשיוצרים מארח וירטואלי, מציינים את האישור והמפתח באמצעות שם הכינוי שלהם.
‫key_pword – הסיסמה של המפתח הפרטי. משמיטים את הפרמטר הזה אם למפתח הפרטי אין סיסמה.

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

curl -u orgAdminEmail:password -X GET\
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}

דוגמה לתשובה:

{  
 "certs" : [ "myCertificate" ],
 "keys" : [ "myKey" ],
 "name" : "myKeystore"
}

העלאת אישור ומפתח כקובץ PKCS12/PFX

מעלים קובץ PKCS12/PFX שמכיל אישור ומפתח פרטי באמצעות ה-API‏ Create an alias from a JAR or PKCS file:

curl -u orgAdminEmail:password -X POST -H "Content-Type: multipart/form-data" \
-F file="@myKeystore.p12" -F password={key_pword} \
"https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases?alias={alias_name}&format=pkcs12"

האפשרות -F מציינת את הנתיב לקובץ P12.

בשיחה הזו מציינים:

‫alias_name – מזהה את האישור והמפתח במאגר המפתחות. כשיוצרים מארח וירטואלי, מציינים את האישור והמפתח באמצעות שם הכינוי שלהם.
‫key_pword – הסיסמה של המפתח הפרטי. משמיטים את הפרמטר הזה אם למפתח הפרטי אין סיסמה.

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

curl -u orgAdminEmail:password -X GET\
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}

דוגמה לתשובה:

{  
 "certs" : [ "myCertificate" ],
 "keys" : [ "myKey" ],
 "name" : "myKeystore"
}

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

אפשר להשתמש ב-API‏ Create an alias by generating a self-signed certificate כדי ליצור אישור ומפתח עם חתימה עצמית ולהעלות אותם לכינוי. הקריאה הבאה מציינת רק את המידע הנדרש כדי ליצור את האישור בחתימה עצמית. אפשר לשנות את הקריאה הזו כדי להוסיף מידע נוסף:

curl -u orgAdminEmail:password -X POST --header "Content-Type: application/json"  \
-d "{
    "alias": "selfsigned",
    "subject": {
        "commonName": "mycert"
    }
}" \
"https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases?format=selfsignedcert"

התגובה אמורה להופיע כך:

{
  "alias": "selfsigned",
  "certsInfo": {
    "certInfo": [
      {
        "basicConstraints": "CA:FALSE",
        "expiryDate": 1491497204000,
        "isValid": "Yes",
        "issuer": "CN=mycert",
        "publicKey": "RSA Public Key, 2048 bits",
        "serialNumber": "00:d1:b4:78:e1",
        "sigAlgName": "SHA256withRSA",
        "subject": "CN=mycert",
        "subjectAlternativeNames": [],
        "validFrom": 1459961204000,
        "version": 3
      }
    ],
    "certName": "selfsigned-cert"
  },
  "keyName": "selfsigned"
}

יצירת מאגר אישורים

ה-API שבו משתמשים כדי ליצור truststore זהה ל-API שבו משתמשים כדי ליצור keystore. ההבדל היחיד הוא שמעלים רק קובץ אישור, כקובץ PEM, למאגר האישורים.

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

אם רוצים להעלות כמה אישורים בחתימה עצמית שלא שייכים לשרשרת, משתמשים באותה שיטה: אם יש כמה אישורים שרוצים לתת להם אמון, מעלים אותם בקובץ אחד.

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

במהלך אימות TLS דו-כיווני, אימות הלקוח מצליח כשהשרת שולח את client_cert_1 ללקוח כחלק מתהליך לחיצת היד של TLS.

לחלופין, יש לכם אישור שני, client_cert_2, שחתום על ידי אותו אישור, ca_cert. עם זאת, לא מעלים את client_cert_2 אל truststore. מאגר האישורים עדיין מכיל את client_cert_1 ואת ca_cert.

כשהשרת מעביר את client_cert_2 כחלק מתהליך לחיצת היד של TLS, הבקשה מצליחה. הסיבה לכך היא ש-Edge מאפשר לאימות TLS להצליח כש-client_cert_2 לא קיים במאגר האישורים, אבל הוא נחתם על ידי אישור שקיים במאגר האישורים. אם מסירים את אישור ה-CA,‏ ca_cert, ממאגר האישורים המהימנים, אימות ה-TLS ייכשל.

יוצרים מאגר מהימן ריק בסביבה באמצעות Create a Keystore or Truststore (יצירת מאגר מפתחות או מאגר מהימן), אותו API שבו משתמשים כדי ליצור מאגר מפתחות:

curl -u orgAdminEmail:password -X POST -H "Content-Type: text/xml" \
-d '<KeyStore name="myTruststore"/>' \
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores

אחרי שיוצרים את מאגר האישורים, מעלים את האישור כקובץ PEM למאגר האישורים באמצעות ה-API Create an alias from a certificate PEM file:

curl -u orgAdminEmail:password -X POST -H "Content-Type: multipart/form-data" -F certFile="@cert.pem" \
"https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/myTruststore/aliases?alias=myTruststore&format=keycertfile"

האפשרות -F מציינת את הנתיב לקובץ ה-PEM.

קבלת פרטים על חנות מפתחות או חנות אישורים קיימת

כדי לבדוק אם יש מאגרי מפתחות קיימים בסביבה שלכם, משתמשים ב-API של List Keystores and Truststores:

curl -u orgAdminEmail:password -X GET \
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores

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

[ "freetrial" ]

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

עבור לקוחות Private Cloud, המערך שמוחזר ריק עד שיוצרים את מאגר המפתחות הראשון.

בודקים את התוכן של מאגר המפתחות באמצעות API של Get a Keystore or Truststore. לקוחות Cloud אמורים לראות אישור TLS יחיד לשרת – אישור ברירת המחדל ש-Apigee Edge מספק לחשבונות ניסיון בחינם.

curl -u orgAdminEmail:password -X GET\
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/freetrial

התגובה אמורה להופיע כך:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

איך מקבלים פרטים על כתובת אימייל חלופית

כדי לקבל רשימה של כל הכינויים של מאגרי מפתחות, משתמשים ב-API של List aliases:

curl -u orgAdminEmail:password -X GET \
"https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases"

התגובה אמורה להופיע כך:

[
  "alias1",
  "alias2",
  "alias3",
]

כדי לקבל את כל המידע על כינוי, כמו תאריך התפוגה והנפקן, משתמשים ב-API של Get alias ומציינים את שם הכינוי:

curl  -u orgAdminEmail:password -X GET \
"https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases/{alias_name}"

התגובה אמורה להופיע כך:

{
  "alias": "alias1",
  "certsInfo": {
    "certInfo": [
      {
        "basicConstraints": "CA:TRUE",
        "expiryDate": 1459371335000,
        "isValid": "No",
        "issuer": "EMAILADDRESS=foo@bar.com, CN=smg, OU=doc, O=Internet Widgits Pty Ltd, L=noho, ST=Some-State, C=AU",
        "publicKey": "RSA Public Key, 1024 bits",
        "serialNumber": "00:86:a0:9b:5b:91:a9:fe:92",
        "sigAlgName": "SHA256withRSA",
        "subject": "EMAILADDRESS=foo@bar.com, CN=smg, OU=doc, O=Internet Widgits Pty Ltd, L=noho, ST=Some-State, C=AU",
        "subjectAlternativeNames": [],
        "validFrom": 1456779335000,
        "version": 3
      }
    ],
    "certName": "new\-cert"
  },
  "keyName": "newssl20"
}

כדי להוריד את האישור של כינוי, משתמשים ב-API Export a certificate for an alias:

curl -u orgAdminEmail:password -X GET \
"https://api.enterprise.apigee.com/v1/e/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases/{alias_name}/certificate"

התגובה אמורה להופיע כך:

-----BEGIN CERTIFICATE-----
MIIDojCCAwugAwIBAgIJAIagm1uRqf6SMA0GCSqGSIb3DQEBCwUAMIGTMQswCQYD
...
RBUkaTe/570sLHY0tvkIm5tEX36ESw==
-----END CERTIFICATE-----

אם יש לכם אישור שתוקפו פג ואתם רוצים לחדש אותו, אתם יכולים להוריד בקשה לחתימת אישור (CSR). לאחר מכן שולחים את ה-CSR לרשות האישורים כדי לקבל אישור חדש. כדי ליצור CSR עבור כינוי, משתמשים ב-API‏ Generate a CSR for an alias:

curl -u orgAdminEmail:password -X GET \
"https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/{keystore_name}/aliases/{alias_name}/csr"

התגובה אמורה להופיע כך:

-----BEGIN CERTIFICATE REQUEST-----
MIIB1DCCAT0CAQAwgZMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpTb21lLVN0YXRl
...
RF5RMytbkxkvPxIE17mDKJH0d8aekv/iEOItZ+BtQg+EibMUkkjTzQ==
-----END CERTIFICATE REQUEST-----

הוספת אישור למאגר אישורים לצורך TLS דו-כיווני

כשמשתמשים ב-TLS דו-כיווני לחיבורים נכנסים, כלומר לבקשת API ל-Edge, מאגר האישורים מכיל אישור או שרשרת CA לכל לקוח שמורשה לשלוח בקשות ל-Edge.

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

כדי להוסיף אישורים חדשים למאגר אישורים שמשמש ל-TLS דו-כיווני:

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

מידע נוסף זמין במאמר בנושא שינוי הפניה.

מחיקה של מאגר מפתחות/מאגר אישורים או כינוי

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

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

יוצרים מאגר מפתחות/מאגר אישורים או כינוי חדשים כמו שמתואר למעלה.
במקרה של חיבורים נכנסים, כלומר בקשת API ל-Edge, צריך לעדכן את ההגדרה של המארח הווירטואלי כדי להפנות אל מאגר המפתחות החדש ואל הכינוי של המפתח.
לחיבורים יוצאים, כלומר מ-Apigee לשרת backend:
1. מעדכנים את ההגדרה של TargetEndpoint לכל פרוקסי ה-API שהתייחסו למאגר המפתחות הישן ולכינוי המפתח, כך שיתייחסו למאגר המפתחות החדש ולכינוי המפתח החדש. אם TargetEndpoint מפנה אל TargetServer, צריך לעדכן את ההגדרה של TargetServer כך שתפנה אל מאגר המפתחות החדש ואל הכינוי של המפתח.
2. אם יש הפניה ישירה אל keystore ו-truststore מההגדרה של TargetEndpoint, צריך לפרוס מחדש את ה-proxy. אם TargetEndpoint מפנה להגדרה של TargetServer, וההגדרה של TargetServer מפנה ל-keystore ול-truststore, לא צריך לפרוס מחדש את ה-proxy.
3. מוודאים ששרתי ה-proxy של ה-API פועלים בצורה תקינה.
4. מוחקים את מאגר המפתחות, מאגר האישורים או הכינוי.

מידע נוסף זמין במאמר עדכון האישור בכינוי.

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

אפשר למחוק מאגר מפתחות או מאגר אישורים באמצעות ה-API‏ Delete a Keystore or Truststore:

curl -u orgAdminEmail:password -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/myKeystoreName

אם מוחקים ויוצרים מחדש מאגר מפתחות או מאגר אישורים שמשמשים מארח וירטואלי, צריך לפרוס מחדש את שרתי ה-proxy של ה-API.

מחיקת כינוי

אפשר למחוק כינוי במאגר מפתחות או במאגר אישורים באמצעות ה-API‏ Delete alias:

curl -u orgAdminEmail:password -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/keystores/myKeystoreName/aliases/{alias_name}