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

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

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

• מקורות – מומלץ
• שמות ישירים
• משתני זרימה

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

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

כדי לבדוק את האישור הנוכחי לפני העדכון, משתמשים בפקודות 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. יוצרים keystore חדש ומעלים אישור ומפתח כמו שמתואר במאמר בנושא Keystores ו-Truststores. במאגר המפתחות החדש, מוודאים שמשתמשים באותו שם לכינוי המפתח כמו במאגר המפתחות הקיים.
   
   הערה: אפשר למחוק את מאגר המפתחות הנוכחי וליצור מאגר חדש עם אותו שם וכינוי. אין צורך להפעיל מחדש את הנתב. עם זאת, בקשות API ייכשלו עד להגדרת מאגר המפתחות החדש והכינוי.
2. עבור מארח וירטואלי שמשמש לחיבורים נכנסים, כלומר בקשת API ל-Edge:
   1. אם המארח הווירטואלי שלכם משתמש בהפניה למאגר המפתחות, צריך לעדכן את ההפניה כמו שמתואר במאמר עבודה עם הפניות.
   2. אם המארח הווירטואלי משתמש בשם ישיר של מאגר המפתחות:
      1. מעדכנים את כל המארחים הווירטואליים שהתייחסו למאגר המפתחות הישן ולכינוי המפתח הישן כך שיתייחסו למאגר המפתחות החדש ולכינוי המפתח החדש.
      2. מפעילים מחדש את הנתבים, אחד בכל פעם. שימו לב: אם מחקתם את מאגר המפתחות הישן ויצרתם מאגר מפתחות חדש עם אותו שם, לא צריך להפעיל מחדש את הנתב.
         
         אין צורך לפרוס מחדש את ה-proxy.
3. לנקודת קצה של יעד או לשרת יעד שמשמשים לחיבורים יוצאים, כלומר מ-Apigee לשרת קצה עורפי:
   1. אם נקודת הקצה של היעד או שרת היעד משתמשים בהפניות למאגר המפתחות, צריך לעדכן את ההפניה כמו שמתואר במאמר עבודה עם הפניות. אין צורך לפרוס מחדש את ה-proxy.
   2. אם נקודת הקצה או שרת היעד משתמשים במשתנה של זרימת נתונים, צריך לעדכן את המשתנה הזה. אין צורך לפרוס מחדש את ה-proxy.
   3. אם נקודת הקצה או שרת היעד משתמשים בשם ישיר של מאגר המפתחות:
      1. מעדכנים את ההגדרה של שרת היעד או נקודת הקצה של היעד לכל פרוקסי API שהתייחס למאגר המפתחות הישן ולכינוי המפתח הישן, כך שיתייחס למאגר המפתחות החדש ולכינוי המפתח החדש.
      2. לכל שרתי proxy ל-API שמפנים למאגר המפתחות מהגדרה של TargetEndpoint, צריך לפרוס מחדש את ה-proxy.
         
         אם TargetEndpoint מפנה להגדרה של TargetServer, וההגדרה של TargetServer מפנה אל Keystore, אין צורך בפריסה מחדש של ה-proxy.
      3. אם מאגר המפתחות משמש ל-TLS דו-כיווני בין Edge לבין שירות הקצה העורפי, ומחקתם את מאגר המפתחות או יצרתם אותו מחדש עם אותו שם, אתם צריכים להפעיל מחדש את מעבדי ההודעות של Edge.
4. אחרי שמוודאים שמאגר המפתחות החדש פועל בצורה תקינה, מוחקים את מאגר המפתחות הישן עם האישור והמפתח שתוקפם פג, כמו שמתואר למעלה.

עדכון אישור TLS במאגר אישורים מהימנים

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

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

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

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