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

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

סקירה מפורטת יותר זמינה במאמר מה זה?.

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

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

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

מידע כללי

מה זה?

סיכום: אם לא תפעלו לפי ההנחיות שבכתובת https://pki.goog/faq/#connecting-to-google, סביר להניח שתיתקלו בעתיד בהפסקות שירות שקשורות לאישור.

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

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

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

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

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

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

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

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

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

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

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

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

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

סיכום טכני

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

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

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

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

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

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

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

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

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

אישורי בסיס חדשים יפורסמו בכתובת https://pki.goog/updates/. אפשר להירשם לפיד RSS כדי לקבל התראות על עדכונים. אנחנו מודיעים רק על שורשים חדשים. שינויים בשרשרת האישורים שמתרחשים בין שורשי אישורים ותיקים לא מפורסמים ויכולים לקרות בכל שלב. כדי להבטיח חיבורים מהימנים ל-Google, אסור להצמיד לאף שורש או ביניים יחיד, וצריך לבטוח בכל קבוצת השורשים של Google שמפורטים בכתובת https://pki.goog/faq/#connecting-to-google.

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

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

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

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

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

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

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

בודקים את סביבת האפליקציה מול כל השורשים בקטע Root CAs (רשויות אישורים בסיסיות) בכתובת https://pki.goog/repository/

בדרך כלל, המערכת תהיה תואמת לשינויים ב-CA הבסיסי אם:

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

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

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

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

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

הוראות להורדת curl מופיעות בקטע הורדת curl בהמשך.

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

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

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

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

הדוגמה הזו היא ל-GTS R1, צריך לבצע בדיקה מול כל שורשי GTS.

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; \

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

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

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

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

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

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

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

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

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

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

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

דברים שכדאי לשים לב אליהם

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

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

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

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

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

דרישות והמלצות נוספות מפורטות בקטעים What are the recommended requirements for a TLS client to communicate with Google?‎ ו-Why do many Google Services still allow connections using TLS 1.0 and TLS 1.1?‎ בשאלות הנפוצות בנושא GTS.

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

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

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

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

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

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

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

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

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

בנוסף, כדאי לעיין בשאלה I'm building a product that connects to Google services. אילו אישורים של רשות אישורים צריך להגדיר כמהימנים? בשאלות הנפוצות בנושא GTS מופיעות המלצות נוספות.

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

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

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

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

האם יש סיכון שיישומים של JavaScript ייפגעו?

אישורי הבסיס של GTS כבר מוטמעים היטב ומהימנים ברוב הדפדפנים המודרניים, והחתימה הצולבת מ-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 עבדה באופן נרחב עם כל הצדדים השלישיים הגדולים שמנהלים חבילות של אישורי בסיס שנעשה בהם שימוש נרחב ושהם מהימנים. לדוגמה: יצרני מערכות הפעלה כמו Apple ו-Microsoft, אבל גם צוותי Android ו-ChromeOS של Google; מפתחי דפדפנים כמו Mozilla,‏ Apple ו-Microsoft, אבל גם צוות Chrome של Google; יצרני חומרה כמו טלפונים, ממירים, טלוויזיות, קונסולות משחקים ומדפסות, אלה רק כמה דוגמאות.

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

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

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

פתרון בעיות

איפה אפשר להשיג את הכלים הדרושים?

איך יוצרים תלתלים

אם הפצת מערכת ההפעלה שלכם לא מספקת את 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, בדף ה-man של Tshark ובדף ה-man של Tcpdump.

קבלת כלי המפתחות של Java

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

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

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

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

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

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

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

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

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

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

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

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

    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;
curl -vvI https://good.gtsr2.demosite.pki.goog/; \
openssl s_client -connect good.gtsr2.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr3.demosite.pki.goog/; \
openssl s_client -connect good.gtsr3.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr4.demosite.pki.goog/; \
openssl s_client -connect good.gtsr4.demosite.pki.goog:443 -showcerts </dev/null; \

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

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

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

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

  • מהן כתובות ה-IP הציבוריות שלך?
  • מהי כתובת ה-IP הציבורית של שרת ה-DNS שלך?
  • אם אפשר, כדאי לצרף קובץ PCAP של לכידת מנות tcpdump או Wireshark של משא ומתן TLS שנכשל מול https://maps.googleapis.com/, באמצעות אורך תמונה מספיק גדול כדי ללכוד את המנה כולה בלי לחתוך אותה (למשל, באמצעות -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 מדפיסה גם את מאגר אישורי הבסיס (root) שנעשה בו שימוש, אבל הפלט המדויק עשוי להשתנות בהתאם למערכת, כמו שמוצג כאן.

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

דוגמה ממכונת 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 של מטען הייעודי (payload) מועברת בהצלחה דרך חיבור מוצפן ב-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?

{# disableFinding(LINE_OVER_80)}

…
---
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+ הגדרות > אבטחה > מתקדם > הצפנה ופרטי כניסה > פרטי כניסה מהימנים

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

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

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

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

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

חברת אפל לא מציגה ישירות למשתמשים במכשירים ניידים את קבוצת אישורי הבסיס המהימנים שמוגדרת כברירת מחדל. במאמרי התמיכה של אפל יש קישורים לקבוצות של רשויות אישורים מהימנות בסיסיות ל-iOS מגרסה 5 ואילך:

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

  • ‫/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 בקובץ האישור שמתאים לכל אישור בסיסי מומלץ, את 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 יכולים להיעזר לפחות במאמרים הבאים של מיקרוסופט כדי לעדכן את מאגר אישורי הבסיס שלהם:

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

מהו קובץ PEM?

‫Privacy-Enhanced Mail (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, גם אם הקובץ מכיל כמה אישורים. כדי לראות איך אפשר לפצל את הקובץ קודם, אפשר לעיין בשאלה How do I extract individual certificates from 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.

הוראות להשגת openssl מופיעות בקטע השגת OpenSSL.

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

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

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 {: .external}.

איך מייצאים אישורים ממאגר האישורים הבסיסיים של 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 CA):

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

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

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

נספח

רוצה לקבל מידע נוסף?

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

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

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

כדי לקבל מבוא קצר להצפנה, ל-PKI, לאישורים ולשרשראות אישורים, מומלץ לצפות ברשימת הסרטונים PKI Bootcamp ב-YouTube של פול טרנר.

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

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

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