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

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

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

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

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

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

צריך להשתמש באותה פקודה אחרי עדכון האישור כדי לבדוק אותו.

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

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

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

      כדי להבין איך לבדוק את הרכיב <SSLInfo> בהגדרה של שרת היעד מאגר המפתחות/מאגר המפתחות מוגדרים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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