דף זה תורגם על ידי Cloud Translation API.

שאלות נפוצות בנושא העברת רשות אישורים ברמה הבסיסית לפלטפורמה של מפות Google

המסמך הזה מכיל את הקטעים הבאים:

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

לסקירה מפורטת יותר של ההעברה המתמשכת ל-CA ברמה הבסיסית (root) של Google ראו מה קורה?

הסברים על המונחים

בהמשך מופיעה רשימה של המונחים החשובים ביותר שצריך להכיר במסמך הזה. בשאלות הנפוצות על Google Trust Services תוכלו לקרוא סקירה כללית מקיפה יותר של המונחים הקשורים.

אישור SSL/TLS: אישור מקשר מפתח קריפטוגרפי לזהות.; אישורי SSL/TLS משמשים לאימות וליצירת חיבורים מאובטחים לאתרים. האישורים מונפקים ונחתמים באופן קריפטוגרפי על ידי ישויות שנקראות 'רשויות אישורים'.; הדפדפנים מסתמכים על אישורים שהונפקו על ידי רשויות אישורים מהימנות כדי לדעת שהמידע נשלח לשרת הנכון ושה הוא מוצפן בזמן ההעברה.
Secure Sockets Layer (SSL): Secure Sockets Layer היה הפרוטוקול הנפוץ ביותר ששימש להצפנת תקשורת באינטרנט. פרוטוקול ה-SSL כבר לא נחשב מאובטח ואין להשתמש בו.
Transport Layer Security (TLS)‎: Transport Layer Security הוא הדור הבא של SSL.
רשות אישורים (CA): רשות אישורים היא כמו משרד דרכון דיגיטלי למכשירים ולאנשים. היא מנפיקה מסמכים (אישורים) שמוגנים מבחינה קריפטוגרפית כדי להוכיח שיש ישות (למשל אתר) היא מי שהיא טוענת שהיא.; לפני הנפקת אישור, רשויות אישור אחראיות לאמת שהשמות שמוגדרים באישור מקושרים לאדם או לישות שמבקשים אותו.; המונח 'רשות האישורים' יכול להתייחס גם לארגונים כמו Google Trust Services וגם למערכות שמנפיקות אישורים.
אחסון אישורי בסיס: מאגר אישורי בסיס מכיל קבוצה של רשויות אישורים שמהימנות על ידי ספק תוכנת אפליקציות. לרוב הדפדפנים ומערכות ההפעלה יש מאגר משלהם של אישורי בסיס.; כדי להיכלל במאגר של אישורי בסיס, רשות האישורים צריכה לעמוד בדרישות מחמירות שנקבעו על ידי ספק תוכנת האפליקציה.; בדרך כלל הם כוללים ציות לתקנים המקובלים בתחום, כמו הדרישות של הפורום של קנדה/הדפדפן.
רשות אישורי בסיס: רשות אישורי בסיס (או יותר נכון, האישור שלה) הוא האישור העליון בשרשרת האישורים.; אישורי CA ברמה הבסיסית הם בדרך כלל בחתימה עצמית. המפתחות הפרטיים המשויכים אליהם מאוחסנים במתקנים מאובטחים מאוד, ונשמרים במצב אופליין כדי להגן עליהם מפני גישה לא מורשית.
רשות אישורי ביניים: רשות אישורים ביניים (או, באופן מדויק יותר, האישור שלה) הוא אישור שמשמש לחתימה על אישורים אחרים בשרשרת אישורים.; רשויות אישורים ביניים קיימות בעיקר כדי לאפשר הנפקת אישורים אונליין, ובמקביל לאפשר את האישור של רשות האישורים ברמה הבסיסית (root) להישאר אופליין.; רשויות אישורים ביניים נקראות גם רשויות אישורים משניות.
רשות האישורים המנפיקה: רשות אישורים מנפיקה, או יותר נכון, האישור שלה, הוא האישור שמשמש לחתימה על האישור התחתון ביותר בשרשרת האישורים.; האישור התחתון ביותר נקרא בדרך כלל אישור מנוי, אישור של ישות קצה או אישור קצה. במסמך הזה נשתמש גם במונח אישור שרת.
שרשרת אישורים: אישורים מקושרים למנפיק שלהם (חתומים על ידיו באופן קריפטוגרפי). שרשרת אישורים מורכבת מאישור עלה, כל אישורי המנפיק שלה ואישור בסיסי.
חתימה חוזרת: לקוחות של ספקי תוכנות אפליקציות צריכים לעדכן את מאגר אישורי הבסיס שלהם כך שיכללו אישורי CA חדשים, כדי שהמוצרים שלהם ייחשבו כמהימנים. לוקח קצת זמן עד שנעשה שימוש נרחב במוצרים עם אישורי ה-CA החדשים.; כדי לשפר את התאימות ללקוחות ישנים יותר, אישורי CA יכולים להיות "חתומים בכפל" על ידי רשות אישורים אחרת ותיקה יותר. כך נוצר למעשה אישור CA שני לאותה זהות (שם וזוג מפתחות).; בהתאם להרשאות ה-CA שכלולות במאגר אישורי הבסיס, הלקוחות ייצרו שרשרת אישורים אחרת עד לרמה הבסיסית (root) שהם סומכים עליהם.

מידע כללי

מה קורה?

התמונה הגדולה

