כיצד לפתור שגיאות באישור TLS ודפי HTTPS שלא נטענים

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

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

מהי תעודת TLS/SSL ומדוע חיבור ה-HTTPS מתנתק?

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

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

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

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

הסיבות הנפוצות ביותר לשגיאות של אישורי TLS ו-HTTPS שלא נטענות

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

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

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

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

שגיאות SSL/TLS אופייניות ומה המשמעות האמיתית שלהן

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

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

עוד קלאסיקה היא ERR_CERT_COMMON_NAME_INVALIDהתראה זו מופיעה כאשר שם הדומיין בתעודה אינו תואם לדומיין שאליו אתה מנסה לגשת. זוהי אזהרה חמורה מכיוון זה יכול להיות סימפטום של מתקפת Man-in-the-Middle או תצורת שרת גרועה. (לדוגמה, הצגת אותו אישור עבור מספר דומיינים ללא רשתות SAN מתאימות).

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

קשור קשר הדוק הוא רשת::ERR_CERT_DATE_INVALIDזה מצביע על בעיית תאריך: או שהתעודה פגה, או ששעון המחשב של המשתמש אינו תואם את תקופת התוקף. תעודות TLS הן בעלות תאריך; אם אתה מחוץ לתקופה זו, הדפדפן מניח שלא ניתן לסמוך עליו.

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

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

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

שגיאות תוכן מעורב ואתרי HTTPS "לא מאובטחים לחלוטין"

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

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

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

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

במקרה הספציפי של יישומים מודרניים, יש צורך גם לבחון מחדש URI של הפניות OAuth (למשל, מגוגל) המצביעות אל localhost oa HTTPשילוב זה עלול לגרום לשגיאות מוזרות, אזהרות בלתי צפויות לגבי אישורים (כגון אישור חתום עצמית מ-"localhost"), ויתרה מכך, להשפיע רק על משתמש או סביבה ספציפיים.

בעיות נפוצות בהתקנה ובתוקף אישורים

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

