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

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

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

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

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

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

מידע כללי

מה קורה?

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

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

לאחר השלב הראשון, אבטחת ה-TLS של שירותי הפלטפורמה של מפות Google מובטחת על ידי GS Root R2, רשות אישורים שורש (CA) ידועה מאוד ומהימנה על ידי Google, ש-Google רכשה מ-GMO GlobalSign כדי להקל על המעבר לרשויות האישורים ברמה הבסיסית של 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 כבר יכירו (או את שניהם) מבין רשויות האישורים הבסיסיות המהימנות האלה, ולא יושפעו בכלל מהשלב השני של המעבר.

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

עליכם לאמת את המערכות שלכם אם התנאים הבאים מתקיימים:

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

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

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

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

סיכום טכני

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

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

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

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

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

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

תוכנית השקה כללית לכל אחד משירותי Google

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

האם אפליקציות לנייד עלולות להיקטע?

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

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

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

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

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

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

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

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

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

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

פתרון בעיות

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

אחזור של curl

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

קבלת OpenSSL

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

קבלת Wireshark, Tshark או Tcpdump

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

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

ניתן למצוא תיעוד עבור הכלים השימושיים האלה במדריך למשתמש של Wireshark, בדף האדם של Tshark ובדף האדם ב-Tcpdump, בהתאמה.

קבלת מפתח Java

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

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

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

  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.demo.pki.goog/; \
openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

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

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

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

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

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

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

פרסום בנושא ציבורי מספר 186840968

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

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

ב-Linux, אתם יכולים להריץ את הפקודה הבאה:

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

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

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

איך לפרש את פלט ה-curl

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

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

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

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

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

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

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

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

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

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

סוכן משתמש

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

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

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

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

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

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

לחיצת יד בפרוטוקול TLS בוצעה בהצלחה

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

  • מעתיקים את האישור בקידוד Base 64 במלואו, כולל כותרת עליונה וכותרת תחתונה:

    -----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.demo.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.demo.pki.goog

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

---
…

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

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

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

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

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

בטבלה הבאה אפשר לראות את הזמינות הסבירה של אישורי הבסיס הקריטיים ביותר בכל גרסה של Android, על סמך אימות ידני באמצעות תמונות מערכת של Android במכשיר וירטואלי (AVD) שזמינות כרגע, תוך התייחסות לאישורי ה-CA של AOSP היסטוריית הגרסאות של מאגר Git, שבה תמונות המערכת כבר לא היו זמינות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הנכון!

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

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

openssl version -d

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

OPENSSLDIR: "/usr/lib/ssl"

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

ls -l /usr/lib/ssl/certs

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

ls -l /etc/ssl/certs

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

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

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

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

אפליקציות Java עשויות להשתמש במאגר אישורי בסיס משלהן, שבמערכות 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

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

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

מהו קובץ PEM?

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

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

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

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

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

מהו קובץ DER?

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

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

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

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

במערכות מסוימות, למשל, Java keytool יכול לייבא רק אישור אחד מקובץ PEM, גם אם הוא מכיל כמה אישורים. ראו את השאלה איך מחלצים אישורים בודדים מ-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: keytool.

כיצד מייצאים אישורים ממאגר אישורי הבסיס של NSS כקובץ PEM?

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

certutil -L -d certdir

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

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

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

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

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

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

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

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

הנפקת הפקודה

openssl x509 -in GTS_Root_R1.pem -text

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

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

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

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

הנפקת הפקודה הבאה

keytool -printcert -file GTS_Root_R1.pem

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

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

Extensions:

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

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

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

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

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

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

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

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

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

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

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

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

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

נספח

זקוקים למידע נוסף?

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

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

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

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

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

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