בשנת 2017, Google התחילה פרויקט רב-שנתי להנפקה של אישורי Root משלה ולהשתמש בהם. אלה החתימות הקריפטוגרפיות שמהוות את הבסיס לאבטחת האינטרנט של TLS שבה נעשה שימוש ב-HTTPS.

אחרי השלב הראשון, אבטחת TLS של שירותי הפלטפורמה של מפות Google אושרה על ידי GS Root R2, רשות אישורי בסיס (CA) ידועה מאוד ואמינה, ש-Google רכשה מ-GMO GlobalSign כדי להקל על המעבר לרשויות אישורים ברמה הבסיסית (root) של שירותי Google Trust ב-Google (GTS).

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

עם זאת, לפי תכנון, רשות אישורים לא יכולה להנפיק אישורים שתוקפם עולה על תאריך התפוגה של האישור שלה. תוקף GS Root R2 יפוג ב-15 בדצמבר 2021, ולכן Google תעביר את השירותים שלה ל-CA חדש, GTS Root R1 Cross, באמצעות אישור שהונפק על ידי רשות האישור ברמה הבסיסית של Google, GTS Root R1.

הרוב המכריע של מערכות ההפעלה המודרניות וספריות הלקוח של TLS כבר סומכים על אישורי ה-CA ברמה הבסיסית (root) של GTS, אבל כדי להבטיח מעבר חלק לרוב המערכות מהדור הקודם, Google רכשה חתימה צולבת מ-GMO GlobalSign באמצעות GlobalSign Root CA – R1, אחת מרשויות האישורים הישנות והמהימנות ביותר שזמינות כרגע.

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

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

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

השירותים שלכם פועלים בפלטפורמות לא סטנדרטיות או מדור קודם, או שאתם מאחסנים אישורי בסיס משלכם
לא נקטתם פעולה בשנים 2017-2018, במהלך השלב הראשון של העברת ה-CA ברמה הבסיסית (root) של Google, או שלא התקנתם את כל האישורים מחבילת האישורים המהימנים של Google ברמה הבסיסית (root)

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

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

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

סיכום טכני

כפי שפורסם ב-15 במרץ 2021 בבלוג האבטחה של Google, התוקף של GS Root R2, רשות האישורים ברמה הבסיסית שבה נעשה שימוש בפלטפורמה של מפות Google מאז תחילת 2018, יפוג ב-15 בדצמבר 2021. לכן, במהלך השנה Google תעבור ל-CA חדש שנוצר לאחרונה, GTS Root R1 Cross. כלומר, השירותים שלנו יעברו בהדרגה לאישורי TLS ברמה הבסיסית (leaf) שיונפקו על ידי רשות האישורים החדשה הזו.

כמעט כל לקוחות ה-TLS והמערכות המודרניות כבר מוגדרים מראש עם האישור GTS Root R1, או שהם אמורים לקבל אותו דרך עדכוני תוכנה רגילים. האישור GlobalSign Root CA – R1 אמור להיות זמין גם במערכות מדור קודם.

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

השירותים שלכם פועלים בפלטפורמות לא סטנדרטיות או מדור קודם, או שאתם מאחסנים אישורי בסיס משלכם.
לא נקטתם פעולה בשנים 2017-2018, במהלך השלב הראשון של העברת ה-CA ברמה הבסיסית (root) של Google, או שלא התקנתם את כל האישורים מחבילת האישורים המהימנים של Google ברמה הבסיסית (root)

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

הפרטים המלאים מופיעים בשאלה למה כדאי לשמור על סנכרון של מאגר אישורי הבסיס עם חבילת רשויות האישורים המהימנה ברמה הבסיסית של Google?

איך אפשר לקבל עדכונים על שלב ההעברה הזה?

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

איך אפשר לקבל הודעה מראש על העברות עתידיות?

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

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

אנחנו משתמשים במספר שירותי Google. האם ההעברה של רשות האישורים ברמה הבסיסית תשפיע על כולם?

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

תוכלו לקרוא את התשובות לשאלות למה כדאי לשמור על סנכרון של מאגר אישורי הבסיס עם חבילת רשויות האישורים (CA) המהימנה של Google? ואילו סוגים של אפליקציות נמצאים בסיכון לקריסה? כדי לקבל תובנות נוספות.

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

איך לוודא אם נדרש עדכון למאגר אישורי הבסיס שלי

בודקים את סביבת האפליקציה באמצעות נקודות הקצה לבדיקה שמפורטות בהמשך:

אם יש לכם אפשרות ליצור חיבור TLS לנקודת הקצה (endpoint) של GTS Root R1 Cross הבדיקה, תאריך התפוגה של GS Root R2 לא יושפע.
אם תצליחו ליצור חיבור TLS לנקודת הקצה (endpoint) של בדיקת GTS Root R1, האפליקציה שלכם כנראה גם תהיה מוגנת מפני תפוגת התוקף של GTS Root R1 Cross ושל GlobalSign Root CA – R1 ב-2028.

באופן כללי, המערכת תהיה תואמת לשינוי הזה ברשות האישורים ברמה הבסיסית אם:

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

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

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

האם יש כלי פשוט שבו אוכל להשתמש כדי לאמת את מאגר אישורי הבסיס שלנו?

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

להוראות על curl, ראו את הקטע קבלת curl שבהמשך.

פקודות openssl שמופיעות בהמשך מיועדות לגרסה 1.1.1 ואילך. אין תמיכה בגרסאות קודמות לגרסה 1.1.1. אם אתם משתמשים בגרסה קודמת, עליכם לשדרג או לשנות את הפקודות האלה בהתאם לגרסה שלכם. להוראות לקבלת openssl, ראו את הקטע קבלת OpenSSL בהמשך.

