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

אתה צופה בתיעוד של Apigee Edge.
הצג תיעוד של Apigee X.

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

מידע על חנויות מפתחות/חנויות מהימנות ומארחים וירטואליים ב-Edge Cloud

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

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

מידע נוסף:

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

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

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

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

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

• keystore - ישות מפתח חנות שמכילה כינוי אחד או יותר, כאשר כל כינוי מכיל צמד אישורים/מפתחות.
• Trustedstore - ישות keystore שמכילה כינוי אחד או יותר, כאשר כל כינוי מכיל אישור בלבד.

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

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

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

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

מידע על הטמעת כינוי

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

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

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

• אישור 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, ואפשר להשתמש בהם ב-Keystore או ב-Trust Store בלי להמיר אותם לקובץ PEM.

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

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

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

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

-----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 עדיין מכיל רק את client_cert_1 ואת ca_cert.

כאשר השרת מעביר את client_cert_2 כחלק מלחיצת יד ב-TLS, הבקשה מצליחה. הסיבה לכך היא ש-Edge מאפשר TLS (אבטחת שכבת התעבורה) להצליח כש-client_cert_2 לא קיים ב-Truststore, אבל נחתם על ידי האישור שקיים ב-Truststore. אם האישור של ca_cert יוסר מה-Trust Store, אימות ה-TLS ייכשל.

הדף TLS Keystores

ניגשים לדף של מאגרי מפתחות TLS (אבטחת שכבת התעבורה), כפי שמתואר בהמשך.

הדף של ה-TLS Keystores מוצג:

כפי שצוין באיור הקודם, הדף TLS Keystores מאפשר לך:

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

הצגת כינוי

כדי להציג כינוי:

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

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

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

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

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

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

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

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

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

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

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

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

כדי ליצור כינוי מקובץ JAR:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שדה טופס	תיאור	ברירת המחדל	חובה
שם כינוי	שם כינוי. האורך המרבי הוא 128 תווים.	לא רלוונטי	כן
גודל המַפְתח	גודל המפתח, בביטים. ערך ברירת המחדל והערך המקסימלי הם 2048 ביט.	2048	לא
אלגוריתם חתימה	אלגוריתם לחתימה ליצירת מפתח פרטי. הערכים החוקיים הם SHA512withRSA, SHA384withRSA ו-SHA256withRSA (ברירת המחדל).	SHA256עם RSA	לא
תוקף האישור בימים	תוקף האישור, בימים. מקבל ערך חיובי שאינו אפס.	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 תווים.	לא רלוונטי	לא
מדינה	קוד מדינה בן שתי אותיות. לדוגמה, הודו בהודו, ארצות הברית.	לא רלוונטי	לא
שמות חלופיים	רשימה של שמות מארחים חלופיים. היא מאפשרת לקשר זהויות נוספות לנושא של האישור. האפשרויות המוגדרות כוללות כתובת אימייל אלקטרונית, שם DNS, כתובת IP ומזהה משאב אחיד (URI). 255 תווים לכל היותר לכל ערך. אפשר להפריד בין השמות באמצעות פסיקים או על ידי הקשה על Enter אחרי כל שם.	לא רלוונטי	לא

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

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

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

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

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

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

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

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

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

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

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

3. יש לעדכן את קובץ העזר של Trustedstore כדי להגדיר אותו לערך אותו. העדכון הזה גורם ל-Edge לטעון מחדש את ה-Trust Store ואת האישור החדש.

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

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

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

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

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

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

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

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

מחיקת כינוי

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

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