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

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

במסמך הזה מופיעים הקטעים הבאים:

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

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

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

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

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

מידע כללי

מה קורה?

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

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

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

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

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

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

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

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

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

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

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

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

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

סיכום טכני

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בודקים את סביבת האפליקציה מול נקודות הקצה (endpoints) הבאות לבדיקה:

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

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

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

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

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

יכול להיות ששני כלי שורת הפקודה 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 ברמה הבסיסית

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

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

איך ומתי תימשך המיגרציה של רשות האישורים הבסיסית (CA) ב-Google?

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

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

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

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

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

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

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

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

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

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

מה צריך לחפש

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פתרון בעיות

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

קבלת curl

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

קבלת OpenSSL

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

קבלת Wireshark, Tshark או Tcpdump

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

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

ניתן למצוא תיעוד לכלים השימושיים האלה Wireshark User's Guide, בדף האיש של Tshark ובדף אדם של Tcpdump, בהתאמה.

קבלת כלי המקשים של Java

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

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

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

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

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

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

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

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

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

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

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

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.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, באמצעות אורך תמונת מצב גדול מספיק כדי לצלם את כל החבילה ללא קיצור הטקסט (למשל, שימוש ב--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 בפורמט קריא לאנשים.

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

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

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

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

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

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

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

למרות ש-Apple לא מציגה באופן ישיר את קבוצת ברירת המחדל של אישורי בסיס מהימנים למשתמש הטלפון הנייד, לחברה יש קישורים לקבוצות של רשויות אישורים ברמה הבסיסית (root) המהימנות ל-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, שניתן לנהל באמצעות keytool של Java כלי שורת הפקודה (CLI).

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

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

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

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

מהו קובץ PEM?

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

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

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

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

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

מהו קובץ DER?

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

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

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

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

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

איך אפשר לחלץ אישורים בודדים מ-Roots.pem?

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

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

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

ls -l *.pem

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

keytool -v -list -keystore certs.jks

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

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

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

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

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

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

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

certutil -L -d certdir

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

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

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

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

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

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

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

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

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

ביצוע הפקודה

openssl x509 -in GTS_Root_R1.pem -text

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

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

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

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

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

keytool -printcert -file GTS_Root_R1.pem

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

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

Extensions:

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

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

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

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

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

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

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

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

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

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

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

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

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

נספח

יש לך צורך במידע נוסף?

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

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

כדאי לעיין גם שאלות נפוצות על Google Trust Services

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

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

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