תוכלו למצוא עוד כלים שימושיים בקטע איפה אפשר לקבל את הכלים הדרושים? שבהמשך.

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

בדיקת מאגר אישורי הבסיס שמוגדר כברירת מחדל

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

אימות חבילת רשויות אישורי הבסיס המהימנות של Google

מורידים את חבילת ה-CA המהימנה של Google ברמה הבסיסית (root) ואז מבצעים את השלבים הבאים:

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

איך ומתי תמשיך ההעברה של רשות האישורים ברמה הבסיסית של Google?

השלב הראשון (המעבר ל-GS Root R2), שהכרזנו בינואר 2017, התחיל בסוף 2017 והסתיים במחצית הראשונה של 2018.
השלב השני (המעבר ל-GTS Root R1 Cross) הוצג במרץ 2021, והוא יושק במהלך החודשים הקרובים, לפני שתוקף GS Root R2 יפוג ב-15 בדצמבר 2021.

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

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

כדי לקבל רקע נוסף, ראו גם את השאלה למה כדאי לשמור את אישורי הבסיס שלי בסנכרון עם חבילת ה-CA המהימנה של Google ברמה הבסיסית?.

תוכנית השקה כללית לכל שירות של Google

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

מי יושפע, מתי ואיפה?

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

אנחנו לא יכולים לדעת בוודאות מראש מי יושפע, מתי ואיפה, ולכן אנחנו ממליצים לכל הלקוחות שלנו לאמת את השירותים שלהם ולהכין אותם לעתיד כבר עכשיו, הרבה לפני שלבי ההעברה האפשריים של רשות האישורים ברמה הבסיסית (root CA) של Google.

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

מה צריך לחפש

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

בהתאם להגדרות ה-TLS (אבטחת שכבת התעבורה), הלקוחות יכולים להמשיך לשלוח בקשה לפלטפורמה של מפות Google, או לסרב להמשיך לטפל בבקשה.

מהן הדרישות המינימליות ללקוח TLS כדי לתקשר עם פלטפורמת מפות Google?

אישורי פלטפורמת מפות Google כוללים Subject Alternative Names (SAN) ב-DNS, ולכן עיבוד האישור של הלקוח צריך לתמוך ב-SAN שעשוי לכלול תו כללי לחיפוש אחד בתור התווית השמאלית ביותר בשם, כמו *.googleapis.com.

דרישות נוספות מפורטות בקטע מהן הדרישות המומלצות ללקוח TLS כדי לתקשר עם Google? בשאלות הנפוצות בנושא GTS.

אילו סוגי אפליקציות עלולים לקרוס?

האפליקציה משתמשת במאגר אישורי הבסיס של המערכת ללא הגבלות של המפתח

אפליקציות של שירותי אינטרנט בפלטפורמה של מפות Google

אם אתם משתמשים במערכת הפעלה רגילה, למשל, Ubuntu,‏ Red Hat,‏ Windows 10 או Server 2019,‏ OS X) שעדיין מתוחזק ומקבל עדכונים באופן קבוע, מאגר אישורי הבסיס שמוגדר כברירת מחדל אמור כבר לכלול את האישור GTS Root R1.

אם אתם משתמשים בגרסה מדור קודם של מערכת הפעלה שכבר לא מקבלת עדכונים, יכול להיות שאין לכם אישור של GTS Root R1. עם זאת, סביר להניח שמאגר אישורי הבסיס מכיל את GlobalSign Root CA – R1 – אחת מרשויות האישורים הישנות והמהימנות ביותר.

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

אפליקציות הפלטפורמה של מפות Google בצד הלקוח

בדרך כלל, אפליקציות JavaScript API של מפות Google מסתמכות על אישורי הבסיס של דפדפן האינטרנט שמפעיל את האפליקציה. לפרטים נוספים, ראו האם אפליקציות JavaScript נמצאות בסיכון לשיבושים?.

באפליקציות לנייד ילידיות שמשתמשות ב-Maps SDK ל-Android, ב-Maps SDK ל-iOS, ב-Places SDK ל-Android או ב-Places SDK ל-iOS, חלים אותם כללים שחלים על אפליקציות שמבצעות קריאה לשירותי האינטרנט של פלטפורמת מפות Google.

לפרטים נוספים, ראו האם אפליקציות לנייד עלולות לגרום לשיבושים?.

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

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

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

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

למה כדאי לשמור על סנכרון של מאגר אישורי הבסיס עם חבילת רשויות אישורי הבסיס המהימנות של Google?

הרשימה המלאה של רשויות אישורים ברמה הבסיסית (root) בחבילת ה-CA המהימנים של Google ברמה הבסיסית (root) כוללת את כל ה-CAs שעשויות לשמש את שירותי Google בעתיד הקרוב.

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

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

ניתן לעיין בשאלה איך אפשר לקבל הודעה מראש על העברות עתידיות? כדי להבין איך לקבל עדכונים לגבי העברות עתידיות של רשות אישורים ברמה הבסיסית. סנכרון שוטף של מאגר אישורי הבסיס עם הרשימה שנבחרה יגן על השירותים שלכם מפני שיבושים עתידיים בשירות, עקב שינויים ב-CA, וישמור על הפעלת השירותים גם לאחר תפוגת התוקף של GTS Root R1 Cross ושל GlobalSign Root CA - R1.

