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

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

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

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

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

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

מידע נוסף:

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

הטמעת מאגרי מפתחות ומאגרי אמון ב-Edge

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

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

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

• מאגר מפתחות – ישות keystore שמכילה כינוי אחד או יותר, וכל כינוי מכיל צמד של אישור/מפתח.
• truststore – ישות 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.

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

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

* מומלץ להשתמש ב-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 תומך בגדלי מפתחות של עד 2048 ביט. השימוש בביטוי סיסמה הוא אופציונלי.

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

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

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

הדף TLS Keystores מוצג:

כפי שמודגש באיור הקודם, בדף 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. לוחצים על Add Keystore. מאגר המפתחות החדש יופיע ברשימה.
6. כדי להוסיף כתובת אימייל חלופית, אפשר להשתמש באחת מהשיטות הבאות. אפשר לעיין גם במאמר פורמטים נתמכים של קובצי אישורים.
   • יצירת כתובת אימייל חלופית מ-cert (truststore בלבד)
   • יצירת כינוי מקובץ JAR (ב-keystore בלבד)
   • יצירת כינוי מאישור ומפתח (מאגר מפתחות בלבד)
   • יצירת כינוי מקובץ PKCS12/PFX (מאגר מפתחות בלבד)
   • יצירת כינוי (alias) מתעודה בחתימה עצמית (במאגר מפתחות בלבד)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. כניסה לדף TLS Keystores
2. בוחרים את הסביבה (בדרך כלל prod או test).
3. מעבירים את הסמן מעל מאגר המפתחות של TLS שרוצים לבדוק כדי להציג את תפריט הפעולות, ולוחצים על בדיקה. תיבת הדו-שיח הבאה מופיעה עם שם מאגר האמון:
   
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. בוחרים באפשרות בדיקה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מחיקת הכינוי

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

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