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

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

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

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

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

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

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

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

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

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

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