תודה על המשוב.

זה נועד להודיע לך על שינוי מדיניות דפדפן Google Chrome הקרוב המשפיע על הנפקת אישורי TLS ציבוריים ולתאר את הפעולות שסיסקו תנקוט כדי להבטיח תמיכה מתמשכת בחיבורי TLS הדדיים (MTL) בסביבות מופע ייעודי Cisco Webex Calling וענן UCM.

החל מה-1 בפברואר 202 ⁷, רשויות האישורים הציבוריות (CA) הכלולות בתוכנית האמון של Google Chrome יפסיקו לחתום על אישורים הכוללים שימוש במפתח מורחב ( EKU) לאימות לקוח (ClientAuth).

החל מה- 15 במרץ 2027, Google תאכוף מדיניות המחייבת כי מק"י שורש ציבוריים בחנות השורש של Chrome ינפיקו אישורים המכילים רק את ^ה - EKU אימות שרת (ServerAuth). כתוצאה מכך, מק"י שורש ציבוריים בחנות השורש של Chrome לא יורשו עוד להנפיק אישורים המשלבים הן אימות שרת והן EK U אימות לקוח באישור יחיד.

יישומי UC ייעודיים של מופעים משתמשים כעת באישורים הכוללים גם EKU אימות שרת וגם אימות לקוח בתוך אישור יחיד כדי ליצור אמון עבור חיבורי MTL. תמיכה באישורי שרת ולקוח נפרדים זמינה כעת עם מהדורת יישומי UC V15su5.

נכון לעכשיו, מופע ייעודי משתמש ב-IdenTrust Commercial Root CA 1, חלק מחנות השורש של Google Chrome, כדי לחתום על אישורים אלה. עם זאת, עקב שינוי המדיניות הקרוב של Chrome, CA זה לא יורשה עוד להנפיק אישורים המכילים את שני ה- EKU באי שור יחיד החל מה -1 בפברואר ²⁰² 7.

האישורים הושפעו

אישורי היישום הבאים של UC חתומים באמצעות CA שורש ציבורי ומשמשים בדרך כלל לחיבורי MTL:

יישום UC	סוג התעודה	חיבורי MTL נפוצים
Cisco Unified CM/חברות קטנות ובינוניות	טומקט/טומקט-ECDSA	LDAP, Filebeat, לוגסטאש, SIP OAuth דרך MRA, סיסלוג מרחוק
	מנהל התקשרות/מנהל שיחות-ECDSA	גזעי SIP, חיבורים בין צמתים ובין-אשכולות
Cisco Unity Connection	טומקט/טומקט-ECDSA	פרוקסי SIP, גזעי SIP
הודעות מיידיות ונוכחות של סיסקו	טומקט/טומקט-ECDSA	—
	כוס/כוס-ECDSA	SIP מאובטח עם CUCM, לקוחות צד שלישי, פרוקסי SIP
	כוסה-xmpp/כוסה-XMPP-ECDSA	פדרציית XMPP
Cisco Emergency Responder	טומקט/טומקט-ECDSA	—
Cisco Expressway	אישור שרת	נייד ו- Remote Access (MRA)

האישורים לא הושפעו

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

כדי לטפל בשינוי המדיניות של Chrome ולשמור על פונקציונליות MTL ללא הפרעה, Cisco ת נקוט בפעולה הבאה:

• החל מה -1 ביוני 2026^, סיסקו תחליף את CA השורש הציבורי המשמשת לחתימה על אישורי יישומי UC של מופע ייעודי מ- IdenTrust Commercial Root CA 1 ל- IdenTrust Public Sector Root CA 1 עבור כל חידושי האישורים.

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

• האישורים ימשיכו לכלול גם EKUs לאימות שרת וגם לקוח.

כל יישומים או שירותים של צד שלישי בסביבת הלקוח המחברים יי שומי UC במופע ייעודי באמצעות חיבורי TLS או mTLS חייבים להשתמש באותה שרשרת אישורים כמו יישומי UC במופע ייעודי. אם מאגר האמון של מערכות הלקוח או היישומים אינו כולל כבר את ר שויות האישורים הנדרשות של IdenTrust, יש לייבא את אישור השורש החדש כדי למנוע כשלים בחיבור TLS/MTLS.

1. ביקורת על חיבורי MTL נוכחיים
   1. זהה יישומים, שירותי צד שלישי או שילובים שמתחברים ליישומי UC במופע ייעודי באמצעות TLS או MTL.
   2. ודא אם יישומים אלה סומכים על CA השורש הציבורי החדש: IdenTrust CA שורש למגזר הציבורי 1.
2. הוסף את CA השורש הציבורי החדש (אם נדרש)
   1. אם ה- CA 1 של IdenTrust Public Sector Public Sector Root אינו מהימן כבר ביי שום הלקוח או במאגר האמון של המערכת, יש להוסיף אותו.
   2. ניתן להוריד אותו מהקישורים הבאים:

      CA שורש: IDEntrust שורש למגזר הציבורי CA 1

      דף הורדה חלופי: הורדות תמיכה של IdenTrust

      הנפקה/תת-CA: שרת המג זר הציבורי של I denTrust CA 1.

   עבור רוב היישומים, אמון ב- CA Root מספיק אם השרת מציג את השרשרת המלאה. מועיל לכלול את הנפקה/תת-CA ליישומים הדורשים יי בוא את אישור הביניים בנפרד.

