יצירת מאגרי מפתחות ו-Truststore באמצעות ממשק המשתמש של Edge

מוצג התיעוד של Apigee Edge.
נכנסים למסמכי התיעוד של Apigee X. מידע

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

מידע על מאגרי מפתחות/מאגרי אמינות ומארחים וירטואליים של Edge Cloud

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

• מארחים וירטואליים חייבים להשתמש ב-TLS (אבטחת שכבת התעבורה).
• מארחים וירטואליים יכולים להשתמש רק ביציאה 443.
• יש להשתמש באישור TLS חתום. אי אפשר להשתמש באישורים לא חתומים במארחים וירטואליים בענן.
• שם הדומיין שצוין באישור ה-TLS חייב להתאים לכינוי המארח של המארח הווירטואלי.

מידע נוסף:

• מידע על TLS/SSL
• שימוש ב-TLS עם Edge
• שאלות נפוצות על הגדרת מארחים וירטואליים
• מידע על מארחים וירטואליים

הטמעה של מאגרי מפתחות ומאגרי אמינות ב-Edge

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

ב-Edge, מאגרי מפתחות ו-Truststores מיוצגים על ידי ישות של keystore שמכילה כינוי אחד או יותר. כלומר, אין הבדל בהטמעה בין מאגר מפתחות לבין Truststore ב-Edge.

ההבדל בין מאגרי מפתחות ל-Truststore נגזר מסוגי הרשומות שהם מכילים והאופן שבו נעשה בהם שימוש בלחיצת יד של TLS:

• מאגר מפתחות – ישות במאגר מפתחות שמכילה כתובת אימייל חלופית אחת או יותר, שבה כל כינוי מכיל צמד אישור/מפתח.
• Truststore – ישות keystore שמכילה כתובת אימייל חלופית אחת או יותר, שבה כל כינוי מכיל רק אישור.

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

<VirtualHost name="myTLSVHost"> 
    <HostAliases> 
        <HostAlias>apiTLS.myCompany.com</HostAlias> 
    </HostAliases> 
    <Interfaces/> 
    <Port>9006</Port> 
    <SSLInfo> 
        <Enabled>true</Enabled> 
        <ClientAuthEnabled>false</ClientAuthEnabled> 
        <KeyStore>ref://keystoreref</KeyStore> 
        <KeyAlias>myKeyAlias</KeyAlias> 
    </SSLInfo>
</VirtualHost>

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

אם נדרש Truststore, לדוגמה להגדרת TLS דו-כיווני, צריך להשתמש בתג <TrustStore> כדי לציין את ה-Truststore:

<VirtualHost name="myTLSVHost"> 
    <HostAliases> 
        <HostAlias>apiTLS.myCompany.com</HostAlias> 
    </HostAliases> 
    <Interfaces/> 
    <Port>9006</Port> 
    <SSLInfo> 
        <Enabled>true</Enabled> 
        <ClientAuthEnabled>true</ClientAuthEnabled> 
        <KeyStore>ref://keystoreref</KeyStore> 
        <KeyAlias>myKeyAlias</KeyAlias> 
        <TrustStore>ref://truststoreref</TrustStore>
    </SSLInfo>
</VirtualHost>

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

פורמטים נתמכים של אישורים

מבנה הקורס	תמיכה בהעלאה באמצעות API וממשק משתמש	תמיכה לכיוון צפון	מאומת
PEM	כן	כן	כן
* PKCS12	כן	כן	כן הערה: Apigee ממירה באופן פנימי את PKCS12 ל-PEM.
* דרכם	לא	לא	כן
* PKCS7	לא	לא	לא

* מומלץ להשתמש ב-PEM אם אפשר.

מידע על הטמעת כתובת אימייל חלופית

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

• אישור TLS כקובץ PEM או PKCS12/PFX – אישור שחתום על ידי רשות אישורים (CA), קובץ שמכיל שרשרת של אישורים שבה האישור האחרון חתום על ידי רשות אישורים, או אישור בחתימה עצמית.
• מפתח פרטי כקובץ PEM או PKCS12/PFX. Edge תומך בגדלי מקשים של עד 2048 ביטים. ביטוי סיסמה הוא אופציונלי.

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