אם האישור אינו תואם את הדומיין (לדוגמה, הוא מכסה רק את mydomain.com אך אתה ניגש ל-www.mydomain.com), הדפדפן יסמן את החיבור כלא מאובטח. בעת רכישה או יצירת תעודה, עליך לוודא שאתה כולל את כל הווריאציות הנדרשות (עם ובלי www, תת-דומיינים וכו')., או להשתמש ב-SANs עם תווים כלליים (wildcard) כאשר מתאים.

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

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

בפלטפורמות מנוהלות כמו Azure App Service או Vercel, גורמים נוספים נכנסים לתמונה. הרשאות על מאגר המפתחות או שיוכים בין אישורים ודומיינים מותאמים אישיתאם לשירות המנהל את האישורים אין הרשאות מספיקות ב-Key Vault, או אם לא בוצע סנכרון אוטומטי, היישום ימשיך להשתמש באישור הישן.

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

הפניות HTTP/HTTPS, דומיינים ו-DNS: מקורות לשגיאות בלתי נראות

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

כדי שאתר ייראה תמיד בטוח, הדבר הרגיל הוא כפיית HTTPS באמצעות כללי הפניה (למשל, ב-.htaccess, Nginx, לוח הבקרה של האירוח או פרוקסי הפוך)אם כללים אלה מוגדרים בצורה שגויה, ניתן ליצור לולאות בין http:// ל-https:// או בין www לדף שאינו www. התוצאה האופיינית היא: ERR_TOO_MANY_REDIRECTS או דף שפשוט לא מוצג.

עליך גם לדאוג לאופן שבו הדומיין הוגדר בספק ה-DNS. בעת הפניית דומיין לאפליקציית אינטרנט או לשירות ענן, עליך להשתמש ברשומות A, CNAME ו-TXT בצורה נכונה.שימוש גם ברשומת A וגם ברשומת CNAME עבור אותו מחשב מארח, שכחת קובץ ה-TXT לאימות, או אי עדכון כתובת ה-IP בעת החלפת שרתים ייצרו שגיאות פתרון (DNS_PROBE_FINISHED_NXDOMAIN ואחרות).

בנוסף, ה-DNS לא מתעדכן באופן מיידילכל רשומה יש ערך TTL (Time To Live), המציין כמה זמן רזולוטורים יכולים לשמור אותה במטמון. אם שינית לאחרונה ספקי אירוח או כתובות IP, זה נורמלי שחלק מהמשתמשים עדיין יראו את האתר הישן או שגיאת 404 במשך מספר שעות. כלים כמו WhatsMyDNS יכולים לעזור לוודא שההפצה מתקדמת כראוי.

פעמים אחרות, הבעיה טמונה בדפדפן או במערכת של המשתמש. DNS מקומי ומטמון דפדפן יכולים לשמור כתובות ישנות.נקה את המטמון, רוקן את ה-DNS (לדוגמה, עם ipconfig / flushdns (ב-Windows) או הפעלה מחדש של הנתב בדרך כלל מספיקים כדי להבטיח שהדומיין יזוהה כהלכה בשרת הנכון.

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

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

אם אתם עובדים עם פלטפורמות מנוהלות (Azure, Vercel, cPanel וכו'), ישנן שגיאות שמותנות על ידי התשתית עצמה. האופן שבו אתם משייכים אישורים ליישומים, מגבלות רכישה וסוג התוכנית - כל אלה משפיעים על האופן והמועד שבו תוכלו להשתמש ב-TLS..

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

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

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

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

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

כיצד לתקן שגיאות חיבור SSL מצד המשתמש

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

הדבר הראשון שצריך לעשות הוא סקירה התאריך והשעה של המערכת שלךעיכוב של כמה דקות בלבד מספיק כדי שאישורים שנראים תקפים ייחשבו כתוקפים שפג תוקפם או "עדיין לא תקפים". הפעלת סנכרון אוטומטי של תאריך ושעה (ב-Windows, macOS, Android או iOS) בדרך כלל פותרת מספר לא מבוטל של שגיאות חיבור SSL בבת אחת.

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

במחשבים שולחניים, זה רעיון טוב מחיקת תעודות ה-SSL "slate" או תעודות המאוחסנות במטמון במערכתב-Windows, ניתן לעשות זאת דרך אפשרויות אינטרנט, בכרטיסייה תוכן, באמצעות כפתור נקה מצב SSL. ב-macOS, ניתן להשתמש בגישה באמצעות מחזיקי מפתחות כדי לאתר אישורים המשויכים לדומיין ספציפי ולמחוק אותם ידנית.

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

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

שיטות עבודה מומלצות למניעת שגיאות באישור TLS

מעבר לכיבוי שריפות, מה שבאמת מעניין הוא שהטעויות האלה כמעט ולא מתרחשות. מניעת בעיות בתעודות TLS כרוכה בשמירה על עדכניות ומעקב מקיף אחר תעודות, שרתים ו-DNS..

הנקודה הראשונה ברורה מאליה אך קל לשכוח אותה: חדשו אישורים לפני שפג תוקפם, ואם אפשר, אוטומציה של התהליךעם Let's Encrypt והרבה רשויות אישורים מודרניות, קל להגדיר חידושים אוטומטיים, כך שלא תצטרכו לזכור כל כמה חודשים. למרות זאת, מומלץ לעקוב אחר תאריכי תפוגה ולקבל התראות.

זה גם מכריע שמרו על השרת ופרוטוקולי האבטחה מעודכניםיש להשבית את SSLv3, TLS 1.0 ופרוטוקולים מיושנים אחרים, ויש להשתמש ב-TLS 1.2 ו-1.3 במקום זאת, יחד עם חבילות הצפנה מודרניות ומפתחות חזקים מספיק. ניתן להשתמש במדריכים כגון Mozilla SSL Configuration כמקור עזר להגדרת השרת עם רמת אבטחה מקובלת.

לא פחות חשוב הוא יש לבדוק מעת לעת את כללי ההפניה בין HTTP ל-HTTPS ובין גרסאות דומיין.שינוי שנראה תמים (כלל חדש ב-.htaccess, פרוקסי CDN, WAF אינטרפוזד) יכול להכניס לולאות או לשלוח תנועה לגרסה הלא מאובטחת. סקירת הפניות וביצוע בדיקות עומס מלא לאחר כל שינוי הן נוהג טוב.

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

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

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