דף זה תורגם על ידי Cloud Translation API.

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

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

במסמך הזה מוסבר איך ליצור, לשנות ולמחוק מאגרי מפתחות ומאגרי אמון ב-Edge ל-Cloud ול-Edge בגרסה 4.18.01 ואילך של ענן פרטי.

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

מבוא

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

להיכרות עם מאגרי מפתחות, Truststore וכינויים, אפשר לעיין במאמר בנושא Keystores ו-Truststores

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

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

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

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

כדי ליצור מאגר מפתחות, צריך לציין את השם של מאגר המפתחות בשדה יצירת מאגר מפתחות API של Keystore או 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 אחד, שבו צריך לחתום את האישור האחרון על ידי רשות אישורים ברמה הבסיסית. צריך לצרף את האישורים לקובץ ה-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 שמכילים אישור ומפתח פרטי באמצעות יוצרים כתובת אימייל חלופית מקובץ JAR או PKCS:

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 שמכילים אישור ומפתח פרטי באמצעות יוצרים כתובת אימייל חלופית מקובצי PEM של אישורים ומפתחות PEM:

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 שמכיל אישור ומפתח פרטי באמצעות יוצרים כתובת אימייל חלופית מקובץ JAR או PKCS:

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 כדי ליצור אישור בחתימה עצמית ומעלים אותם לכתובת אימייל חלופית. הקריאה הבאה מציינת רק את המידע הנדרש כדי: יצירת האישור עם החתימה העצמית. אפשר לשנות את השיחה כדי להוסיף פרטים נוספים:

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 שבהם משתמשים כדי ליצור מאגר אמון זהים לממשקי ה-API שבהם משתמשים כדי ליצור מאגר מפתחות. ההבדל היחיד הוא שמעלים רק קובץ אישור, כקובץ PEM, ל-Truststore.

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

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

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

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

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

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

כדי ליצור מאגר אמון ריק בסביבה באמצעות Create a Keystore או 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

אחרי שיוצרים את ה-Truststore, מעלים את האישור כקובץ PEM ל-Truststore על ידי באמצעות יוצרים כתובת אימייל חלופית מקובץ PEM של אישור:

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.

קבלת פרטים על נכס קיים מאגר מפתחות או Truststore

כדי לבדוק אם יש מאגרי מפתחות קיימים בסביבה, משתמשים ב-List Keystores ו-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 של Keystore או 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"
}

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

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

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 החלופי וציון השם החלופי:

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 חלופי:

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

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

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

הוספת אישור ל-Truststore עבור TLS דו-כיווני

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

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

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

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

מידע נוסף זמין במאמר שינוי קובץ עזר.

מחיקה של מאגר מפתחות, מאגר אמון או כתובת אימייל חלופית

צריך להיזהר כשמוחקים מאגר מפתחות/מאגר אמון או כינוי. אם מוחקים מאגר מפתחות, Truststore או כינוי שמשמש מארח וירטואלי, נקודת קצה (endpoint) או שרת יעד – הכול קריאות ל-API דרך המארח הווירטואלי או דרך נקודת הקצה/שרת היעד ייכשלו.

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

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

ראו למידע נוסף, אפשר לעדכן את האישור בכתובת אימייל חלופית.

מחיקה של מאגר מפתחות או מאגר אמון

אפשר למחוק מאגר מפתחות או מאגר אמון באמצעות מחיקת Keystore או Truststore API:

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

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

מחיקת כינוי

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

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