מוצג המסמך של Apigee Edge.
עוברים אל
מסמכי תיעוד של Apigee X. מידע
במסמך הזה מוסבר איך ליצור, לשנות ולמחוק מאגרי מפתחות ומאגרי אמון ב-Edge ל-Private Cloud בגרסה 4.17.09 ובגרסאות קודמות.
מידע על מאגרי מפתחות ועל מאגרי אמון
ב-Keystores וב-Truststores מוגדרים מאגרים של אישורי אבטחה שמשמשים ל-TLS. הצפנה. ההבדל העיקרי בין שתי הפלטפורמות הוא המקום שבו משתמשים בהן ללחיצת יד בפרוטוקול TLS תהליך:
- מאגר מפתחות מכיל אישור TLS ומפתח פרטי המשמשים לזיהוי
במהלך לחיצת היד בפרוטוקול TLS.
ב-TLS חד-כיווני, כשלקוח מתחבר לנקודת הקצה של TLS בשרת, מאגר המפתחות של השרת מציג ללקוח את אישור השרת (אישור ציבורי). לאחר מכן הלקוח מוודא אישור מטעם רשות אישורים (CA), כמו Symantec או VeriSign.
ב-TLS דו-כיווני, הלקוח וגם השרת מחזיקים מאגר מפתחות עם אישור משלהם מפתח פרטי המשמש לאימות הדדי. - truststore מכילה אישורים שמשמשים לאימות אישורים שהתקבלו בתור
חלק מלחיצת היד בפרוטוקול TLS.
ב-TLS חד-כיווני, אין צורך ב-Truststore אם האישור חתום על ידי CA תקין. אם אישור שהתקבל על ידי לקוח TLS חתום על ידי CA חוקי, ואז הלקוח שולח בקשה ל-CA כדי לאמת את האישור. לקוח TLS משתמש בדרך כלל ב-Truststore כדי לאמת אישורים בחתימה עצמית שהתקבלו משרת ה-TLS, או אישורים שאינם חתומים על ידי רשות אישורים מהימנה. בתרחיש הזה, הלקוח מאכלס את מאגר האמון שלו באישורים שהוא מהימנים. לאחר מכן, כשהלקוח מקבל אישור שרת, האישור הנכנס מאומת מול האישורים במאגר האמון שלו.
לדוגמה, לקוח TLS מתחבר לשרת TLS שבו השרת משתמש בחתימה עצמית. אישור. מאחר שזהו אישור בחתימה עצמית, הלקוח לא יכול לאמת אותו באמצעות CA. במקום זאת, הלקוח טוען מראש את האישור עם החתימה העצמית של השרת למאגר האמון שלו. לאחר מכן: כשהלקוח מנסה להתחבר לשרת, הוא משתמש במאגר האמון שלו כדי לאמת את האישור שהתקבל מהשרת.
ב-TLS דו-כיווני, גם לקוח ה-TLS וגם שרת ה-TLS יכולים להשתמש ב-Truststore. מאגר אמון נדרשת כשמבצעים TLS דו-כיווני כש-Edge פועל כשרת ה-TLS.
אישורים יכולים להיות מונפקים על ידי רשות אישורים (CA), או שאפשר לחתום אותם באופן עצמאי על ידי המפתח הפרטי שיוצרים, אם יש לך גישה ל-CA, עליך לפעול לפי ההוראות שסופקו על ידי רשות אישורים ליצירת מפתחות ולהנפקת אישורים. אם אין לך גישה ל-CA, אפשר ליצור אישור בחתימה עצמית באמצעות אחד מהכלים הרבים שקיימים בחינם, כמו openssl.
ההטמעה של Keystore ו-Truststore ב-Edge
ב-Edge, מאגר מפתחות מכיל קובץ JAR אחד או יותר, שבו קובץ ה-JAR מכיל:
- אישור TLS כקובץ PEM – אישור חתום על ידי רשות אישורים (CA), שרשרת אישורים שבה האישור האחרון חתום על ידי CA או חתימה עצמית אישור.
- מפתח פרטי כקובץ PEM. Edge תומך בגדלים של עד 2,048 ביט. ביטוי סיסמה הוא אופציונלי.
מאגר אמון דומה למאגר מפתחות, אבל הוא מכיל רק אישורים כקובץ PEM, למפתחות פרטיים.
אם האישור הוא חלק משרשרת, מאגר המפתחות/חנות המפתחות צריכים להכיל את כל האישורים כקובצי PEM בודדים או כקובץ יחיד. אם משתמשים בקובץ יחיד, האישורים צריכים להיות בסדר שבו האישור הראשון בקובץ הוא האישור שמשמש ל-TLS ואחריו לפי שרשרת האישורים, לפי הסדר של אישור ה-CA. עליך להזין שורה ריקה בין לכל אישור בקובץ.
Edge מספק API שבו משתמשים כדי ליצור מאגרי מפתחות ומאגרים של אמון. ממשקי ה-API עצמם זהה. ההבדל הוא שכאשר יוצרים מאגר מפתחות, מעבירים קובץ JAR שמכיל את אישור ומפתח פרטי. כשיוצרים מאגר אמון, מעבירים רק את האישור כקובץ PEM.
מידע על הפורמט של קובצי אישורים ומפתחות
בדוגמאות שבמסמך הזה מוצגים אישור ה-TLS והמפתח שמוגדרים כקובצי PEM, שעומדים בדרישות בפורמט X.509. אם האישור או המפתח הפרטי שלך לא מוגדרים באמצעות קובץ PEM, אפשר להמיר לקובץ PEM באמצעות תוכניות שירות כמו opensl.
עם זאת, חלק גדול מקובצי ה- .crt וקובצי ה- .key כבר בפורמט PEM. אם הקבצים האלה הם טקסט קבצים, והם מוקפים ב:
-----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
או:
-----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY-----
הקבצים תואמים לפורמט PEM ואפשר להשתמש בהם במאגר מפתחות או ל-Truststore בלי להמיר אותם לקובץ PEM.
אם יש לך שרשרת אישורים ואתם רוצים להשתמש בה במאגר מפתחות או במאגר אמון, אפשר לשלב את כל האישורים לקובץ PEM אחד עם שורה חדשה בין כל אישור. האישורים צריכים להיות בסדר, והאישור האחרון חייב להיות אישור בסיס או אישור ביניים חתומה על ידי אישור בסיס:
-----BEGIN CERTIFICATE----- (Your Primary TLS certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Intermediate certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Root certificate or intermediate certificate signed by a root certificate) -----END CERTIFICATE-----
קבלת פרטים על מאגר מפתחות קיים
כדי לבדוק אם יש מאגרי מפתחות קיימים בסביבה, משתמשים ב-List Keystores ו-Truststores:
curl -X GET \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password
ללקוחות בענן, מאגר מפתחות ברירת המחדל מסופק לארגונים עם תקופת ניסיון בחינם בסביבות של בדיקה וייצור. התוצאות הבאות אמורות להופיע בשיחה הזו בסביבות:
[ "freetrial" ]
אפשר להשתמש במאגר המפתחות הזה שמוגדר כברירת מחדל כדי לבדוק את ממשקי ה-API ולהעביר את ממשקי ה-API לסביבת הייצור, אבל בדרך כלל יוצר מאגר מפתחות משלכם, עם אישור ומפתח משלכם, לפני הפריסה לסביבת הייצור.
ללקוחות Private Cloud, המערך שהוחזר ריק עד שתיצרו את מאגר מפתחות.
בודקים את התוכן של מאגר המפתחות באמצעות קבלת ממשקי API של Keystore או Truststore. ללקוחות של Cloud אתם אמורים לראות שרת TLS יחיד אישור – אישור ברירת המחדל ש-Apigee Edge מספק לחשבונות לתקופת ניסיון בחינם.
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password
התגובה אמורה להיראות כך:
{
"certs" : [ "wildcard.apigee.net.crt" ],
"keys" : [ "freetrial" ],
"name" : "freetrial"
}
אפשר להציג את המידע הזה גם בממשק המשתמש של Edge management:
- מתחברים לממשק המשתמש של ניהול Edge בכתובת https://enterprise.apigee.com (בענן) או ב-
http://<ms-ip>:9000(בארגון), כאשר<ms-ip>הוא כתובת ה-IP של צומת שרת הניהול. - בתפריט Edge management UI, בוחרים באפשרות Admin > (אדמין >) אישורי TLS.
קבלת פרטי אישור TLS
אפשר להשתמש ב קבלת פרטי אישור מ-Keystore או Truststore API כדי לצפות בפרטים על אישורי TLS ב- מאגר המפתחות, כמו תאריך התפוגה והמנפיק. קודם כול, משיגים את שם האישור שמעניין אותך. הדוגמה הזו מאחזרת מידע לגבי מאגר המפתחות שנקרא 'freetrial'.
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password
דוגמה לתגובה:
{
"certs" : [ "wildcard.apigee.net.crt" ],
"keys" : [ "freetrial" ],
"name" : "freetrial"
}
אחר כך משתמשים בערך של מאפיין האישורים כדי לקבל את פרטי האישור:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial/certs/wildcard.apigee.net.crt \
-u email:password
דוגמה לתגובה:
{
"certInfo" : [ {
"expiryDate" : "Wed, 23 Apr 2014 20:50:02 UTC",
"isValid" : "Yes",
"issuer" : "CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US",
"subject" : CN=*.example.apigee.net, OU=Domain Control Validated",
"subjectAlternativeNames" : ["*.example.apigee.net","*.example.apigee.net" ],
"validFrom" : "Tue, 15 Apr 2014 09:17:03 UTC",
"version" : 3
} ],
"name" : "example.apigee.net.crt"
}
אפשר להציג את המידע הזה גם בממשק המשתמש של Edge management:
- מתחברים לממשק המשתמש של ניהול Edge בכתובת https://enterprise.apigee.com (ענן)
או
http://<ms-ip>:9000(באופן מקומי), כאשר<ms-ip>הוא כתובת ה-IP של צומת שרת הניהול. - בתפריט Edge management UI, בוחרים באפשרות Admin > (אדמין >) TLS אישורים.
בממשק המשתמש של Edge, אפשר לציין כמה זמן מראש יופיע האישור ב-Edge עד תאריך התפוגה. כברירת מחדל, בממשק המשתמש מדגישים כל האישורים שתוזמנו לפוג ב-10 הימים הבאים ימים.
יצירת מאגר מפתחות
מאגר מפתחות הוא ספציפי לסביבה בארגון. לדוגמה, הבדיקה או הייצור הסביבה. לכן, אם רוצים לבדוק את מאגר המפתחות בסביבת בדיקה לפני פריסה בסביבת הייצור שלכם, עליכם ליצור אותו בשתי הסביבות.
יצירת מאגר מפתחות היא תהליך דו-שלבי:
- יצירת קובץ JAR שמכיל את האישור והמפתח הפרטי שלך.
- יוצרים את מאגר המפתחות ומעלים את קובץ ה-JAR.
יצירת קובץ JAR שמכיל את האישור והמפתח הפרטי שלך
עליך ליצור קובץ JAR עם המפתח הפרטי, האישור ומניפסט. על קובץ ה-JAR מכילים את הקבצים והספריות הבאים:
/META-INF/descriptor.properties myCert.pem myKey.pem
בספרייה שמכילה את זוג המפתחות והאישור, יוצרים ספרייה שנקראת
/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 של Keystore או Truststore. השם יכול להכיל רק תווים אלפאנומריים:
curl -X POST -H "Content-Type: text/xml" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-d '<KeyStore name="myKeystore"/>' -u email:password
דוגמה לתגובה:
{
"certs" : [ ],
"keys" : [ ],
"name" : "myKeystore"
}
אחרי שיוצרים מאגר מפתחות בעל שם בסביבה, אפשר להעלות את קובצי ה-JAR מכילים אישור ומפתח פרטי באמצעות הפקודה העלאת קובץ JAR ל-Keystore API:
curl -X POST -H "Content-Type: multipart/form-data" \
-F file="@myKeystore.jar" -F password={key_pass} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/{myKeystore}/keys?alias={key_alias}" \
-u email:password
שבהן האפשרות -F מציינת
את הנתיב לקובץ ה-JAR.
בשיחה הזו אתם מציינים שני פרמטרים של שאילתה:
alias– מזהה את את האישור והמפתח במאגר המפתחות. כשיוצרים מארח וירטואלי, מפנים אל של האישור והמפתח באמצעות השם החלופי שלו.password- הסיסמה עבור המפתח הפרטי. יש להשמיט את הפרמטר הזה אם למפתח הפרטי אין סיסמה.
מוודאים שמאגר המפתחות הועלה כראוי:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystore \
-u email:password
דוגמה לתגובה:
{
"certs" : [ "myCertificate" ],
"keys" : [ "myKey" ],
"name" : "myKeystore"
}
יצירת מאגר אמון
ממשקי ה-API שבהם משתמשים כדי ליצור מאגר אמון זהים לממשקי ה-API שבהם משתמשים כדי ליצור מאגר מפתחות. ההבדל היחיד הוא שמעבירים את קובץ האישור כקובץ PEM במקום כקובץ JAR.
אם האישור הוא חלק משרשרת, צריך להעלות את כל האישורים בשרשרת בנפרד
ל-Truststore או ליצור קובץ יחיד שמכיל את כל האישורים, לכלול שורה חדשה בין
לכל אישור בקובץ. האישור הסופי חתום בדרך כלל על ידי מנפיק האישור. עבור
לדוגמה: ב-Truststore מעלים אישור לקוח, client_cert_1 ואת אישור הלקוח.
אישור של המנפיק, 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 -X POST -H "Content-Type: text/xml" -d \
'<KeyStore name="myTruststore"/>' \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password
מעלים את האישור כקובץ PEM ל-Truststore באמצעות העלאת אישור ל-Truststore API:
curl -X POST -H "Content-Type: multipart/form-data" -F file="@trust.pem" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myTruststore/certs?alias=myTruststore \
-u email:password
שבהן האפשרות -F מציינת
את הנתיב לקובץ ה-PEM.
מחיקה של מאגר מפתחות או מאגר אמון
אפשר למחוק מאגר מפתחות או מאגר אמון באמצעות מחיקת Keystore או Truststore API:
curl -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystoreName \
-u email:password
דוגמה לתגובה:
{
"certs" : [ ],
"keys" : [ ],
"name" : "myKeystoreName"
}
אם מוחקים מאגר מפתחות או מאגר אמון שנמצאים בשימוש של יעד או מארח וירטואלי נקודת קצה/יעד/שרת, כל הקריאות ל-API דרך המארח הווירטואלי או שרת היעד/שרת היעד תיכשל.