עדכון אישור TLS עבור הענן הפרטי

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

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

  • קובצי עזר - מועדף
  • שמות ישירים
  • משתני זרימה

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

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

ל-Truststore צריך ליצור מאגר אמון עם שם חדש.

 מעדכנים את ההפניה ל-Keystore או ל-Truststore.

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

ל-Truststore, יוצרים מאגר אמון עם שם חדש.

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

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

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

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

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

בדיקת האישור לפני ואחרי העדכון

צריך להשתמש בפקודות openssl הבאות כדי לבדוק את האישור הנוכחי לפני העדכון זה:

echo | openssl s_client -servername hostAlias -connect hostAlias.apigee.net:443 2>/dev/null | openssl x509 -noout -dates -subject

כאשר hostAlias הוא הכינוי של המארח הווירטואלי או כתובת ה-IP. לדוגמה:

echo | openssl s_client -servername api.myCompany.com -connect api.myCompany.com:443 2>/dev/null | openssl x509 -noout -dates -subject

הפלט אמור להופיע בפורמט הבא:

notBefore=Dec 30 22:11:38 2015 GMT
notAfter=Dec 30 22:11:38 2016 GMT
subject= /OU=Domain Control Validated/CN=*.apigee.net

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

עדכון אישור TLS במאגר מפתחות

בפריסה מקומית של Edge:

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

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

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

        אם נקודת הקצה (TargetEndpoint) מפנה להגדרה של TargetServer, ול-TargetServer מפנה למאגר המפתחות, אז לא נדרשת פריסה מחדש של שרת proxy.
      3. אם מאגר המפתחות משמש ל-TLS דו-כיווני בין Edge לבין השירות לקצה העורפי, וגם מחקת/יצרת מחדש את מאגר המפתחות עם אותו שם, עליך להפעיל מחדש את Edge מעבדי הודעות.
  4. אחרי שמוודאים שמאגר המפתחות החדש פועל כמו שצריך, מוחקים את מאגר המפתחות הישן עם האישור והמפתח שפג תוקפם, כפי שמתואר למעלה.

עדכון אישור TLS ב-Truststore

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

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

אם אתם משתמשים בשמות ישירים של מאגרי המפתחות והמאגרים:

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