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

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

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

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

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

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

כדי לבדוק את האישור הנוכחי לפני העדכון, משתמשים בפקודות 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

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

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

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

      <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. לנקודת קצה של יעד או לשרת יעד שמשמשים לחיבור יוצא, כלומר מ-Apigee לשרת עורפי:
   1. אם נקודת הקצה או שרת היעד משתמשים בהפניות למאגר המפתחות, צריך לעדכן את ההפניה. אין צורך לפרוס מחדש את ה-proxy.
   2. אם נקודת הקצה או שרת היעד משתמשים במשתנה של זרימת נתונים, צריך לעדכן את המשתנה הזה. אין צורך לפרוס מחדש את ה-proxy.

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

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

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

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

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

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

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

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

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

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

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

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

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

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