תאריכים והערת עריכה: המקור פורסם ב־. התרגום והבדיקה הטכנית עודכנו ב־. נשמר מלוא מבנה המאמר, עם תיקוני דיוק מתועדים. פקודות ותצורות לא הורצו; יש להתאים אותן לסביבה ולגרסה לפני שימוש.
מקור המאמר: לקריאת הגרסה המקורית באנגלית.
מבוא לשקיפות תעודות — Certificate Transparency
כאשר דפדפן מתחבר לאתר ב־HTTPS, הוא בודק תעודת TLS כחלק מאימות השרת. אבל איך יודעים אם רשות אישורים הנפיקה תעודה שלא הייתה צריכה להנפיק? שקיפות תעודות — Certificate Transparency (CT) — מאפשרת לפרסם תעודות ביומנים הניתנים לביקורת. כך אפשר לנטר הנפקות ולבדוק גם את התנהגות היומנים, בלי להסתמך רק על אמון ברשויות האישורים.
שקיפות תעודות במבט מהיר
הבעיה ש־CT מצמצם: לקחים ממקרי אמון היסטוריים
רשויות אישורים הן גורמים המנפיקים תעודות דיגיטליות. דפדפנים ומערכות הפעלה מחזיקים מאגר של עוגני אמון. חתימה של רשות מוכרת אינה מספיקה לבדה: נבדקים גם שרשרת, שם, תוקף, ייעוד ומדיניות. תיעוד רשמי של יצרני דפדפנים מציג לאורך השנים מקרים שבהם נדרשו חסימה או הסרת אמון; אלה מדגישים את חשיבות השקיפות והביקורת.
- DigiNotar, 2011: Google תיעדה חסימת תעודה לא מורשית והסרת אמון ברשויות שהפעילה DigiNotar. הדיווח המקורי ומועדי הפעולות.
- Comodo, 2011: Mozilla פרסמה דיווח על תשע תעודות לא מורשות לאחר פגיעה בשותף רישום של הרשות. המקרה מדגים את חשיבות הבקרה גם על גורמים המשתתפים בתהליך ההנפקה. הדיווח המקורי ומועדי הפעולות.
- TURKTRUST — דיווח בינואר 2013 על חסימות בדצמבר 2012: Google פרסמה כי נחסמו תעודות ביניים שנמסרו בטעות במקום תעודות שרת רגילות, לפי המידע שמסרה הרשות. ההבחנה בין סמכות של רשות ביניים לבין תעודת שרת חשובה למודל האמון. הדיווח המקורי ומועדי הפעולות.
- Symantec, 2017–2018: Chrome פרסמה ויישמה בשלבים תוכנית להסרת אמון בתשתית PKI הוותיקה של Symantec. הדיווח המקורי ומועדי הפעולות.
CT מוסיף יכולת לניטור שיטתי של הנפקות, אך אינו מבטיח שכל הנפקה שגויה תתגלה בזמן, אינו מונע אותה מראש ואינו מחליף טיפול וביטול תעודות.
ציר הזמן של Certificate Transparency
איך שקיפות תעודות פועלת
שלב 1: הגשת התעודה ליומן
רשות אישורים או מגיש אחר שולחים תעודה או קדם־תעודה ליומני CT. מספר היומנים וגיוון המפעילים הנדרשים נקבעים במדיניות הדפדפן או התוכנית הרלוונטית, ולא בכלל אחיד של הפרוטוקול. היומן בודק את תנאי הקבלה ומחזיר חותמת זמן חתומה לתעודה — Signed Certificate Timestamp (SCT).
שלב 2: חותמות זמן חתומות — SCT
SCT היא קבלה קריפטוגרפית והתחייבות לשלב את הרשומה ביומן בתוך Maximum Merge Delay (MMD), זמן ההשהיה המרבי שהיומן מפרסם. היא כוללת פרטים כגון מזהה יומן, זמן, הרחבות וחתימה הנקשרת לתוכן שהוגש; אין לתאר אותה כסתם שדה של גיבוב תעודה. היא יכולה להגיע כחלק מהתעודה או באמצעות מנגנון TLS מתאים. תמיכה בהעברה דרך OCSP stapling תלויה במדיניות ובגרסת הלקוח; אין להניח שהיא נתמכת בכל דפדפן עדכני.
שלב 3: הכללה בעץ מרקל
יומני CT משתמשים בעץ גיבוב מסוג מרקל לארגון הרשומות. גיבובי העלים והצמתים הפנימיים מובילים לגיבוב שורש. מבנה ראש עץ חתום — Signed Tree Head (STH) כולל את גיבוב השורש לצד נתונים כגון גודל העץ, זמן וחתימה. הוכחות הכללה ועקביות מסייעות לבדוק את היומן; מבנה הנתונים אינו הופך מפעיל זדוני לבלתי אפשרי. הוכחת הכללה דורשת מספר גיבובים מסדר O(log n).
מבנה סכמטי של עץ מרקל ביומן CT
שלב 4: ניטור וביקורת
מערכות ניטור סורקות יומנים או אינדקסים כדי לזהות תעודות המתאימות לדומיינים שבמעקב. בין הכלים המוכרים: crt.sh ו־CertSpotter; זמינות השירות והכיסוי מחייבים בדיקה. רכיבי ביקורת בודקים הוכחות הכללה ועקביות. גילוי מצב שבו יומן מציג תמונות שונות למשתמשים שונים — split view — דורש מנגנוני השוואה ותצפיות מתאימים; בדיקה מקומית אחת אינה מספיקה תמיד.
מערכת יומני ה־CT
דוגמאות למפעילים ולמשפחות יומנים
| מפעיל | שמות יומנים לדוגמה | מעמד ברשימה הזאת | הערות |
|---|---|---|---|
| Xenon, Argon, Solera | דוגמה; המעמד משתנה | מפעילת יומנים מוקדמת; קבלה תלויה במדיניות הדפדפן | |
| Cloudflare | Nimbus | דוגמה; המעמד משתנה | השם אינו הוכחה שיומן מסוים עדיין מקבל רשומות |
| DigiCert | Wyvern, Sphinx | דוגמה; המעמד משתנה | רשות אישורים המפעילה גם יומנים |
| Sectigo | Sabre, Mammoth | דוגמה; המעמד משתנה | יש לבדוק מזהה יומן, מפעיל ותקופת פעילות |
| Let's Encrypt | Oak — היסטורי; Sycamore, Willow | דוגמה; המעמד משתנה | יומנים עשויים לקבל גם תעודות מרשויות אחרות לפי רשימת השורשים |
| TrustAsia | log2026a, log2026b | דוגמה; המעמד משתנה | בדקו את מצב היומן ברשימת הדפדפן הנוכחית; אין לייחס למפעיל זה את Twig |
שמות הדוגמה נבדקו מול רשימת היומנים המוכרים ל־Chrome מ־24 באוקטובר 2026; עצם ההופעה ברשימה אינה מעידה שיומן או חלוקה תקופתית שלו עדיין מאושרים להנפקה. Twig הוא יומן בדיקה של Let’s Encrypt, לא של TrustAsia. שירותי Oak הישנים הגיעו לסוף חייהם; בדקו את דפי המפעיל ואת מדיניות הדפדפן.
אכיפת דפדפנים: מדיניות CT של Chrome
מדיניות Chrome העדכנית מבחינה בין SCT המוטמעים בתעודה ובין SCT המועברים ב־TLS, ובוחנת גם את מצב היומן וגיוון המפעילים. בתעודות עם SCT מוטמעים נדרשים לפחות שני יומנים לתוקף של עד 180 יום ושלושה מעבר לכך, לצד יתר התנאים. אין כלל עדכני גורף של ארבעה SCT לתעודות ארוכות. ל־Apple מדיניות נפרדת; בדקו תמיד את המקורות הרשמיים והגרסה הרלוונטית במקום להעתיק טבלת דרישות ישנה.
כלים לניטור CT
crt.sh
כלי חיפוש ציבורי המופעל בידי Sectigo, המאפשר חיפוש תעודות לפי מאפיינים כגון דומיין וטביעת אצבע. הוא שימושי לבדיקות ולחקירה, אך אין לראות באינדקס שלו הוכחה שכל תעודה שהונפקה אי פעם נכללת בו או שהמידע תמיד מגיע ללא עיכוב.
CertSpotter
שירות של SSLMate לניטור תעודות ולשליחת התראות על הנפקות לדומיינים שבמעקב. בדקו את התוכנית, המחיר והכיסוי העדכניים לפני שימוש. ניטור יכול לסייע לגלות הנפקה לא צפויה, אך אינו מבטיח גילוי לפני ניצול לרעה.
certstream
משפחת כלים וזרמי אירועים המאפשרים לעבד תצפיות מיומני CT. הדוגמה הבאה היא פסאודו־קוד לעיבוד הודעות, לא API מאומת של חבילת npm מסוימת ולא הבטחה לכיסוי כל היומנים:
// פסאודו־קוד לעיבוד הודעות; לא ממשק מאומת של חבילת npm.
// הגדירו ספק זרם, פורמט נתונים וטיפול בניתוקים לפי התיעוד שלו.
function processCertificateUpdate(message) {
if (message.message_type !== "certificate_update") return;
const cert = message.data?.leaf_cert;
if (!cert) return;
const domains = cert.all_domains ?? [];
// subject הוא נושא התעודה, לא המנפיק שלה.
console.log("דומיינים שנצפו:", domains);
}
// חברו את הפונקציה למקור אירועים מאומת; כיסוי הזרם עשוי להיות חלקי.
שאילתות ישירות ליומנים: ממשק HTTP של RFC 6962
# דוגמה היסטורית ל־API של RFC 6962; כתובת argon2024 אינה המלצה ליומן פעיל
# בדקו רשימת יומנים עדכנית לפני בחירת נקודת קצה
# קבלת ראש עץ חתום
GET https://ct.googleapis.com/logs/us1/argon2024/ct/v1/get-sth
# קבלת הוכחת הכללה עבור גיבוב עלה לפי הגדרת הפרוטוקול
GET https://ct.googleapis.com/logs/us1/argon2024/ct/v1/get-proof-by-hash
?hash={base64-leaf-hash}&tree_size={size}
# קריאת רשומות בטווח — בדוגמה עשר רשומות
GET https://ct.googleapis.com/logs/us1/argon2024/ct/v1/get-entries?start=0&end=9
CT ב־.NET: בדיקת נוכחות הרחבת SCT
דפדפנים אוכפים מדיניות CT משלהם. ביישום מותאם אישית, בדיקת קיומה של הרחבת SCT היא בדיקה אבחונית בלבד: היא אינה מאמתת חתימות, מצב יומן, גיוון מפעילים, תזמון או עמידה במדיניות. אין להחליף בה אימות TLS תקין.
using System;
using System.Net.Http;
using System.Net.Security;
using System.Security.Cryptography.X509Certificates;
// בדיקת נוכחות הרחבה בלבד — אינה אימות תאימות ל־CT.
static bool HasEmbeddedScts(X509Certificate2 cert) =>
cert.Extensions["1.3.6.1.4.1.11129.2.4.2"] is not null;
using var handler = new HttpClientHandler {
ServerCertificateCustomValidationCallback = (request, cert, chain, errors) => {
if (cert is not null)
Console.WriteLine($"נמצאה הרחבת SCT מוטמעת: {HasEmbeddedScts(cert)}");
// לא עוקפים שגיאות תעודה; גם הצלחה כאן אינה אכיפת CT מלאה.
return errors == SslPolicyErrors.None;
}
};
using var client = new HttpClient(handler);
using var response = await client.GetAsync("https://example.com");
שיקולי פרטיות
רישום ציבורי חושף שמות ומידע הכלולים בתעודות שנרשמו. הוא אינו מכיל בהכרח כל דומיין המשתמש ב־TLS: תעודות פרטיות אינן כפופות אוטומטית לאותה מדיניות. אפשר להשתמש ביומנים גם למיפוי שירותים ותתי־דומיינים. הימנעו מהכנסת שמות רגישים לתעודות ציבוריות; בחנו רשות פרטית לתשתית פנימית. תעודת wildcard מצמצמת פירוט של שמות אך אינה פתרון פרטיות כולל, ויש לה השלכות ניהול מפתחות משלה.
CT v1, CT v2 ו־Static CT API: שלושה מושגים שונים
CT v1 — RFC 6962
- גיבוב עצי מרקל באמצעות SHA-256
- ראש עץ חתום והוכחות הכללה ועקביות
- רשימות קבלה נקבעות במדיניות הלקוחות
- ממשקי HTTP/JSON מוגדרים
CT v2 — RFC 9162
- מבנים מעודכנים וגמישות קריפטוגרפית
- שינויים במבני הוכחות ובפריטי היומן
- מפרט ניסויי; אינו זהה לפריסה בכל דפדפן
- Static CT API הוא מפרט נפרד, לא תכונת RFC 9162
- גילוי split view עדיין מחייב תצפיות וביקורת מתאימות
כיווני התפתחות בשקיפות תעודות
- תעודות עץ מרקל — Merkle Tree Certificates: תחום של תכנון ותקינה המנסה לשלב הנפקה והוכחות מבוססות עצים במבנה התעודה. אין להניח שהחליף את X.509 בכל הרשת; בדקו את מצב הטיוטות והמימושים העדכניים.
- שקיפות תעודות בעידן פוסט־קוונטי: מערכות חתימה ויומנים צריכות להיערך לאפשרות של מחשבים קוונטיים המסוגלים לפגוע באלגוריתמים קלאסיים. המעבר דורש תכנון פרוטוקול, בחירת אלגוריתמים ותאימות; אינו שינוי אוטומטי של שם האלגוריתם.
- בדיקות CT בצד הלקוח: דפדפנים כבר בודקים SCT. כיווני מחקר ופיתוח כוללים הרחבת יכולות אימות היומן והשוואת תצפיות, מעבר לבדיקת חותמת בלבד.
- הקשר בין DNS CAA לבין CT: CAA מסייע לבעלי דומיין לקבוע אילו רשויות רשאיות להנפיק עבורם. אין להציג את בחירת יומני CT באמצעות CAA כיכולת כללית ומחייבת קיימת; הצעות להרחבות דורשות מפרט ותמיכה מפורשים.
המערכת שסביב Certificate Transparency
סיכום
CT מוסיף שקיפות ואפשרות לביקורת בתשתית המפתח הציבורי של הרשת. הוא מסייע לזהות הנפקות חשודות ולבחון יומנים, אך אינו מונע כל כשל ואינו מבטיח גילוי מלא או מיידי. נטרו דומיינים שבאחריותכם, הבדילו בין SCT לבין הוכחת הכללה, ואל תסיקו תאימות למדיניות מעצם קיומה של הרחבה. עקבו אחר מדיניות הדפדפנים והרשימות העדכניות של היומנים.
מקורות להבהרות ולעדכונים
התרגום כולל תיקוני דיוק והבהרות על בסיס המקורות הרשמיים הבאים, שנבדקו ב־25 באוקטובר 2026.
- security.googleblog.com: update-on-attempted-man-in-middle
- www.rfc-editor.org: rfc9162
- googlechrome.github.io: ct_policy
- googlechrome.github.io: log_list
- c2sp.org: static-ct-api
- blog.mozilla.org:
- security.googleblog.com: enhancing-digital-certificate-security
- www.chromium.org:
- support.apple.com: 103214
רשימת היומנים המוכרים ל־Chrome; דף יומני השקיפות של Let’s Encrypt.