כפיית HTTPS על כל האתר: מעבר מתעודה מותקנת לכפייה מלאה

תעודה מותקנת לבדה לא מספיקה. מדריך לכפיית HTTPS עם redirect 301, החלפת קישורים ב-DB ובדיקת mixed content.

תעודת SSL מותקנת בלבד אומרת שהאתר 'יכול' לרוץ ב-HTTPS - אבל אם מבקרים שמגיעים דרך http:// לא מועברים אוטומטית ל-https://, חלק מהתנועה עדיין עובר לא מוצפנת. כפיית HTTPS אמיתית דורשת שלושה שלבים: כתובת האתר ב-WordPress, redirect ברמת השרת, וקישורים פנימיים ב-DB.

למה זה משנה

כשהאתר נגיש גם ב-HTTP וגם ב-HTTPS, יש לכך מספר השפעות חמורות: אבטחה - סיסמאות, עוגיות session ומידע אישי שעוברים דרך HTTP ניתנים לציתות בכל רשת באמצע (Wi-Fi ציבורי, ISP, רשת תאגידית עם proxy). תוקף שיושב בנקודת Wi-Fi בנמל תעופה יכול לקרוא את ה-cookie של אדמין שמתחבר דרך HTTP ולגנוב את הסשן. SEO - Google מתייחס לאותו תוכן ב-http:// וב-https:// כשני URLs נפרדים. הדבר מפצל את ה-PageRank, יוצר תוכן כפול, ועלול להוריד את הדירוג. בנוסף, Google מאז 2014 מעדיף אתרי HTTPS באלגוריתם הדירוג. חוויית משתמש - דפדפנים מודרניים (Chrome, Firefox, Safari) מסמנים אתרי HTTP כ-'Not Secure' עם איקון אזהרה בולט. במובייל, חלק מהדפדפנים אפילו מציגים אזהרה גדולה לפני שמטעינים. שיעור הנטישה של אתרים שמסומנים 'Not Secure' עולה ב-15-25%.

איך לזהות

הבדיקה מבצעת בקשת HTTP ל-http://example.com ובודקת האם מתקבלת תשובה 301 או 302 ל-https://. אם התשובה היא 200 (התוכן נטען על HTTP) - הבדיקה אדומה. ידנית:

curl -I http://example.com
אמור להחזיר 'HTTP/1.1 301 Moved Permanently' ו-'Location: https://example.com/'. גם בקליטה ידנית: גש לאתר עם http:// בדפדפן - הכתובת אמורה להשתנות אוטומטית ל-https://.

איך לתקן

  1. בלוח הבקרה > הגדרות > כללי, ודא ש-WordPress Address ו-Site Address שניהם מתחילים ב-https://.
  2. הוסף redirect 301 ברמת השרת. Apache ב-.htaccess:
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  3. Nginx:
    server {
        listen 80;
        server_name example.com www.example.com;
        return 301 https://$server_name$request_uri;
    }
  4. החלף קישורים פנימיים שנשמרו ב-DB עם http://. השיטה הקלה: התקן את התוסף 'Better Search Replace'. בעמוד התוסף הגדר: search='http://example.com', replace='https://example.com', בחר את כל הטבלאות, סמן 'Run as dry run' קודם.
  5. אם הכמות נראית סבירה (אלפים, לא מיליונים), הסר את ה-dry run והרץ אמיתי.
  6. חלופה: WP-CLI
    wp search-replace "http://example.com" "https://example.com" --all-tables-with-prefix --skip-columns=guid
  7. בדוק את האתר במצב גלישה פרטית. פתח DevTools (F12) > Console - אזהרות 'Mixed Content' אמורות להיעלם.
  8. אם נשארו - הם בקובצי תבנית או תוסף. חפש בקוד מחרוזות 'http://' שצריכות להיות 'https://'.

טעויות נפוצות

אל תסתפק בהגדרת WP_HOME ו-WP_SITEURL ב-wp-config.php בלי redirect ברמת השרת - מבקרים שמגיעים ישירות ל-http://example.com/some/page עדיין יקבלו תוכן על HTTP. אל תשתמש ב-Search Replace רגיל של MySQL (sed או UPDATE) - הוא לא מטפל ב-serialized data, ואופציות שמורות בפורמט serialized יישברו. אל תפעיל את התוסף 'Really Simple SSL' כפתרון קבוע - הוא טוב לתיקון מהיר אבל מוסיף עומס; אחרי שתיקנת ב-DB, הסר אותו. אל תכלול את עמודת guid ב-search-replace - זה משבר RSS feeds.

בדיקה לאחר תיקון

curl -I http://example.com אמור להחזיר 301 ל-https. אתר 'Why No Padlock?' (whynopadlock.com) סורק mixed content. SSL Labs (ssllabs.com/ssltest/) נותן ציון מלא לקונפיגורציה. בדוק 5-10 דפים שונים, גם בפנים האדמין, כדי לוודא שאין משאבים שעדיין נטענים על http.

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