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

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

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

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

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

סוג ההגדרה	איך מעדכנים או מחליפים אישור	איך מעדכנים את המארח הווירטואלי, נקודת הקצה (endpoint)/שרת היעד של היעד
חומר עזר (מומלץ)	למאגר מפתחות, צריך ליצור מאגר מפתחות חדש עם שם חדש וכתובת אימייל חלופית עם אותו שם כמו של כתובת האימייל החלופית הישנה. אם אתם בקשר ל-Truststore, אתם צריכים ליצור מאגר אמון עם שם חדש.	מעדכנים את ההפניה ל-Keystore או ל-Truststore. לא נדרשת הפעלה מחדש של הנתב או של מעבד ההודעות.
וריאציות של זרימה (נקודת קצה ליעד בלבד)	למאגר מפתחות, צריך ליצור מאגר מפתחות חדש עם שם חדש וכתובת אימייל חלופית עם באותו שם או בשם חדש. אם אתם בקשר ל-Truststore, אתם צריכים ליצור מאגר אמון עם שם חדש.	העברת שינויי זרימה מעודכנים בכל בקשה עם השם של מאגר המפתחות, הכינוי החדש או ב-Truststore. לא נדרשת הפעלה מחדש של הנתב או של מעבד ההודעות.
ישיר	יצירת מאגר מפתחות, כתובת אימייל חלופית ומאגר זהויות חדש.	לעדכן את המארח הווירטואלי ולהפעיל מחדש את הנתבים. אם שרת היעד או נקודת הקצה משתמשים ב-Truststore, פורסים מחדש את שרת ה-proxy.
ישיר	מוחקים את מאגר המפתחות או את ה-Truststore ויוצרים אותם מחדש עם אותו השם.	לא נדרש עדכון למארח הווירטואלי, לא נדרשת הפעלה מחדש של הנתב. אבל בקשות API נכשלות עד שמאגר המפתחות והכינוי החדשים יוגדרו. אם מאגר המפתחות משמש ל-TLS דו-כיווני בין Edge לבין השירות לקצה העורפי, צריך להפעיל מחדש את מעבדי ההודעות.
ישיר	ב-Truststore בלבד, מעלים אישור חדש ל-Truststore.	אם ה-Truststore נמצא בשימוש של מארח וירטואלי, צריך להפעיל מחדש את הנתבים. אם שרת היעד או נקודת הקצה (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, תהליך העדכון של אישור ב-Truststore זהה למאגר מפתחות, כפי שמוצג למעלה. ההבדלים היחידים הם:

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

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

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