קוד ה- CA 1 של IdenTrust Public Sector Root מהימן כברירת מחדל במאגרי האמון הסטנדרטיים עבור מערכות ההפעלה והפלטפורמות הבאות:

• Microsoft Windows
• מקאוס
• אייפוס /אייפדוס
• Android

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

הערת חנות אמון אנדרואיד

ה- CA 1 של IdenTrust Public Sector Root כלול בחנות CA של מערכת Android והוא מהימן כברירת מחדל בגירסאות אנדרואיד הנתמכות כעת. Android אינו מספק מיפוי ציבורי ספציפי לגרסה עבור תאריכי הצגת תעודות שורש בודדות. האמון מנוהל דרך חנות CA של מערכת אנדרואיד ומופץ באמצעות עדכוני מערכת הפעלה ועדכוני מערכת Google Play.

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

ה- CA 1 של השורש למגזר הציבורי של IdenTrust אינו נכלל בחנות השורש של Google Chrome.

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

Windows - תצורת אמון נדרשת

כדי להבטיח שה-CA השורש מאומרת על ידי Google Chrome ב-Windows, יש לייבא את CA השורש למגזר הציבורי של IdenTrust לאחד מהמיקומים הבאים:

• מחשב מקומי → רשויות אישור שורש מהימנות

  (מומלץ למערכות מנוהלות ארגוניות)

או

• משתמש נוכחי → רשויות אישור שורש מהימנות

  (לאמון ברמת המשתמש)

אישורים המיובאים באמצעות אשף ייבוא האישורים של Windows למיקומים אלה (כולל באמצעות מדיניות קבוצתית) מהימנים על ידי Google Chrome.

אישורי שורש הקיימים רק ב- Windows צד שלישי אינם מהימנים באופן אוטומטי על ידי Chrome אלא אם כן מיובאים במפורש כמתואר לעיל.

Mac OS - תצורת אמון נדרשת

כדי להבטיח שה-CA השורש מאובטח על ידי Google Chrome ב-macOS, יש להוסיף את CA השורש למגזר הציבורי של IdenTrust 1 למחזיק המפתחות של macOS ולאמין במפורש:

1. ייבוא האישור למחזיק מפתחות המערכת (מומלץ) או מחזיק מפתחות כניסה

2. פתח את האישור והגדר:

   • בעת שימוש באישור זה: אמון תמיד

     (או לכל הפחות, SSL: אמון תמיד)

לאחר אמון ברמת המערכת או המשתמש, Google Chrome יכבד את האישור כא מין.

מנהלי מערכת יכולים לאמת אילו אישורי פלטפורמה מהימנים על ידי Chrome על ידי ניווט אל: chrome: //certificate- manager/localcerts/platformcerts

לקבלת מידע נוסף, ראה שאלות נפוצות של Google.

שילובים של צד שלישי דורשים אימות לקוחות ראשוני.

עבור יישומים או שירותים של צד שלישי שיוצרים חיבורי TLS/mTLS עם יישומי UC של מופע ייעודי, הלקוחות חייבים לבצע את הפעולות המוזכרות בש ינויים באישור CA ציבורי המשפיעים על מופע ייעודי.

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

לקוחות יכולים לאמת את CA השורש הציבורי החדש באמצעות אישור הבדיקה של IdenTrust.

אם הדף נפתח בהצלחה, ה- CA 1 של IdenTrust Sector Public Sector Root הוא מהימן בסביבתך .

אם יש לך שאלות בנוגע לשינוי זה, למדיניות הדפדפן של Google Chrome או לעד כוני אישורים במופע ייעודי, פתח בקשת שירות ב-Control Hub תחת סגנון חיים של יישום UC.

לקוחות UCM Cloud (UCMC) שבבעלותם התחום שלהם ומנהלים חידוש אישורי יישומ י UC משלהם ולא האצילו סמכות תחום לסיסקו לחתימה על אישורי יי שומי UC, יהיו אחראים לעבוד ישירות עם רשויות האישורים הציבוריות שבחרו כדי לטפל בשינוי זה. 

לקוחות אלה צריכים גם להתאים את ה המלצות של מוצר יישומי UC הרלוונ טי (מוצרי שיחות מקומיות של Cisco ו Cisco Expressway) בנוגע לשימוש באישורים ולתיקון הקשורים לשינויים הקרובים במדיניות ה-CA הציבורית והדפדפן. לקבלת מידע נוסף, ראה תפקידים ואחריות. 

סיסקו תמשיך לספק עדכונים ככל שתהיה זמינה תמיכה ביישומי UC עבור אישורי שרת ולקוח נפרדים. עיין במסמך זה לקבלת העדכונים האחרונים.

שינויים באישור EKU: פעולות ללקוחות שיתוף פעולה מקומי של סיסקו חייבים לנקוט עכשיו