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

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

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

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

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

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

מידע נוסף:

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

הטמעה של keystores ו-truststores ב-Edge

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

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

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

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

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

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

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

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

שימוש במאגרי מפתחות PKCS12 ב-Edge for Private Cloud בגרסה 4.53.00 ואילך

אם אתם משתמשים ב-Edge for Private Cloud בגרסה 4.53.00 ואילך, אתם צריכים להשתמש רק במאגר מפתחות PKCS12 כדי להעלות מפתחות ואישורים קשורים ל-Apigee. לקבלת עזרה בהמרת המפתחות והאישורים הקיימים לפורמט PKCS12/PFX, אפשר לעיין במאמר בנושא המרת אישורים לפורמט נתמך.

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

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

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

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

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

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

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

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

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

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

• מאגר מפתחות – אם אישור הוא חלק משרשרת, צריך ליצור קובץ יחיד שמכיל את כל האישורים בשרשרת. האישורים צריכים להיות מסודרים, והאישור האחרון צריך להיות אישור בסיס או אישור ביניים שחתום על ידי אישור בסיס.
• 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 למאגר האישורים. מאגר האישורים עדיין מכיל רק את client_cert_1 ואת ca_cert.

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

שיקולים בנוגע ל-FIPS

אם אתם משתמשים ב-Edge for Private Cloud בגרסה 4.53.00 ואילך במערכת הפעלה עם תמיכה ב-FIPS, אתם צריכים להשתמש רק במאגר מפתחות PKCS12 כדי להעלות מפתחות ואישורים קשורים ל-Apigee.

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

מוצג הדף TLS Keystores (מאגרי מפתחות TLS):

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

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

הצגת כינוי

כדי לראות כינוי:

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

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

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

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

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

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

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

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

יצירת כינוי מאישור (רק בחנות אישורים)

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

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

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

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

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

יצירת כינוי מאישור וממפתח (רק ב-keystore)

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

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

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

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

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

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

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

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

1. נכנסים לדף TLS Keystores.
2. מציבים את הסמן מעל מאגר המפתחות כדי להציג את תפריט הפעולות ולוחצים על +.
3. מציינים את שם הכינוי.
4. בקטע Certificate details (פרטי אישור), בוחרים באפשרות Self-Signed Certificate (אישור בחתימה עצמית) בתפריט הנפתח Type (סוג).
5. ממלאים את הטופס באמצעות הטבלה שלמטה.
6. לוחצים על שמירה כדי ליצור את האישור ואת זוג המפתחות הפרטיים ולהעלות אותם לכינוי.

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

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

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

בדיקת חנות מפתחות או חנות אישורים

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

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

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

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

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

הוספת אישור למאגר אישורים לצורך TLS דו-כיווני

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

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

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

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

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

   מידע נוסף זמין במאמר בנושא שינוי הפניה.

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

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

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

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

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

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

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

מחיקת כינוי

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

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