• אישור TLS כקובץ PEM – אישור שחתום על ידי רשות אישורים (CA), שרשרת אישורים שבה האישור האחרון חתום על ידי CA, או אישור בחתימה עצמית.

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

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

אפשר לייצג אישורים ומפתחות כקובצי PEM או כקובצי PKCS12/PFX. קובצי PEM תואמים לפורמט X.509. אם האישור או המפתח הפרטי שלך לא מוגדרים על ידי קובץ PEM, אפשר להמיר אותו לקובץ PEM באמצעות כלים כמו openssl.

עם זאת, קובצי crt. רבים וקובצי מפתח רבים כבר קיימים בפורמט PEM. אם הקבצים האלה הם קובצי טקסט, והם כוללים בתוך:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

או:

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

הקבצים תואמים לפורמט PEM, וניתן להשתמש בהם ב-Keystore או ב-Truststore בלי להמיר אותם לקובץ PEM.

מידע על שרשראות אישורים

אם אישור הוא חלק מרשת, הטיפול בו משתנה בהתאם לאופן השימוש בו במאגר מפתחות או ב-Truststore:

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

לדוגמה, ניתן לשלב את כל האישורים לקובץ 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-----

אם האישורים שלכם מיוצגים כקובצי PKCS12/PFX, תוכלו להשתמש בפקודה openssl כדי ליצור קובץ PKCS12/PFX משרשרת האישורים, באופן הבא:

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

כשעובדים עם רשתות אישורים ב-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, אבל נחתם על ידי האישור שקיים ב-Truststore. אם תסירו מ-Truststore את אישור ה-CA, ca_cert, אימות ה-TLS ייכשל.

הדף 'מאגרי מפתחות של TLS'

ניתן לגשת לדף 'מאגרי מפתחות של TLS' כמו שמתואר בהמשך.

מוצג הדף TLS Keystores:

כפי שמודגש באיור הקודם, הדף 'מאגרי מפתחות של TLS' מאפשר לכם:

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

הצגת כינוי

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

1. כניסה לדף TLS Keystores.
2. בוחרים את הסביבה (בדרך כלל prod או test).
3. לוחצים על השורה שמשויכת לכתובת האימייל החלופית שרוצים לראות.

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

4. אפשר לנהל את האישור באמצעות הלחצנים שבחלק העליון של הדף כדי:
   • מורידים את האישור כקובץ PEM.
   • צור נציג שירות לקוחות אם יש לכם אישור שפג תוקפו ואתם רוצים לחדש אותו, אפשר להוריד בקשה לחתימה על אישור (CSR). לאחר מכן, שולחים את ה-CSR ל-CA כדי לקבל אישור חדש.
   • עדכון אישור. זהירות: אם מעדכנים אישור שמשמש כרגע מארח וירטואלי או של שרת יעד/נקודת קצה (endpoint), צריך לפנות לתמיכה של Apigee Edge כדי להפעיל מחדש את הנתבים ומעבדי ההודעות. הדרך המומלצת לעדכון אישור היא:
     1. יוצרים מאגר מפתחות חדש או מאגר Truststore חדש.
     2. מוסיפים את האישור החדש למאגר המפתחות החדש או ל-Truststore החדש.
     3. מעדכנים את ההפניה במארח הווירטואלי או בנקודת הקצה של שרת/יעד אל מאגר המפתחות או ה-Truststore. מידע נוסף זמין במאמר עדכון אישור TLS ב-Cloud.
     4. מחיקת הכינוי. הערה: אם מוחקים כתובת אימייל חלופית והיא משמשת כרגע מארח וירטואלי או נקודת קצה של יעד, המארח הווירטואלי או נקודת הקצה של היעד ייכשלו.

יצירת מאגר מפתחות או מאגר מהימנות וכינוי

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

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

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