כמו כן, כדאי לעיין בשאלה אני יוצר מוצר שמתחבר לשירותי Google. באילו אישורי CA צריך לסמוך? לקבלת המלצות נוספות, תוכלו למצוא בשאלות הנפוצות של GTS.

למה לא כדאי להתקין אישורי CA ברמה הבסיסית או ברמה הביניים?

אם תעשו זאת, האפליקציה שלכם עלולה להיפגע בכל שלב שבו נרשום אישור חדש או נעבור בין רשויות אישור ברמה ביניים. כל אחד מהם יכול להתרחש בכל שלב וללא הודעה מוקדמת, והוא חל באופן שווה על אישורי שרת נפרדים, כמו אלה שמסופקים על ידי maps.googleapis.com, ועל כל אחת מרשויות ה-CA הביניים, כמו GTS Root R1 Cross.

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

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

האם אפליקציות JavaScript נמצאות בסיכון לקריסה?

אישורי הבסיס של GTS כבר מוטמעים היטב ומעודכנים על ידי רוב הדפדפנים המתקדמים. החתימה הדיגיטלית מ-GMO GlobalSign אמורה להבטיח העברה חלקה גם לרוב משתמשי הקצה בדפדפנים מדור קודם. זה כולל את כל הדפדפנים הנתמכים באופן רשמי ל-Maps JavaScript API.

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

האם אפליקציות לנייד נמצאות בסיכון לקריסה?

מכשירי Android ו-Apple iOS שעדיין מקבלים עדכונים שוטפים מיצרן המכשיר צפויים להיות גם הוכחה לעתיד. רוב דגמי הטלפונים הישנים של Android כוללים לפחות את האישור GlobalSign Root CA – R1, למרות שרשימת האישורים המהימנים עשויה להשתנות בהתאם ליצרן המכשיר, לדגם המכשיר ולגרסת Android.

עם זאת, יכול להיות שהתמיכה ברשויות אישורים ברמה הבסיסית של GTS, כולל GTS Root R1, עדיין תהיה מוגבלת בגרסאות Android שקודמות ל-10.

במכשירי iOS, אפל שומרת רשימה של רשויות אישור רוט מהימנות לכל גרסה עדכנית של iOS בדפי התמיכה שלה. עם זאת, כל הגרסאות של iOS מגרסה 5 ואילך תומכות ב-GlobalSign Root CA – R1.

אישורי CA של Root GTS, כולל GTS Root R1, נתמכים החל מגרסה 12.1.3 של iOS.

לפרטים נוספים, ראו איך אפשר לבדוק את אישורי הבסיס המהימנים בטלפון הנייד שלי?.

מתי הדפדפן או מערכת ההפעלה שלי יכללו את אישורי הבסיס של Google Trust Services?

בשנים האחרונות, Google עבדה בצורה נרחבת עם כל הצדדים השלישיים העיקריים שמנהלים חבילות של אישורי Root מהימנים ונפוצים. לדוגמה: יצרני מערכות הפעלה, כמו Apple ו-Microsoft, אבל גם צוותים של Google ל-Android ול-Chrome OS, מפתחי דפדפנים כמו Mozilla, Apple ו-Microsoft, אבל גם צוות Chrome של Google; יצרני חומרה כמו טלפונים, ממירים, טלוויזיות, קונסולות משחקים, מדפסות ועוד.

לכן, סביר להניח שכל מערכת שמתוחזקת כבר תומכת באישורי GTS Root החדשים של Google, כולל GTS Root R1, ואפילו במערכות מדור קודם, בסבירות גבוהה יתמכו ב-GlobalSign Root CA - R1, שישמשו לחתימה על אישורים שהונפקו על ידי Google בשנים הבאות.

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

יכול להיות שלצדדים שלישיים נבחרים, כמו תוכנית אישורי CA של Mozilla, יש לוחות זמנים משלהם להוספת אישורים.

פתרון בעיות

איפה אפשר לקבל את הכלים הנדרשים?

קבלת curl

אם ההפצה של מערכת ההפעלה לא מספקת curl, תוכלו להוריד אותה מהכתובת https://curl.haxx.se/. אתם יכולים להוריד את המקור ולהרכיב את הכלי בעצמכם, או להוריד קובץ בינארי שעבר הידור מראש, אם יש כזה לפלטפורמה שלכם.

בתהליך קבלת OpenSSL

אם הפצת מערכת ההפעלה לא מספקת openssl, אפשר להוריד את המקור מ-https://www.openssl.org/ ולהרכיב את הכלי. רשימה של קובצי בינארי שנוצרו על ידי צדדים שלישיים זמינה בכתובת https://www.openssl.org/community/binaries.html. עם זאת, צוות OpenSSL לא תומך באף אחת מהגרסאות האלה ולא ממליץ עליהן באופן ספציפי.

הורדה של Wireshark,‏ Tshark או Tcpdump

רוב ההפצות של Linux מציעות את wireshark, את כלי שורת הפקודה tshark ואת tcpdump, אבל את הגרסאות הראשונות שעברו הידור מראש של השתיים הראשונות אפשר למצוא בכתובת https://www.wireshark.org.

תוכלו למצוא את קוד המקור ל-Tcpdump ול-LibPCAP בכתובת https://www.tcpdump.org.

אפשר למצוא מסמכי עזרה לגבי הכלים השימושיים האלה במדריך למשתמש של Wireshark, בדף העזרה של Tshark ובדף העזרה של Tcpdump, בהתאמה.

