לקריאת המאמר באנגלית: English
פרסום המקור באנגלית: 24 באוקטובר 2026. בדיקת התרגום לעברית: 25 באוקטובר 2026.
שגיאת TLS יכולה להעיד שהלקוח אינו מצליח לבסס אמון בתעודה, שהתעודה שייכת לשם מארח אחר, או שכמה בדיקות נכשלו יחד. החלפת תעודות באקראי מקשה להבין את התקלה. התחילו בהפרדה בין הבדיקות שנכשלו, ואז שחזרו את הכשל בסביבה שבה האפליקציה באמת פועלת.
רשימת הבדיקה הזאת מיועדת לשירותי HTTPS ולמפתחים שבודקים תקלות בפריסה. כל שמות המארחים, הכתובות, שמות הקבצים והתוצאות שמופיעים כאן הם להמחשה, ולא תוצאות של בדיקה בסביבת ייצור. החליפו אותם ביעדים שלכם שיש לכם הרשאה לבדוק.
מעדיפים סקירה חזותית קצרה? צפו בסרטון ההסבר המוקלט על TLS, שאורכו 92 שניות. הוא מציג אמון בשרשרת, בדיקות שם מארח ו־SNI באמצעות תרשימים מקוריים וכתוביות באנגלית. בהמשך המאמר מופיעות פקודות האבחון וההסתייגויות.
1. מפרידים בין אימות השרשרת לאימות שם המארח
אימות השרשרת בודק אם אפשר לקשר את תעודת הקצה שהוצגה לעוגן אמון מוגדר באמצעות תעודות מנפיקות שעומדות בדרישות. האימות בוחן גם מאפיינים כגון תקופות תוקף, חתימות ושימושים מותרים. גם תעודה שעדיין לא פג תוקפה יכולה להיכשל בבדיקות האלה. ראו את סקירת אימות התעודות של OpenSSL.
אימות שם המארח בודק אם תעודת הקצה מזהה את השירות שאליו הלקוח התכוון לפנות. ב־HTTPS, בדקו את שמות ה־DNS בהרחבת Subject Alternative Name, או SAN. אל תסתמכו על התאמה בשדה Common Name: RFC 9525 מגדיר זהות שירות המבוססת על SAN ואינו מתיר זיהוי באמצעות Common Name.
| התצפית | מה לבדוק קודם | אילו ראיות לאסוף |
|---|---|---|
| לא ניתן למצוא מנפיק | תעודת ביניים חסרה או עוגן אמון שאינו זמין | התעודות שהוצגו והגדרות האמון של הלקוח |
| אי־התאמה בשם המארח | תעודה, כתובת URL או שיוך מארח וירטואלי שאינם נכונים | שם המארח המבוקש, SNI ושמות SAN בתעודת הקצה |
| התוקף פג או טרם התחיל | תאריכי התעודה ושעון הלקוח | מיקום התעודה שנכשלה בשרשרת |
| הדפדפן מצליח והאפליקציה נכשלת | הבדלים בהגדרות הלקוח | סביבת הריצה, מאגר האמון, שרת הפרוקסי ומסלול הרשת |
| לא התקבלה תעודה מהצד השני | כשל לפני אימות התעודה | פורט, קישוריות ונתוני אבחון של לחיצת היד |
אלה נקודות התחלה, לא אבחנות חד־משמעיות. תעדו את השגיאה המלאה לפני שמשנים דבר, כולל חריגות פנימיות ומועד הכשל. בפריסה אחת יכולים להתקיים כמה ליקויים.
2. משחזרים את החיבור עם שם המארח המיועד
במעטפת פקודות שבה מותקן OpenSSL, הריצו:
openssl s_client -connect api.example.com:443 -servername api.example.com -verify_hostname api.example.com -verify_return_error -showcertsלמתגים יש תפקידים שונים:
-connectבוחר את יעד הרשת.-servernameשולח Server Name Indication, או SNI, ומאפשר לשרת משותף לבחור תעודה.-verify_hostnameמבקש בדיקת שם מארח.-verify_return_errorעוצר את לחיצת היד כשיש שגיאות באימות התעודה.-showcertsמציג את התעודות שהשרת סיפק.
אל תסירו את מתגי האימות. בלעדיהם, לקוח האבחון של OpenSSL עשוי להמשיך גם כשיש שגיאות אימות בתעודה. נוסף על כך, רשימת התעודות המוצגת היא מה שהשרת שלח, ולא הוכחה לכך שהשרשרת אומתה בהצלחה. ההתנהגות הזאת מתועדת במדריך s_client.
לאחר שתיעדתם את פלט לחיצת היד והאימות, סיימו את הפקודה האינטראקטיבית באמצעות Ctrl+C. בדיקה מוצלחת ב־OpenSSL מבססת תוצאה עבור ההגדרה המסוימת הזאת של OpenSSL, ולא עבור כל דפדפן או אפליקציה. תעדו את פלט openssl version ובדקו את העזרה המקומית של הפקודה אם אפשרות מסוימת אינה זמינה.
3. בודקים את התעודה שהשרת מציג בפועל
שמרו את בלוק התעודה הראשון מהפלט, כולל שורות BEGIN ו־END CERTIFICATE, בשם leaf.pem. בדקו אותו מקומית:
openssl x509 -in leaf.pem -noout -subject -issuer -dates -ext subjectAltName
openssl x509 -in leaf.pem -noout -fingerprint -sha256הפקודות מדפיסות מטא־נתונים בלי לחשוף מפתח פרטי. טביעת האצבע עוזרת להשוות בין התעודות שמציגות נקודות קצה שונות. אפשרויות הבדיקה הזמינות מתוארות במדריך OpenSSL x509.
למשל, תעודה שמכילה רק DNS:www.example.com אינה מזהה את api.example.com. תבנית כללית כמו *.example.com מכסה תווית שמאלית אחת, ולא את example.com או את v2.api.example.com. התחברות באמצעות כתובת IP דורשת SAN תואם מסוג כתובת IP, ולא רק SAN מסוג DNS שמכיל טקסט דומה. כללי הזהות האלה מופיעים בנהלי ההתאמה של RFC 9525.
אם התעודה שגויה, בדקו את הנקודה שבה מסתיים חיבור ה־TLS: פרוקסי הפוך, CDN, מאזן עומסים או שרת אינטרנט. תקנו את השיוך שלה או פרסו תעודה שמכסה את השם המיועד. התקנת תעודות שורש מהימנות נוספות אינה יכולה לתקן אי־התאמה בשם המארח.
4. בודקים את תעודות הביניים
בפריסה טיפוסית נשלחת תעודת הקצה ואחריה תעודות הביניים הנחוצות. תעודת השורש מופצת בדרך כלל באמצעות הגדרות האמון של הלקוח; שליחת שורש אינה גורמת ללקוח לתת בו אמון. מפרט הודעת התעודה של TLS 1.3 מתאר את רשימת התעודות ומתיר להשמיט את תעודת עוגן האמון.
כדי לבדוק מקומית את בניית השרשרת, שמרו את בלוקי ה־PEM של תעודות הביניים בקובץ intermediates.pem. השיגו את trusted-roots.pem ממקור אמון שאושר באופן עצמאי, ולא על ידי הענקת אמון לתעודות שנאספו מהשרת שבו אירע הכשל.
openssl verify -show_chain -purpose sslserver -verify_hostname api.example.com -CAfile trusted-roots.pem -no-CApath -no-CAstore -untrusted intermediates.pem leaf.pemפקודת OpenSSL 3.x הזאת משתמשת בקובץ CA מפורש ומשביתה את תיקיית ה־CA ואת המאגר המוגדרים כברירת מחדל. הקלט -untrusted מספק מועמדות לבניית השרשרת; הוא אינו מכריז שתעודות הביניים האלה מהימנות. OpenSSL verify מדווח על העומק שבו נכשל האימות: אפס הוא תעודת הקצה, אחת היא המנפיקה שלה, וכן הלאה.
אם הוספת תעודת הביניים הנכונה גורמת לבדיקה לעבור, בדקו אם השרת השמיט אותה. פרסו את השרשרת שסיפקה רשות האישורים בנקודת סיום ה־TLS. אל תוסיפו את תעודת הקצה למאגר שורשי האמון כדי להשתיק את השגיאה.
5. בודקים הבדלים ייחודיים ל־Windows
ב־Windows, ייצאו את תעודת הקצה לקובץ Leaf.cer שמכיל תעודה בלבד, והשתמשו במעטפת אבחון עם הרשאות מנהל:
certutil -verify -urlfetch .\Leaf.cer
certutil -URL .\Leaf.cerהפקודה הראשונה בודקת אימות שרשרת ואחזור מקוון. השנייה פותחת את URL Retrieval Tool לבדיקת כתובות הקשורות לתעודה. הבדיקות האלה עשויות לפנות לשירותי מנפיקים וביטול תעודות, ולכן יש להשתמש בגישת רשת מאושרת. אף אחת מהפקודות, כפי שהן מוצגות, אינה מוכיחה התאמה לשם המארח של HTTPS.
נקודת קצה לבדיקת ביטול שאי אפשר להגיע אליה אינה מעידה שהתעודה בוטלה. השוו גישת DNS, פרוקסי וחומת אש מהלקוח המושפע. הנחיות מיקרוסופט לאימות נתיב תעודות ממליצות גם לבדוק תחת זהות ההרצה של האפליקציה ולהבחין בין תוצאות מהמטמון לאחזור חדש. אל תנקו את מטמון התעודות של משתמש בסביבת ייצור רק כדי לקבל בדיקה ״נקייה״ יותר.
6. מסיימים בבדיקה חוזרת מתוך האפליקציה
חזרו על הבקשה המקורית מתוך האפליקציה שנכשלה, עם מדיניות האימות הרגילה שלה. ודאו את שם המארח המיועד, התעודה שנפרסה, השרשרת הנדרשת והגדרות האמון הרלוונטיות. אם רק חלק מהבקשות נכשלות, השוו בין התעודות שמציגים שרתי הקצה האחוריים או מסלולי הרשת השונים.
שמרו תיעוד קצר של האירוע: השגיאה, נקודת הקצה, טביעת האצבע של התעודה, הבדיקה שנכשלה, שינוי התצורה והתוצאה הסופית באפליקציה. לעולם אל תפתרו את התקלה באמצעות קבלה של כל תעודה, השבתת אימות שם המארח או כיבוי בדיקות ביטול. היעלמות האזהרה אינה ראיה מספקת לכך שזהות הצד השני בחיבור מאומתת כראוי.
לקריאה נוספת
לדוגמת PowerShell שמונה תעודות בשרשרת שנבנתה מקומית, ראו הדפסת כל תעודות השרשרת ב־PowerShell. ראו במניית התעודות פעולה לבדיקה, לא תחליף לבחינת תוצאות האימות או שם המארח של HTTPS.
לאימות שרתי דואר המבוסס על DNS חתום, ראו DANE ו־TLSA: איך DNSSEC יכול לאמת שרת דואר. המאמר מסביר מדוע אימות תעבורת SMTP ובדיקות התעודה בדפדפן הם החלטות יישום שונות.