1. כניסה לדף TLS Keystores.
2. בוחרים את הסביבה (בדרך כלל prod או test).
3. לוחצים על + Keystore.
4. צריך לציין את השם של מאגר המפתחות. השם יכול להכיל תווים אלפאנומריים בלבד.
5. לוחצים על Add Keystore (הוספת מאגר מפתחות). מאגר המפתחות החדש יופיע ברשימה.
6. משתמשים באחת מהפעולות הבאות כדי להוסיף כינוי. למידע נוסף, ראו פורמטים נתמכים של קובצי אישורים.
   • יצירת כתובת אימייל חלופית מאישור (רק ב-Truststore)
   • יצירת כתובת אימייל חלופית מקובץ JAR (מאגר מפתחות בלבד)
   • יצירת כינוי מאישור וממפתח (מאגר מפתחות בלבד)
   • יצירת כתובת אימייל חלופית מקובץ PKCS12/PFX (מאגר מפתחות בלבד)
   • יצירת כתובת אימייל חלופית מאישור עם חתימה עצמית (מאגר מפתחות בלבד)

יצירת כינוי מאישור (חנות אמינות בלבד)

כדי ליצור כינוי מאישור:

1. כניסה לדף TLS Keystores.
2. ממקמים את הסמן מעל מאגר המפתחות כדי להציג את תפריט הפעולות, ולוחצים על +.
3. מציינים את שם הכינוי.
4. בקטע 'פרטי אישור', יש לבחור באפשרות אישור בלבד בתפריט הנפתח 'סוג'.
5. לחץ על בחר קובץ לצד קובץ אישור, נווט אל קובץ PEM שמכיל את האישור ולחץ על פתח.
6. כברירת מחדל, ה-API בודק שתוקף האישור לא פג. אפשר לבחור באפשרות אישור שתוקפו פג כדי לדלג על האימות.
7. בוחרים באפשרות Save כדי להעלות את האישור וליצור את הכינוי.

יצירת כינוי מקובץ JAR (מאגר מפתחות בלבד)

כדי ליצור כתובת אימייל חלופית מקובץ JAR:

1. כניסה לדף TLS Keystores.
2. ממקמים את הסמן מעל מאגר המפתחות כדי להציג את תפריט הפעולות, ולוחצים על +.
3. מציינים את שם הכינוי.
4. בקטע 'פרטי אישור', בוחרים באפשרות קובץ JAR בתפריט הנפתח 'סוג'.
5. לוחצים על Choose File (בחירת קובץ) לצד JAR File (קובץ JAR), מנווטים לקובץ ה-JAR שמכיל את האישור והמפתח, ולוחצים על Open.
6. אם למפתח יש סיסמה, ציינו את הסיסמה. אם אין למפתח סיסמה, משאירים את השדה הזה ריק.
7. כברירת מחדל, ה-API בודק שתוקף האישור לא פג. אפשר לבחור באפשרות אישור שתוקפו פג כדי לדלג על האימות.
8. לוחצים על Save (שמירה) כדי להעלות את המפתח ואת האישור וליצור את הכינוי.

יצירת כינוי מאישור וממפתח (מאגר מפתחות בלבד)

כדי ליצור כינוי מאישור וממפתח:

1. כניסה לדף TLS Keystores.
2. ממקמים את הסמן מעל מאגר המפתחות כדי להציג את תפריט הפעולות, ולוחצים על +.
3. מציינים את שם הכינוי.
4. בקטע 'פרטי אישור', בוחרים באפשרות אישור ומפתח בתפריט הנפתח 'סוג'.
5. לחץ על בחר קובץ לצד קובץ אישור, נווט אל קובץ PEM שמכיל את האישור, ולחץ על פתח.
6. אם למפתח יש סיסמה, ציינו את הסיסמה של המפתח. אם אין למפתח סיסמה, משאירים את השדה הזה ריק.
7. לוחצים על Choose File (בחירת קובץ) לצד Key File (קובץ מפתח), מנווטים אל קובץ ה-PEM שמכיל את המפתח ולוחצים על Open.
8. כברירת מחדל, ה-API בודק שתוקף האישור לא פג. אפשר לבחור באפשרות אישור שתוקפו פג כדי לדלג על האימות.
9. לוחצים על Save (שמירה) כדי להעלות את המפתח ואת האישור וליצור את הכינוי.