קבלת Java keytool

כלי שורת הפקודה keytool אמור להימסר עם כל גרסה של Java Development Kit‏ (JDK) או Java Runtime Environment‏ (JRE). מתקינים אותם כדי לקבל את keytool.. עם זאת, לא סביר להניח שהשימוש ב-keytool יהיה נחוץ לאימות באמצעות אישור בסיס, אלא אם האפליקציה שלכם נוצרה באמצעות Java.

מה לעשות בהפסקה זמנית בשירות בסביבת הייצור

דרך הפעולה העיקרית היא להתקין את אישורי הבסיס הנדרשים מחבילת ה-CA המהימנים של Google ברמה הבסיסית (root) באישורי הבסיס שבהם מאוחסנים האפליקציה שלכם.

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

פנייה לתמיכה של הפלטפורמה של מפות Google

פתרון בעיות ראשוני

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

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

אם הבעיה לא נפתרה ותחליטו לפנות לתמיכה של הפלטפורמה של מפות Google, תתכוננו לספק גם את המידע הבא:

איפה נמצאים השרתים המושפעים?
לאילו כתובות IP של Google קורא השירות?
אילו ממשקי API מושפעים מהבעיה הזו?
מתי בדיוק הבעיה התחילה?

הפלט של הפקודות הבאות:

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

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

שליחה של בקשת תמיכה

עליכם לפעול לפי ההוראות ליצירה של בקשת תמיכה בקטע תמיכה ומשאבים בפלטפורמה של מפות Google.

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

מהן כתובות ה-IP הציבוריות שלכם?
מהי כתובת ה-IP הציבורית של שרת ה-DNS?
אם אפשר, תיעוד של חבילות tcpdump או Wireshark של המשא ומתן ה-TLS שנכשל מול https://maps.googleapis.com/ בפורמט PCAP, באמצעות אורך snapshot גדול מספיק כדי לתעד את כל החבילה בלי לקצר אותה (למשל, שימוש ב--s0 בגרסאות ישנות יותר של tcpdump).
אם אפשר, מתעדים קטעים מהשירות שמראים את הסיבה המדויקת לכשל בחיבור TLS, עדיף בצירוף מידע מלא על שרשרת אישורי השרת.

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

פרסום בגיליון ציבורי 186840968

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

איך אפשר לקבוע את הכתובת הציבורית של ה-DNS?

ב-Linux, מריצים את הפקודה הבאה:

dig -t txt o-o.myaddr.l.google.com

ב-Windows אפשר להשתמש ב-nslookup במצב אינטראקטיבי:

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

כיצד לפרש את פלט ה-curl

הפעלת curl עם הדגלים -vvI מספקת מידע שימושי רב. ריכזנו כאן כמה הוראות לניתוח הפלט:

שורות שמתחילות ב-'*' מציגות את הפלט של המשא ומתן ב-TLS, וגם את פרטי סיום החיבור.
שורות שמתחילות ב-'>' מציגות את בקשת ה-HTTP היוצאת ש-curl שולח.
שורות שמתחילות ב-'<' מציגות את תגובת ה-HTTP שהיא מקבלת מהשרת.
אם הפרוטוקול היה HTTPS, הנוכחות של שורות '>' או '<' מרמזת על לחיצת יד מוצלחת של TLS.

נעשה שימוש בספריית TLS ובחבילת אישורי בסיס

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

הפלט ממכונת Red Hat Linux עם curl שמקושר ל-NSS יכול להכיל את השורות הבאות:

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

הפלט ממכונת Ubuntu או Debian Linux עשוי לכלול את השורות הבאות:

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

הפלט ממכונת Ubuntu או Debian Linux באמצעות קובץ PEM של אישור הבסיס של Google, שניתן באמצעות הדגל --cacert, עשוי להכיל את השורות הבאות:

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

סוכן משתמש

בקשות יוצאות מכילות את הכותרת User-Agent, שעשויה לספק מידע שימושי על curl ועל המערכת שלכם.

דוגמה ממכונת Linux של Red Hat:

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

לחיצת יד בפרוטוקול TLS שנכשלה

שורות, כמו אלה שבדוגמת הקוד הזו, מציינות שהחיבור נסגר לחיצת היד באמצע TLS בגלל אישור שרת לא מהימן. אם חסר פלט של ניפוי באגים שמתחיל ב-> או ב-<, זה סימן משמעותי לניסיון חיבור שנכשל:

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

לחיצת יד מוצלחת ב-TLS

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

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

איך להדפיס את אישורי השרת שהתקבלו בפורמט קריא לאנשים

בהנחה שהפלט בפורמט PEM, למשל הפלט מ-openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, אפשר להדפיס את האישור המוצג לפי השלבים הבאים:

מעתיקים את האישור המקודד ב-Base64 במלואו, כולל הכותרת והכותרת התחתונה:
```
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
```
לאחר מכן מבצעים את הפעולות הבאות:
```
openssl x509 -inform pem -noout -text
````
```
לאחר מכן מדביקים בטרמינל את התוכן של מאגר הנתונים הזמני.
מקישים על מקש Return.

לדוגמה, קלט ופלט, ראו בקטע איך מדפיסים אישורי PEM בפורמט קריא לבני אדם.

איך נראים אישורים של Google עם חתימה אחרת ב-OpenSSL?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

ניהול האישורים המהימנים

איך אפשר לבדוק את אישורי הבסיס המהימנים בטלפון הנייד?

אישורים מהימנים של Android

