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

החל מ-1 בפברואר 2027, רשויות אישורים ציבוריות (CA) הכלולות בתוכנית האמון של גוגל כרום יפסיקו לחתום על אישורים הכוללים את השימוש המורחב במפתח (EKU) של אימות לקוח (clientAuth).

החל מ-15 במרץ 2027, גוגל תאכוף מדיניות המחייבת רשויות רשות אישורים ציבוריות (Public Root CAs) בחנות הבסיס של Chrome להנפיק אישורים המכילים רק את EKU אימות השרת (serverAuth). כתוצאה מכך, רשויות רשות האישור הציבוריות (CAs) בחנות הבסיס של Chrome לא יורשו עוד להנפיק אישורים המשלבים גם אישור שרת וגם אישור לקוח (ECUs) באישור יחיד.

יישומי UC של Instance ייעודיים משתמשים כיום באישורים הכוללים גם EKU של אימות שרת וגם EKU של אימות לקוח בתוך אישור יחיד כדי ליצור אמון עבור חיבורי mTLS. תמיכה בתעודות שרת ולקוח נפרדות צפויה להיות מוצגת עם גרסת אפליקציית UC גרסה 15SU5, המתוכננת להמשך 2026.

נכון לעכשיו, Dedicated Instance משתמש ב-IdenTrust Commercial Root CA 1, חלק מ-Google Chrome Root Store, כדי לחתום על אישורים אלה. עם זאת, עקב שינוי המדיניות הקרוב של Chrome, רשות אישורים זו לא תורשה עוד להנפיק אישורים המכילים את שני ה-EKUs באישור יחיד החל מ-1 בפברואר, 2027.

תעודות מושפעות

אישורי יישום UC הבאים נחתמים באמצעות רשות אישורים ציבורית (Public Root CA) ומשמשים בדרך כלל עבור חיבורי mTLS:

יישום UC	סוג תעודה	חיבורי mTLS נפוצים
סיסקו מאוחד CM / עסקים קטנים ובינוניים	חתול / Tomcat-ECDSA	LDAP, Filebeat, Logstash, SIP OAuth over MRA, Syslog מרוחק
	מנהל שיחות / CallManager-ECDSA	גזעי SIP, חיבורים בין-צמתים ובין-אשכולות
Cisco Unity Connection	חתול / Tomcat-ECDSA	פרוקסי SIP, גזעי SIP
Cisco IM and Presence	חתול / Tomcat-ECDSA	—
	גָבִיעַ / כוס-ECDSA	SIP מאובטח עם CUCM, לקוחות צד שלישי, SIP Proxy
	כוס-xmpp / cup-xmpp-ECDSA	איחוד XMPP
Cisco Emergency Responder	חתול / Tomcat-ECDSA	—
Cisco Expressway	תעודת שרת	גישה ניידת ומרוחקת (MRA)

תעודות לא מושפעות

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

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

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

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

• אישורים ימשיכו לכלול גם יחידות EKU לאימות שרת וגם יחידות אימות לקוח.

על לקוחות ושותפים לבצע את הפעולות הבאות כדי להבטיח תאימות מתמשכת לשירות :

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

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

• Microsoft Windows
• macOS
• iOS / אייפד OS
• Android

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

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

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

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

רישיון CA 1 של IdenTrust Public Sector Root אינו כלול בחנות הרישומים של Google Chrome.

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

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

כדי להבטיח ש-root CA מהימן על ידי Google Chrome ב-Windows, יש לייבא את IdenTrust Public Sector Root CA 1 לאחד מהמיקומים הבאים:

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

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

או

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

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

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

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

מערכת הפעלה Mac - תצורת אמון נדרשת

כדי להבטיח ש-root CA מהימן על ידי Google Chrome ב-macOS, יש להוסיף את IdenTrust Public Sector Root CA 1 ל-macOS Keychain ולוודא שהוא מהימן במפורש:

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

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

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

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

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

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

למידע נוסף, ראו שאלות נפוצות של גוגל.

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

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

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

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

אם אישור זה נפתח בהצלחה ללא אזהרות אמון, רשות האישור 1 של IdenTrust Public Sector Root כבר מהימנה בסביבה.

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

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

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

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

שינויים ב-ECU של תעודה: פעולות שעל לקוחות שיתוף פעולה מקומי של סיסקו לנקוט כעת