יצירת כינוי מקובץ PKCS12/PFX (מאגר מפתחות בלבד)

כדי ליצור כינוי מקובץ PKCS12 שמכיל את האישור והמפתח:

1. כניסה לדף TLS Keystores.
2. ממקמים את הסמן מעל מאגר המפתחות כדי להציג את תפריט הפעולות, ולוחצים על +.
3. מציינים את שם הכינוי.
4. בקטע 'פרטי אישור', בוחרים באפשרות PKCS12/PFX בתפריט הנפתח 'סוג'.
5. לוחצים על Choose File לצד PKCS12/PFX, עוברים לקובץ שמכיל את המפתח והאישור ולוחצים על Open.
6. אם למפתח יש סיסמה, מציינים את הסיסמה של קובץ ה-PKCS12/PFX. אם למפתח אין סיסמה, משאירים את השדה הזה ריק.
7. כברירת מחדל, ה-API בודק שתוקף האישור לא פג. אפשר לבחור באפשרות אישור שתוקפו פג כדי לדלג על האימות.
8. בוחרים באפשרות Save (שמירה) כדי להעלות את הקובץ וליצור את כתובת האימייל החלופית.

יצירת כינוי מאישור בחתימה עצמית (מאגר מפתחות בלבד)

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

כדי ליצור כינוי מאישור בחתימה עצמית:

1. כניסה לדף TLS Keystores.
2. ממקמים את הסמן מעל מאגר המפתחות כדי להציג את תפריט הפעולות, ולוחצים על +.
3. מציינים את שם הכינוי.
4. בקטע 'פרטי אישור', בוחרים באפשרות אישור עם חתימה עצמית בתפריט הנפתח 'סוג'.
5. ממלאים את הטופס באמצעות הטבלה שבהמשך.
6. לוחצים על Save כדי ליצור את האישור ואת זוג המפתחות הפרטיים ולהעלות אותם לכתובת האימייל החלופית.

באישור שנוצר, יופיעו השדות הנוספים הבאים:

• המנפיק
  הישות שחתמה על האישור והנפיקה אותו. לאישור בחתימה עצמית, זהו ה-CN שציינתם כשיצרתם את האישור.
• תוקף
  תקופת התוקף של האישורים מיוצגת בשני תאריכים: התאריך שבו התחילה תקופת התוקף של האישורים והתאריך שבו מסתיימת תקופת התוקף של האישורים. אפשר לקודד את שניהם כערכי UTCTime או GeneralizedTime.

בטבלה הבאה מתוארים שדות הטופס:

