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

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

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

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

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

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

מידע נוסף:

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

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

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

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

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

• מאגר מפתחות – ישות מסוג מאגר מפתחות שמכילה לפחות אחד כינויים, שבהם כל כינוי מכיל זוג אישור/מפתח.
• truststore – ישות keystore שמכילה לפחות פריט אחד כינויים, שבהם כל כינוי מכיל אישור בלבד.

כשמגדירים TLS למארח וירטואלי או לנקודת קצה (endpoint) של יעד, מאגרי מפתחות ומאגרי אמון מספקים לתפקידים שונים בתהליך לחיצת היד בפרוטוקול TLS. בהגדרה של מארח וירטואלי או יעד נקודת קצה (endstores), עליך לציין מאגרי מפתחות ו-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 שניגש למארח הווירטואלי. בדוגמה הזאת אין אמון נדרש.

אם נדרש מאגר אמון, לדוגמה להגדרה דו-כיוונית של 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.
* DER	לא	לא	כן
* PKCS7	לא	לא	לא

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

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

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

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

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

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

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

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

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

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

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

או:

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

הקבצים תואמים לפורמט PEM ואפשר להשתמש בהם במאגר מפתחות או ל-Truststore בלי להמיר אותם לקובץ PEM.

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

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

• 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

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

הדף TLS Keystores

נכנסים לדף TLS Keystores, כמו שמתואר בהמשך.

הדף TLS Keystores מוצג:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. כניסה לדף TLS Keystores
2. מציבים את הסמן מעל מאגר המפתחות כדי להציג את תפריט הפעולות ולוחצים על +.
3. מציינים את שם הכינוי.
4. בקטע 'פרטי האישור', בוחרים באפשרות אישור בלבד בתפריט הנפתח 'סוג'.
5. לוחצים על Choose File (בחירת קובץ) לצד Certificate File (קובץ אישור), ועוברים אל קובץ 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. לוחצים על בחירת קובץ לצד Certificate File (קובץ אישור), עוברים לקובץ ה-PEM שמכיל את האישור ולוחצים על Open.
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. בוחרים באפשרות שמירה כדי להעלות את הקובץ וליצור את הכינוי.

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

כדי ליצור כינוי שמשתמש באישור עם חתימה עצמית, עליך למלא טופס עם שנדרש כדי ליצור את האישור. לאחר מכן, 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 עבור הודו, ארה"ב עבור ארצות הברית.	לא רלוונטי	לא
שמות חלופיים	רשימה של שמות מארחים חלופיים. מאפשר לקשר זהויות נוספות לנושא של האישור. האפשרויות המוגדרות כוללות כתובת דואר אלקטרוני באינטרנט, 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. בשביל מאגר המהימנות הרצוי, לוחצים על הלחצן 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 כמו שמתואר למעלה בקטע יצירת כתובת אימייל חלופית מאישור (חנות מהימנה בלבד)

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 מפנה למאגר המפתחות אז לא נדרשת פריסה מחדש של שרת proxy.
4. מוודאים ששרתי ה-proxy ל-API פועלים בצורה תקינה.
5. מוחקים את מאגר המפתחות/מאגר האמינות או את הכינוי.

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

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

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

מחיקת כינוי

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

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