כפי שצוין בשאלה האם אפליקציות לנייד עלולות לקרוס?, החל מגרסה 4.0, משתמשי Android יכולים לאמת את רשימת האישורים המהימנים בקטע הגדרות. בטבלה הזו מוצג הנתיב המדויק בתפריט Settings (הגדרות):

גרסת Android	נתיב התפריט
1.x,‏ 2.x,‏ 3.x	לא רלוונטי
4.x, 5.x, 6.x, 7.x	הגדרות > אבטחה > פרטי כניסה מהימנים
8.x,‏ 9	הגדרות > אבטחה ומיקום > הצפנה ופרטי כניסה > פרטי כניסה מהימנים
10+	הגדרות > אבטחה > מתקדם > הצפנה ופרטי כניסה > פרטי כניסה מהימנים

בטבלה הזו מוצגת הזמינות הסבירה של אישורי root הקריטיים ביותר לכל גרסה של Android, על סמך אימות ידני באמצעות קובצי אימג' של מערכת Android Virtual Device‏ (AVD) שזמינים כרגע, וחזרה להיסטוריית הגרסאות של מאגר Git של ca-certificates של AOSP, במקרים שבהם קובצי אימג' של מערכת כבר לא היו זמינים:

גרסת Android	GTS Root R1	GlobalSign Root CA –‏ R1	GlobalSign Root R2 (בתוקף עד 15 בדצמבר 2021)
2.3,‏ 3.2,‏ 4.x,‏ 5.x,‏ 6.x,‏ 7.x,‏ 8.x,‏ 9
10+

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

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

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

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

חנות מהימנה ל-iOS

Apple לא מציגה ישירות למשתמש במכשיר את קבוצת ברירת המחדל של אישורי הבסיס המהימנים שלה. עם זאת, לחברה יש קישורים לקבוצות של רשויות אישורים ברמה הבסיסית (root) ל-iOS בגרסה 5 ואילך, במאמרי התמיכה של Apple:

עם זאת, אישורים נוספים שמותקנים במכשיר iOS אמורים להופיע בקטע הגדרות > כללי > פרופיל. אם לא מותקנים אישורים נוספים, יכול להיות שפריט התפריט פרופיל לא יוצג.

הטבלה הזו ממחישה את הזמינות של אישורי הבסיס הקריטיים ביותר בכל גרסת iOS, על סמך המקורות שלמעלה:

גרסת iOS	GTS Root R1	GlobalSign Root CA –‏ R1	GlobalSign Root R2 (בתוקף עד 15 בדצמבר 2021)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

איפה נמצא מאגר אישורי הבסיס של המערכת ואיך אפשר לעדכן אותו?

המיקום של מאגר אישורי הבסיס שמוגדר כברירת מחדל משתנה בהתאם למערכת ההפעלה ולספריית ה-SSL/TLS שבה נעשה שימוש. עם זאת, ברוב ההפצות של Linux, אישורי הבסיס שמוגדרים כברירת מחדל נמצאים באחד מהנתיבים הבאים:

/usr/local/share/ca-certificates: Debian,‏ Ubuntu,‏ גרסאות ישנות יותר של RHEL ו-CentOS
/etc/pki/ca-trust/source/anchors ו-/usr/share/pki/ca-trust-source: Fedora, גרסאות RHEL ו-CentOS חדשות יותר
/var/lib/ca-certificates: OpenSUSE

נתיבים אחרים של אישורים עשויים לכלול:

/etc/ssl/certs: Debian, Ubuntu
/etc/pki/tls/certs: RHEL, CentOS

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

אחסון אישורי בסיס של OpenSSL

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

openssl version -d

הפקודה מדפיסה את הערך OPENSSLDIR, שמתאים לספרייה ברמה העליונה, שבה נמצאות ההגדרות שלה:

OPENSSLDIR: "/usr/lib/ssl"

מאגר אישורי הבסיס נמצא בספריית המשנה certs.

ls -l /usr/lib/ssl/certs

lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs

…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

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

להוראות לקבלת openssl, ראו הקטע קבלת OpenSSL.

מאגר אישורי הבסיס של Java

אפליקציות Java עשויות להשתמש במאגר אישורי Root משלהם, שבמערכות Linux נמצא בדרך כלל ב-/etc/pki/java/cacerts או ב-/usr/share/ca-certificates-java, ואפשר לנהל אותו באמצעות הכלי של שורת הפקודה Java keytool.

כדי לייבא אישור ספציפי למאגר האישורים של Java, מריצים את הפקודה הבאה:

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

פשוט מחליפים את cert.pem בקובץ האישור התואם לכל אישור root מומלץ, את alias בכינוי ייחודי אך בעל משמעות לאישור, ואת certs.jks בקובץ של מסד נתוני האישורים שמשמש בסביבה שלכם.

למידע נוסף, קראו את המאמרים הבאים של Oracle ו-Stack Overflow:

אחסון אישורי בסיס של Mozilla NSS

כברירת מחדל, אפליקציות שמשתמשות ב-Mozilla NSS עשויות גם להשתמש במסד נתונים של אישורים ברמת המערכת, שבדרך כלל נמצא ב-/etc/pki/nssdb, או בחנות ברירת מחדל ספציפית למשתמש מתחת ל-${HOME}/.pki/nssdb.

כדי לעדכן את מסד הנתונים של NSS, צריך להשתמש בכלי certutil.

