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

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

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

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

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

סוג ההגדרה	איך לעדכן או להחליף אישור	איך מעדכנים את המארח הווירטואלי ושרת היעד של נקודת הקצה/יעד
קובץ עזר (מומלץ)	עבור מאגר מפתחות, יוצרים מאגר מפתחות חדש עם שם חדש וכינוי עם אותו שם כמו הכינוי הישן. עבור מאגר אמינות, יוצרים מאגר אישורים עם שם חדש.	מעדכנים את ההפניה ל-Keystore או ל-Truststore. אין צורך לפנות לתמיכה של Apigee Edge.
משתני זרימה (נקודת קצה (endpoint) של היעד בלבד	עבור מאגר מפתחות, יוצרים מאגר מפתחות חדש עם שם חדש וכינוי עם אותו שם או עם שם חדש. עבור מאגר אמינות, יוצרים מאגר אישורים עם שם חדש.	מעבירים את משתנה התהליך המעודכן לכל בקשה עם השם של מאגר המפתחות החדש, הכינוי או ה-Truststore החדשים. אין צורך לפנות לתמיכה של Apigee Edge.
Direct	יצירת מאגר מפתחות חדש, כתובת אימייל חלופית ו-Truststore.	עבור מארחים וירטואליים, יש לפנות לתמיכה של Apigee Edge כדי להפעיל מחדש את הנתבים. אם שרת ה-proxy/נקודת הקצה משתמש ב-Truststore, צריך לפרוס מחדש את שרת ה-proxy.
Direct	מוחקים את מאגר המפתחות או ה-Truststore ויוצרים אותם מחדש עם אותו שם.	לא נדרש עדכון למארח הווירטואלי. עם זאת, בקשות ה-API נכשלות עד להגדרה של מאגר המפתחות והכינוי החדש. אם מאגר המפתחות משמש ל-TLS דו-כיווני בין Edge לשירות לקצה העורפי, צריך לפנות לתמיכה של Apigee Edge כדי להפעיל מחדש את מעבדי ההודעות.
Direct	ל-Truststore בלבד, יש להעלות אישור חדש ל-Truststore.	עבור מארחים וירטואליים, יש לפנות לתמיכה של Apigee Edge כדי להפעיל מחדש את Edge Routers. אם שרת היעד או נקודת הקצה (endpoint) משתמשים ב-Truststore, צריך לפנות אל התמיכה של Apigee Edge כדי להפעיל מחדש את מעבדי ההודעות.

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

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

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

HOSTNAME הוא הכינוי המארח ו-ORG-ENV הוא הארגון והסביבה. לדוגמה:

echo | openssl s_client -servername example.com -connect myOrg-prod.apigee.net: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

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

צריך לקבוע איך המארח הווירטואלי או היעד של שרת נקודת הקצה או שרת היעד מפנים ל-Keystore ול-Truststore

1. מתחברים לממשק המשתמש לניהול Edge בכתובת https://enterprise.apigee.com.
2. בתפריט של ממשק המשתמש לניהול Edge, בוחרים את שם הארגון.
3. במארח וירטואלי, קובעים איך המארח הווירטואלי מציין את מאגר המפתחות ואת ה-Truststore.
   1. בהתאם לגרסת ממשק המשתמש של Edge שבה אתם משתמשים:
      1. אם משתמשים בממשק המשתמש הקלאסי של Edge: בוחרים באפשרות APIs > הגדרת סביבה.
      2. אם משתמשים בממשק המשתמש החדש של Edge: בוחרים באפשרות ניהול > סביבות.
   2. בוחרים בכרטיסייה מארחים וירטואליים.
   3. עבור המארח הווירטואלי הספציפי שברצונך לעדכן, יש ללחוץ על הלחצן Show כדי להציג את המאפיינים שלו. התצוגה כוללת את המאפיינים הבאים:
      1. Key Store: השם של מאגר המפתחות הנוכחי, שמצוין בדרך כלל כקובץ הפניה מ-ref://mykeystoreref.
         
         לחלופין, אפשר לציין אותו בשם ישיר, בפורמט myKeystoreName, או לציין אותו באמצעות משתנה זרימה, בצורה {ssl.keystore}.
      2. כינוי מפתח. הערך של המאפיין הזה הוא השם החלופי במאגר המפתחות. מאגר המפתחות החדש צריך ליצור כתובת אימייל חלופית עם אותו שם.
      3. Trust Store: השם של ה-Truststore הנוכחי, אם יש כזה, שמצוין בדרך כלל בתור הפניה ב-ref://mytruststoreref.
         
         לחלופין, אפשר לציין אותו בשם ישיר, בפורמט myTruststoreName, או לציין אותו באמצעות משתנה זרימה, בצורה {ssl.truststorestore}.
4. לשרת יעד/נקודת קצה (endpoint) של יעד, קובעים איך נקודת הקצה (endpoint) של היעד מציינת את מאגר המפתחות ואת ה-Truststore:
   1. בתפריט של ממשק המשתמש לניהול Edge, בוחרים באפשרות APIs.
   2. בוחרים את השם של שרת ה-API של שרת ה-proxy.
   3. לוחצים על הכרטיסייה פיתוח.
   4. בקטע Target Endpoints, בוחרים באפשרות ברירת מחדל.
   5. באזור הקוד, מופיעה ההגדרה של TargetEndpoint. צריך לבדוק את הרכיב <SSLInfo> כדי לראות איך ה-keystore/truststore מוגדר.
      
      הערה: אם נקודת הקצה (endpoint) של היעד משתמשת בשרת יעד, הגדרת ה-XML של נקודת הקצה (endpoint) תופיע כמו בדוגמה שבהמשך, כאשר התג <LoadBalancer> מציין את שרתי היעד שמשמשים את שרת ה-Proxy של ה-API.

      <TargetEndpoint name="default">
        …
        <HTTPTargetConnection>
          <LoadBalancer>
            <Server name="target1" />
            <Server name="target2" />
          </LoadBalancer>
          <Path>/test</Path>
        </HTTPTargetConnection>
          …
      </TargetEndpoint>

      יש לבדוק את הרכיב <SSLInfo> בהגדרה של שרת היעד כדי לקבוע את אופן ההגדרה של ה-keystore/truststore.

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

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

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

בפריסה מבוססת-ענן של Edge:

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

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

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

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

      לאחר מכן צריך לפרוס מחדש את שרת ה-proxy.

4. אחרי שמוודאים שמאגר המפתחות החדש פועל כמו שצריך, מוחקים את מאגר המפתחות הישן עם האישור והמפתח שפג תוקפם.

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

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

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

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

בפריסה מבוססת-ענן של Edge:

1. יוצרים Truststore חדש ומעלים אישור כמו שמתואר במאמר יצירת מאגרי מפתחות ו-Truststore באמצעות ממשק המשתמש של Edge.

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

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

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

      לאחר מכן צריך לפרוס מחדש את שרת ה-proxy.

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