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

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

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

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

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

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

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

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

מידע כללי

על מה מדובר?

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

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

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

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

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

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

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

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

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

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

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

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

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

סיכום טכני

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) של Google.

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

מה כדאי לשים לב אליו

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מומלץ גם לעיין בשאלה אני יוצר מוצר שמתחבר לשירותי Google. אילו אישורי CA צריך להאמין להם? בשאלות הנפוצות בנושא GTS.

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

אם תעשו זאת, האפליקציה שלכם עלולה להיפגע בכל שלב שבו נרשום אישור חדש או נעבור בין רשויות אישורים ביניים. כל אחת מהפעולות האלה עשויה להתרחש בכל שלב וללא הודעה מוקדמת, והיא חלה באופן שווה על אישורי שרת ספציפיים, כמו אלה שמוצגים על ידי maps.googleapis.com, וגם על כל רשות אישורים ביניים שלנו, כמו 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.

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

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

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

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

לכן, סביר מאוד שכל מערכת שמתוחזקת כרגע כבר תומכת ברשות אישורים ברמה הבסיסית החדשה של GTS של 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. גרסאות מורכבות מראש של שני הכלים הראשונים ל-OS אחרים זמינות בכתובת 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 לאימות של אישורי Root, אלא אם האפליקציה שלכם פותחה באמצעות Java.

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

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

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

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

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

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

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

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

הפעלת 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 של אישור root של Google שצוין באמצעות הדגל --cacert עשוי להכיל את השורות הבאות:

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

סוכן משתמש

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

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

> 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, משתמשי טלפונים ניידים יכולים לאמת את רשימת האישורים המהימנים בקטע הגדרות. בטבלה הזו מוצג הנתיב המדויק בתפריט הגדרות:

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

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

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

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

מאגר האישורים של iOS

Apple לא מציגה ישירות למשתמש הסלולרי את קבוצת ברירת המחדל של אישורי הבסיס המהימנים, אבל יש לחברה קישורים לקבוצות של רשויות אישורי הבסיס המהימנות ל-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, אישורי root שמוגדרים כברירת מחדל נמצאים באחת מהדרכים הבאות:

/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?

Distinguished Encoding Rules (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, Standard Edition Tools Reference: keytool.

איך מייצאים אישורים מאחסון האישורים ברמה הבסיסית (root) של 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

הרצת הפקודה הבאה

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 keytool.

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

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

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

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

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

נספח

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

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

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

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

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

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

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