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

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

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

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

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

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

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

לגבי מאגר אמון, יוצרים מאגר אמון עם שם חדש.

מעדכנים את ההפניה ל-Keystore או ל-Truststore.

אין צורך לפנות אל התמיכה של Apigee Edge.

וריאציות של זרימה (נקודת קצה ליעד בלבד)

לאחסון מפתחות, יוצרים מאגר מפתחות חדש עם שם חדש וכתובת אימייל חלופית עם אותו שם או עם שם חדש.

לגבי מאגר אמון, יוצרים מאגר אמון עם שם חדש.

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

אין צורך לפנות אל התמיכה של Apigee Edge.

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

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

אם שרת היעד או נקודת הקצה משתמשים ב-Truststore, פורסים מחדש את שרת ה-proxy.

ישיר מוחקים את מאגר המפתחות או את ה-Truststore ויוצרים אותם מחדש עם אותו השם.

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

אם מאגר המפתחות משמש ל-TLS דו-כיווני בין Edge לבין השירות לקצה העורפי, פונים לתמיכה של Apigee Edge כדי להפעיל מחדש את מעבדי ההודעות.

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

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

אם נקודת קצה יעד או שרת יעד משתמשים במאגר האימון, פנו אל התמיכה של 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, בוחרים את שם הארגון.
  3. למארח וירטואלי, יש לקבוע איך המארח הווירטואלי מציין את מאגר המפתחות ו-Truststore.
    1. בהתאם לגרסה של ממשק המשתמש של Edge:
      1. אם משתמשים בממשק המשתמש הקלאסי של Edge: בוחרים באפשרות APIs > הגדרת הסביבה.
      2. אם אתם משתמשים בממשק המשתמש החדש של Edge: בוחרים באפשרות אדמין > סביבות.
    2. לוחצים על הכרטיסייה מארחים וירטואליים.
    3. כדי להציג את המאפיינים של המארח הווירטואלי הספציפי שאתם מעדכנים, לוחצים על הלחצן Show. התצוגה כוללת את המאפיינים הבאים:
      1. Key Store: השם של מאגר המפתחות הנוכחי, שמופיע בדרך כלל כהפניה בשדה from‏ ref://mykeystoreref.

        לחלופין, אפשר לציין אותו בשם ישיר, בצורה myKeystoreName, או לציין אותו באמצעות משתנה זרימה, בצורה {ssl.keystore}.
      2. כינוי מפתח. הערך של הנכס הזה הוא שם הכינוי מאגר מפתחות. מאגר המפתחות החדש צריך ליצור כינוי עם אותו שם.
      3. Trust Store: השם של ה-Truststore הנוכחי, אם יש כזה, בדרך כלל צוין כהפניה ב-ref://mytruststoreref.

        לחלופין, אפשר לציין אותו בשם ישיר, בפורמט myTruststoreName, או באמצעות משתנה תהליך, בפורמט {ssl.truststorestore}.
  4. בנקודה קצה יעד/בשרת יעד, קובעים איך נקודת הקצה היעד מציינת את מאגר המפתחות ואת מאגר האמון:
    1. בתפריט של ממשק המשתמש לניהול Edge, בוחרים באפשרות APIs.
    2. בוחרים את השם של שרת ה-proxy של ה-API.
    3. לוחצים על הכרטיסייה פיתוח.
    4. בקטע Target Endpoints (נקודות קצה) בוחרים באפשרות ברירת מחדל.
    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. אם נקודת הקצה או השרת היעד משתמשים במשתנה תהליך, מעדכנים את משתנה התהליך. לא נדרשת פריסה מחדש של שרתי proxy.
    3. אם בשרת היעד או בנקודת הקצה היעד נעשה שימוש בשם ישיר של מאגר המפתחות, צריך לעדכן את ההגדרה של שרת היעד או של נקודת הקצה היעד לכל שרת proxy של API שמפנה למאגר המפתחות ולכינוי המפתח הישנים, כך שיפנה למאגר המפתחות ולכינוי המפתח החדשים.

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

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

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

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

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

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

לפריסה של Edge בענן:

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

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

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

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

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