השדה בטופס	תיאור	ברירת המחדל	חובה
כינוי	כינוי. האורך המקסימלי הוא 128 תווים.	לא רלוונטי	כן
גודל המפתח	גודל המפתח, בביטים. ערך ברירת המחדל והערך המקסימלי הם 2,048 ביטים.	2048	לא
אלגוריתם חתימה	אלגוריתם חתימה ליצירת מפתח פרטי. הערכים החוקיים הם 'SHA512withRSA', 'SHA384withRSA' ו-'SHA256withRSA' (ברירת מחדל).	SHA256withRSA	לא
תוקף האישור בימים	תוקף האישור, בימים. מקבלת ערך חיובי שאינו אפס.	365	לא
שם נפוץ	שם נפוץ (CN) של הארגון מזהה את שמות הדומיין המלאים המשויכים לאישור. הוא מורכב בדרך כלל על ידי מארח ושם דומיין. לדוגמה, api.enterprise.apigee.com, www.apigee.com וכו'. האורך המקסימלי הוא 64 תווים. בהתאם לסוג האישור, ה-CN יכול להיות שם מארח אחד או יותר ששייך לאותו דומיין (למשל example.com, www.example.com), שם עם תו כללי (למשל *.example.com) או רשימת דומיינים. אין לכלול פרוטוקול (http:// או https://), מספר יציאה או נתיב של משאב. האישור תקף רק אם שם המארח של הבקשה תואם לפחות לאחד מהשמות הנפוצים של האישורים.	לא רלוונטי	כן
אימייל	כתובת אימייל. האורך המקסימלי הוא 255 תווים.	לא רלוונטי	לא
שם היחידה הארגונית	שם הצוות של הארגון. האורך המקסימלי הוא 64 תווים.	לא רלוונטי	לא
שם הארגון	שם הארגון. האורך המקסימלי הוא 64 תווים.	לא רלוונטי	לא
ישוב	שם העיר. האורך המקסימלי הוא 128 תווים.	לא רלוונטי	לא
מדינה/אזור	שם המדינה/המחוז. האורך המקסימלי הוא 128 תווים.	לא רלוונטי	לא
מדינה	קוד מדינה בן שתי אותיות. לדוגמה, IN עבור הודו, US עבור ארצות הברית.	לא רלוונטי	לא
שמות חלופיים	רשימה של שמות מארחים חלופיים. מאפשר לקשר זהויות נוספות לנושא האישור. האפשרויות המוגדרות כוללות כתובת אימייל אלקטרונית באינטרנט, שם DNS, כתובת IP ומזהה משאב (URI) אחיד. עד 255 תווים לכל ערך. אפשר להפריד בין השמות באמצעות פסיקים, או על ידי הקשה על Enter אחרי כל שם.	לא רלוונטי	לא

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

אפשר לבדוק את ה-Truststore ואת מאגר המפתחות בממשק המשתמש של Edge כדי לוודא שהם מוגדרים כמו שצריך. Test Ui מאמת בקשת TLS מ-Edge לשירות קצה עורפי. אפשר להגדיר את השירות לקצה העורפי כך שיתמוך ב-TLS (אבטחת שכבת התעבורה) חד-כיווני או דו-כיווני.

כדי לבדוק TLS חד-כיווני:

1. כניסה לדף TLS Keystores.
2. בוחרים את הסביבה (בדרך כלל prod או test).
3. מעבירים את הסמן מעל מאגר המפתחות של TLS שרוצים לבדוק כדי להציג את תפריט הפעולות, ולוחצים על Test. תיבת הדו-שיח הבאה מופיעה עם השם של ה-Truststore:
   
4. צריך להזין את שם המארח של השירות לקצה העורפי.
5. מזינים את מספר יציאת ה-TLS (בדרך כלל 443).
6. אפשר לציין כל פרוטוקול או הצפנה.
7. בוחרים באפשרות בדיקה.

כדי לבדוק TLS דו-כיווני:

1. ל-Truststore הרצוי, לוחצים על הלחצן Test.
2. בתיבת הדו-שיח, בוחרים באפשרות דו-כיוונית בתור סוג בדיקת ה-SSL. מופיעה תיבת הדו-שיח הבאה:
   
3. צריך לציין את השם של מאגר המפתחות שמשמש ב-TLS דו-כיווני.
4. צריך לציין את השם החלופי במאגר המפתחות שמכיל את האישור והמפתח.
5. צריך להזין את שם המארח של השירות לקצה העורפי.
6. מזינים את מספר יציאת ה-TLS (בדרך כלל 443).
7. אפשר לציין כל פרוטוקול או הצפנה.
8. בוחרים באפשרות בדיקה.

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

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

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

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

1. מוודאים שאתם משתמשים בהפניה ל-Truststore במארח הווירטואלי.
2. מעלים אישור חדש ל-Truststore, כמו שמתואר למעלה, בקטע יצירת כינוי מאישור (רק ב-Truststore).

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

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

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

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

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

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

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

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

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

מחיקת כינוי

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

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