כדי לייבא קובץ אישור ספציפי למסד הנתונים של NSS, מריצים את הפקודה הבאה:

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

פשוט מחליפים את cert.pem בקובץ האישור שתואם לכל אישור בסיס מומלץ, cert-name עם כינוי משמעותי לאישור, ואת certdir בנתיב מסד הנתונים של האישורים שבו אתם משתמשים בסביבה שלכם.

מידע נוסף זמין במדריך הרשמי של NSS Tools certutil, וכן במסמכי התיעוד של מערכת ההפעלה.

מאגר אישורי הבסיס של Microsoft ‎.NET

יכול להיות שמפתחים של Windows .NET יוכלו להיעזר במאמרים הבאים של Microsoft, כדי לעדכן את מאגר אישורי הבסיס שלהם:

פורמטים של קובצי אישורים

מהו קובץ PEM?

דואר עם פרטיות משודרגת (PEM) הוא פורמט טקסט סטנדרטי למעשה לאחסון ולשליחה של אישורים קריפטוגרפיים, מפתחות וכו', שהוגדר כתקן דה פקטו ב-RFC 7468.

פורמט הקובץ עצמו קריא לבני אדם, אבל נתוני האישור הבינאריים בקידוד Base64 לא קריאים. עם זאת, מפרט ה-PEM מאפשר פליטת טקסט הסברים לפני או אחרי גוף האישור המקודד בטקסט, וכלים רבים משתמשים בתכונה הזו כדי לספק סיכום בטקסט ברור של רכיבי הנתונים הכי רלוונטיים באישור.

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

מהו קובץ crt.?

כלים שמאפשרים ייצוא של אישורים בפורמט PEM בדרך כלל משתמשים בסיומת הקובץ 'crt.' כדי לציין שהקובץ משתמש בקידוד טקסט.

מהו קובץ DER?

כללי קידוד מובהקים (DER) הם פורמט בינארי סטנדרטי לקידוד אישורים. אישורים בקובצי PEM הם בדרך כלל אישורי DER בקידוד Base64.

מהו קובץ 'cer.'?

קובץ שיוצאו עם הסיומת ‎.cer עשוי להכיל אישור בקידוד PEM, אבל בדרך כלל הוא מכיל אישור בינארי, בדרך כלל בקידוד DER. לפי המוסכמה, קובצי .cer מכילים בדרך כלל רק אישור אחד.

המערכת שלי מסרבת לייבא את כל האישורים מ-roots.pem

במערכות מסוימות, למשל, ב-Java keytool, אפשר לייבא רק אישור אחד מקובץ PEM, גם אם הוא מכיל כמה אישורים. כדי לראות איך אפשר לפצל את הקובץ קודם, אפשר לעיין בשאלה איך מחלצים אישורי SSL נפרדים מקובץ roots.pem?

איך אפשר לחלץ אישורים ספציפיים מקובץ roots.pem?

אפשר לפצל את roots.pem לאישורי הרכיבים שלו באמצעות סקריפט ה-Bash הפשוט הבא:

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

הפעולה הזו אמורה ליצור כמה קובצי PEM נפרדים, דומים לאלה שמפורטים כאן:

ls -l *.pem

-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

לאחר מכן אפשר לייבא את קובצי ה-PEM הספציפיים, כמו 02265526.pem, בנפרד או להמיר אותם לפורמט קובץ שמאגר האישורים שלכם מקבל.

איך ממירים בין קובץ PEM לפורמט שנתמך במערכת שלי

ניתן להשתמש בכלי שורת הפקודה OpenSSL של ערכת הכלים openssl כדי להמיר קבצים בין כל הפורמטים הנפוצים של קובצי האישור. בהמשך מפורטות הוראות להמרה מקובץ PEM לפורמטים הנפוצים ביותר של קובצי אישורים.

רשימה מלאה של האפשרויות הזמינות מופיעה במסמכי התיעוד הרשמי של OpenSSL Command Line Utilities.

להוראות לקבלת openssl, ראו הקטע קבלת OpenSSL.

איך ממירים קובץ PEM לפורמט DER?

באמצעות openssl אפשר לבצע את הפקודה הבאה כדי להמיר קובץ מ-PEM ל-DER:

openssl x509 -in roots.pem -outform der -out roots.der

איך ממירים קובץ PEM ל-PKCS #7?

באמצעות openssl אפשר לשלוח את הפקודה הבאה כדי להמיר קובץ מ-PEM ל-PKCS #7:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b

איך ממירים קובץ PEM ל-PKCS #12 (PFX)?

באמצעות openssl אפשר לבצע את הפקודה הבאה כדי להמיר קובץ מ-PEM ל-PKCS #12:

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

כשאתם יוצרים ארכיון PKCS #12, עליכם לספק סיסמה לקובץ. אם לא תייבאו מיד את קובץ ה-PKCS #12 למערכת, הקפידו לאחסן את הסיסמה במקום בטוח.

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

איך מייצאים אישור מ-Java Key Store כקובץ PEM?

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

keytool -v -list -keystore certs.jks

פשוט מחליפים את certs.jks בקובץ מסד הנתונים של האישורים שמשמש בסביבה שלכם. הפקודה הזו תציג גם את הכינוי של כל אישור, שתצטרכו אם תרצו לייצא אותו.

כדי לייצא אישור ספציפי בפורמט PEM, מריצים את הפקודה הבאה:

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

פשוט מחליפים את certs.jks בקובץ מסד הנתונים של האישורים שנמצא בסביבה שלכם, ומספקים alias ו-alias.pem שמתאימים לאישור שרוצים לייצא.

