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

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

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

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

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

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

* מומלץ להשתמש ב-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), קובץ שמכיל שרשרת אישורים שבה האישור האחרון חתום מטעם CA או אישור בחתימה עצמית.
• מפתח פרטי כקובץ PEM או PKCS12/PFX. Edge תומך בגדלי מפתחות של עד 2048 ביט. א' ביטוי הסיסמה הוא אופציונלי.

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

• אישור TLS כקובץ PEM – אישור שחתום על ידי רשות אישורים (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 באמצעות כינוי שונה לכל אישור. אם מעלים אותם באישור יחיד, האישורים צריכים להיות בסדר והאישור האחרון צריך להיות אישור בסיס או אישור ביניים שחתום על ידי אישור בסיס.
• אם יוצרים קובץ אחד שמכיל כמה אישורי SSL, צריך להוסיף שורה ריקה בין כל אישור.

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

שיקולים לגבי FIPS

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

הדף TLS Keystores

הדף TLS Keystores מוצג:

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

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

הצגת כינוי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בדיקת מאגר מפתחות או מאגר אמון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מחיקת הכינוי

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

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