מידע נוסף זמין במדריך Java Platform, מידע על כלים במהדורה הרגילה: keytool.

איך מייצאים אישורים מאישורי הבסיס של NSS שמאחסנים כקובץ PEM?

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

certutil -L -d certdir

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

כדי לייצא אישור ספציפי בפורמט PEM, מריצים את הפקודה הבאה:

certutil -L -n cert-name -a -d certdir > cert.pem

פשוט מחליפים את certdir בנתיב של מסד נתוני האישורים שבו נעשה שימוש בסביבה, ומספקים את cert-name ו-cert.pem התואמים לאישור שרוצים לייצא.

למידע נוסף, ניתן לעיין במדריך הרשמי של NSS Tools certutil, וגם במסמכים של מערכת ההפעלה.

איך להדפיס אישורי PEM בפורמט קריא (לבני אדם)

בדוגמאות הבאות נניח שיש לכם את הקובץ GTS_Root_R1.pem עם התוכן הבא:

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----

הדפסת קובצי אישורים באמצעות OpenSSL

ביצוע הפקודה

openssl x509 -in GTS_Root_R1.pem -text

הפלט אמור להיראות כך:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

להוראות לקבלת openssl, ראו הקטע קבלת OpenSSL.

הדפסת אישורים באמצעות כלי המפתח Java

ביצוע הפקודה הבאה

keytool -printcert -file GTS_Root_R1.pem

הפלט אמור להיראות כך:

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

להוראות איך להשיג את keytool, ראו קבלת כלי מפתח של Java.

איך אפשר לראות אילו אישורים מותקנים במאגר אישורי הבסיס שלי?

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

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

קובץ ה-PEM יכול להיות מתויג כראוי, ולספק מידע קריא על רשות האישורים המשויכת (דוגמה מחבילת רשות האישורים הבסיסית המהימנה של Google):

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

הקובץ יכול להכיל גם רק את החלק של האישור. במקרים כאלה, שם הקובץ, למשל GTS_Root_R1.pem, עשוי לתאר לאיזו רשות אישורים האישור שייך. בנוסף, מחרוזת האישור בין האסימונים -----BEGIN CERTIFICATE----- ו------END CERTIFICATE----- מבטיחה שתהיה ייחודית לכל CA.

עם זאת, גם אם אין לכם את הכלים שצוינו למעלה, מכיוון שכל אישור בחבילת ה-CA המהימנה של Google ברמה הבסיסית (root) יש תווית נכונה, תוכלו לבצע התאמה אמינה בין ה-CA ברמה הבסיסית (root) מהחבילה לבין אלה ששמורות אישורי הבסיס שמאוחסנים ב-Issuer או באמצעות השוואה בין מחרוזות של אישורי קובץ PEM.

דפדפני אינטרנט יכולים להשתמש במאגר אישורי בסיס משלהם, או להסתמך על ברירת המחדל שסופקה על ידי מערכת ההפעלה. עם זאת, כל הדפדפנים המודרניים אמורים לאפשר ניהול, או לפחות, צפייה בקבוצה של רשויות האישורים ברמה הבסיסית (root) שהם סומכים עליהם. פרטים נוספים זמינים בשאלה האם אפליקציות JavaScript נמצאות בסיכון לקריסה?

להוראות ספציפיות לטלפון נייד, ראו את השאלה הנפרדת איך בודקים את אישורי הבסיס המהימנים בטלפון הנייד?.

נספח

צריכים מידע נוסף?

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

כל מקור מידע אחר כולל השאלות הנפוצות האלה עשוי להיות לא עדכני או לא מדויק מסיבה אחרת, ואין להתייחס אליו כמקור מידע מהימן. עם זאת, עדיין תוכלו למצוא מידע שימושי ברבות מקהילות השאלות והתשובות של Stack Exchange, וגם באתרים כמו AdamW on Linux and more וconfirm blog, בין היתר.

מומלץ גם לעיין בשאלות הנפוצות על Google Trust Services.

לפרטים נוספים על נושאים מתקדמים, כמו הצמדת אישורים, אפשר לעיין בפרויקט Open Web Application Security Project (OWASP) באישור ובהצמדה של מפתח ציבורי במאמר וPinning Cheat Cheat Sheet מידע מועיל. להוראות ספציפיות ל-Android, תוכלו לקרוא את מסמכי ההכשרה הרשמיים של Android לגבי אבטחה ופרטיות אבטחה עם HTTPS ו-SSL. כדי לקבל מידע נוסף על הצמדת אישורים לעומת הצמדת מפתחות ציבוריים ב-Android, מומלץ לקרוא את הפוסט של Matthew Dolan בבלוג Android Security: SSL Pinning.

מסמך ההדרכה בנושא שיטות מומלצות לשמירה על אבטחה ופרטיות ב-הגדרת אבטחת רשת והפוסט בבלוג של JeroenHD והפוסט בבלוג Android 7 Nougat ורשויות האישורים מספקים מידע נוסף על ניהול אישורים מהימנים נוספים ב-Android.

ברשימה המלאה של רשויות אישורים ברמה הבסיסית (root) שמהימנות על ידי AOSP, תוכלו לעיין במאגר ca-certificates של Git. לגרסאות שמבוססות על פורקים לא רשמיים של Android, למשל LineageOS, יש לעיין במאגרים המתאימים שסופקו על ידי ספק מערכת ההפעלה.