HTTPS за WordPress сайт изглежда като една настройка, но на практика са няколко. Сертификатът може да е наред, а браузърът пак да предупреждава, че връзката не е защитена. Или сайтът да се отваря, но да липсват картинки, стилове и бутони. Причината може да е смесеното съдържание, тоест страницата идва по HTTPS, а част от нея още се зарежда по HTTP.
В това ръководство ще минем през всичко поред. Проверявате сертификата, сменяте адресите и добавяте едно пренасочване. После намирате смесеното съдържание в браузъра и го поправяте в базата данни. Накрая ще видите как Cloudflare може да предизвика цикъл и дали Ви трябва HSTS.
Как да проверите дали сертификатът работи
В cPanel сертификатите се издават от AutoSSL, ако хостингът го е включил. Според документацията на cPanel той издава сертификати за 90 дни и се опитва да ги поднови сам, преди да изтекат.
Отворете в cPanel Security > SSL/TLS Status. Филтрите там показват кои домейни са Active, Expired, Expiring Soon, Unsecured или с проблем на AutoSSL, а колоната Certificate Status съдържа грешката на AutoSSL, ако има такава.
Проверете адреса с www и без www. AutoSSL добавя към сертификата и варианта с www, но само ако и той мине проверката за собственост, иначе www остава без сертификат. Като пример за проблем cPanel дава домейн, който не се разрешава до IPv4 адрес в интернет. Как се насочва домейнът към хостинга, вижте в ръководството за регистрация на .bg домейн.
Сертификата можете да проверите и от командния ред. Командата показва за кой домейн е, кой го е издал и до кога важи.
# От Вашия компютър или cPanel > Terminal, само чете
echo | openssl s_client -connect primer.bg:443 \
-servername primer.bg 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
Параметърът -servername указва за кой сайт питате, защото на един IP адрес може да има много сайтове. Датата в реда notAfter е краят на срока. Повторете командата за www.primer.bg.
Как да смените адресите на WordPress на HTTPS
WordPress пази два адреса. Site Address (URL) е адресът, който посетителите пишат в браузъра, а WordPress Address (URL) е мястото на файловете на ядрото. Според документацията на WordPress и двата трябва да започват с https:// и да нямат наклонена черта накрая.
Най-лесно е през Tools > Site Health. От WordPress 5.7, когато сървърът отговаря по HTTPS, в раздела Status има бутон „Update your site to use HTTPS“ (в админа на български „Обновяване на сайта за ползване на HTTPS“). Той сменя двата адреса наведнъж, проверява дали WordPress разпознава сайта като HTTPS и ако не го разпознава, връща старите адреси.
Бутонът е за обичайния случай, когато двата адреса са еднакви. Не се показва, ако в wp-config.php са зададени WP_HOME или WP_SITEURL, както и ако WordPress не открие работещ HTTPS.
Другият начин е през Settings > General. Сменете двете полета от http:// на https:// и запазете. Ако полетата не могат да се редактират, адресите са зададени в wp-config.php и трябва да ги промените там.
// wp-config.php, над "That's all, stop editing!"
define( 'WP_HOME', 'https://primer.bg' );
define( 'WP_SITEURL', 'https://primer.bg' );
Ако сте сменили адресите, преди HTTPS да заработи, и не можете да влезете, сложете в тези редове старите стойности с http:// и ги махнете, когато сертификатът е наред.
За да работят входът и админът само по HTTPS, добавете в wp-config.php define( 'FORCE_SSL_ADMIN', true );, когато SSL вече работи. Константата трябва да е в wp-config.php, а не в плъгин.
Как да пренасочите HTTP към HTTPS в .htaccess
Новите адреси не оправят старите връзки от търсачки и от други сайтове, които още водят към http://primer.bg. За тях сървърът трябва да отговаря с пренасочване, а в cPanel това е едно правило в .htaccess.
Файлът е в папката на сайта, до wp-config.php. Скрит е, затова във File Manager включете Show Hidden Files от Settings. Добавете редовете над блока # BEGIN WordPress, не вътре в него, защото WordPress пренаписва този блок, когато смените постоянните връзки.
# .htaccess, над # BEGIN WordPress
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Според документацията на Apache %{HTTPS} е on само при SSL/TLS, затова правилото пренасочва всичко останало към същия адрес с https и код 301, а пътят и параметрите се запазват.
Проверете с две команди. Първата трябва да върне 301 и ред Location с https. Втората брои пренасочванията и показва крайния адрес, като очакваният резултат е https://primer.bg/ 200 1. Ако curl спре със съобщението Maximum (50) redirects followed, имате цикъл.
# От Вашия компютър, само чете
curl -I http://primer.bg
curl -sIL -o /dev/null \
-w '%{url_effective} %{http_code} %{num_redirects}\n' \
http://primer.bg
Ако плъгин или правило в Cloudflare вече пренасочват към HTTPS, не добавяйте второ. Две пренасочвания могат да си противоречат и да предизвикат цикъл.
Как да намерите смесеното съдържание в браузъра
Смесено съдържание има, когато страница, заредена по HTTPS, зарежда ресурси по HTTP. Според MDN такъв ресурс може да бъде прочетен или променен по пътя, а най-опасни са скриптовете, защото могат да променят всяка част от страницата. Браузърите реагират по два начина. Опитват се да заредят картинките, аудиото и видеото по HTTPS, а ако ги няма там, не ги показват. Скриптовете, стиловете и iframe-овете направо се блокират, затова страницата губи оформлението си или бутони.
Отворете сайта по HTTPS и натиснете Ctrl + Shift + J (на Mac Cmd + Option + J), за да отворите конзолата в Chrome. Презаредете страницата и потърсете съобщенията за Mixed Content. Firefox и Safari също ги показват в конзолата. Във филтъра на панела Network можете да напишете mixed-content:all.
Конзолата показва само текущата страница. Проверете началната страница, един запис, страница с форма и, ако имате магазин, продукт, количката и плащането. Без инструменти можете да отворите view-source:https://primer.bg и да потърсите http://. Връзките <a href> обикновено не са смесено съдържание, затова гледайте src, srcset и href на link.
Смесеното съдържание идва от стари записи с пълни HTTP адреси, от настройки на теми и плъгини, от файловете на темата и от чужди ресурси, които още се зареждат по HTTP.
От версия 5.7 WordPress сам заменя стария HTTP адрес на сайта при показване, но само в съдържанието на записите и страниците, в откъсите им, в текстовите джаджи и в допълнителния CSS, и то само ако адресите са сменени на сайт, който вече има съдържание, и са на същия домейн. Всичко друго остава непроменено, например http://www.primer.bg, когато основният адрес е без www.
Как да замените HTTP адресите в базата данни
Истинската поправка е адресите в базата да започват с https://. Не ги заменяйте със заявка REPLACE в phpMyAdmin. WordPress пази част от данните в сериализиран вид, с дължината на всеки низ, и ако адресът се промени, без да се коригира дължината, данните се повреждат. WP-CLI и плъгинът по-долу се справят правилно със сериализираните данни.
После пуснете замяната само като проба. Параметърът --dry-run изпълнява цялата операция и показва отчет, но не записва нищо, а --skip-columns=guid пропуска колоната guid, която според документацията на WordPress никога не бива да се променя. Адресът е такъв, какъвто е бил в Site Address преди смяната, с www или без. Повече за WP-CLI ще намерите в ръководството за командите му.
# cPanel > Terminal, в папката на сайта, само проба
wp search-replace 'http://primer.bg' 'https://primer.bg' \
--skip-columns=guid --report-changed-only --dry-run
В отчета ще видите кои таблици и колони ще се променят и колко замени ще има. Ако числата изглеждат разумни, пуснете същата команда без --dry-run.
# cPanel > Terminal, в папката на сайта, записва замените
wp search-replace 'http://primer.bg' 'https://primer.bg' \
--skip-columns=guid --report-changed-only
Ако плъгин пази данните като JSON, адресът там е с екранирани наклонени черти. Търсете 'http:\/\/primer.bg' и заменяйте с 'https:\/\/primer.bg', пак първо с --dry-run. После изчистете кеша на плъгина и на Cloudflare и презаредете страницата.
Ако нямате терминал
Инсталирайте плъгина Better Search Replace от wordpress.org. Ще го намерите в менюто Tools. Той се справя със сериализираните данни във всички таблици и има проба (dry run), която показва колко полета ще се променят, преди да запише. Въвеждате http://primer.bg, замествате с https://primer.bg, пускате пробата и чак тогава записвате. Ако има избор за GUID, оставете го изключен. Страницата му предупреждава, че грешен низ може да повреди базата, затова и тук е нужен бекъп. После изтрийте плъгина.
Защо Cloudflare в режим Flexible води до цикъл от пренасочвания?
Cloudflare поддържа две връзки, от посетителя до Cloudflare и от Cloudflare до Вашия сървър. Режимът на шифроване определя как работи втората. При Full и Full (strict) Cloudflare се свързва със сървъра по протокола на посетителя.
| Режим | Посетител до Cloudflare | Cloudflare до сървъра |
|---|---|---|
| Flexible | HTTPS | HTTP |
| Full | HTTPS | HTTPS, сертификатът не се проверява |
| Full (strict) | HTTPS | HTTPS, сертификатът се проверява |
При Flexible Cloudflare праща заявките към сървъра по HTTP. Ако .htaccess или плъгин пренасочва всяка HTTP заявка към HTTPS, цикълът е готов. Посетителят иска HTTPS, Cloudflare пита сървъра по HTTP, сървърът го праща пак към HTTPS и така до грешката ERR_TOO_MANY_REDIRECTS. Подобен цикъл описва и WordPress за FORCE_SSL_ADMIN зад прокси, което поема SSL вместо сайта.
Решението е Full (strict). Този режим изисква на сървъра да има валиден, неизтекъл сертификат от доверен издател, който съвпада с името, а AutoSSL издава точно такъв. Избирате го в Cloudflare от SSL/TLS, страница Overview. Ако видите грешка 526, първо проверете сертификата на сървъра, защото най-вероятно не отговаря на изискванията.
Cloudflare препоръчва Full или Full (strict), когато е възможно, и не препоръчва Flexible за приложения с вход и лични данни, а WordPress има вход. Ако в таблото виждате Automatic SSL/TLS, проверете какъв режим е избрал.
Внимавайте и с Edge Certificates. Always Use HTTPS пренасочва в Cloudflare, а Cloudflare препоръчва в този случай да не пренасочвате към HTTPS и на сървъра, защото може да се получи цикъл. Изберете едно място. Automatic HTTPS Rewrites скрива част от смесеното съдържание на ходу, но базата остава каквато е.
Трябва ли Ви HSTS?
HSTS е заглавие на отговора, с което сървърът казва на браузъра да ползва само HTTPS за този сайт през следващите max-age секунди. Според MDN, докато срокът тече, браузърът сам превръща HTTP в HTTPS и не позволява на посетителя да продължи, ако сертификатът е невалиден. HTTPS работи и без него, затова HSTS не е задължителен.
Същото, което го прави полезен, го прави и рисков. Ако махнете HTTPS или сертификатът изтече, докато политиката е в сила, сайтът ще е недостъпен до края на срока ѝ. Затова започнете с кратък срок. Не включвайте includeSubDomains и preload, освен ако знаете, че всеки поддомейн работи по HTTPS. Cloudflare предупреждава, че без HTTPS поддомейните стават недостъпни, а според MDN preload изисква срок от поне една година. Първата стъпка е правило в .htaccess, под пренасочването, със срок от пет минути.
# .htaccess, под правилото за пренасочване
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=300" env=HTTPS
</IfModule>
Правилото праща заглавието само по HTTPS, защото браузърите го игнорират по HTTP, а 300 секунди са пет минути. Проверете с curl -sI https://primer.bg дали заглавието се връща. Ако няколко дни всичко е наред, увеличавайте срока постепенно. За да спрете политиката, задайте max-age=0. Ако Cloudflare е пред сайта, включете HSTS само на едно място.
Чеклист
-
https://primer.bgиhttps://www.primer.bgсе отварят без предупреждение. - Site Address и WordPress Address са с
https://и без наклонена черта накрая. -
http://primer.bgводи с едно пренасочване (301) доhttps://primer.bg, без цикъл. - Имам бекъп на базата, а замяната е минала първо с
--dry-runи без колоната guid. - Конзолата не показва Mixed Content на нито една от проверените страници, а кешът е изчистен.
- Cloudflare е в режим Full (strict), ако е пред сайта, и пренасочването е само на едно място.
- HSTS е включен само съзнателно и с кратък срок.
Ако не искате да се занимавате с това
Не при всеки сайт се налага да пипате базата. Ако сайтът е нов и няма стари записи, стигат двата адреса и пренасочването.
Ако сайтът е спрял след смяната на адресите или не откривате откъде идва смесеното съдържание, опишете какво виждате във формата за запитване. SSL е включен и в поддръжката на WordPress, където и да е хостнат сайтът Ви.
Често задавани въпроси
Защо браузърът казва, че сайтът не е защитен, макар да има SSL сертификат?
Най-честата причина е смесено съдържание, тоест страница, която идва по HTTPS, а част от нея още се зарежда по HTTP. Браузърите блокират скриптовете, стиловете и iframe по HTTP, така че страницата губи оформлението или бутоните си, а изображения, звук и видео се търсят по HTTPS и ако ги няма там, не се зареждат. Друга причина може да е, че сертификатът не покрива варианта с www.
Как да проверя SSL сертификата на сайта в cPanel?
Отворете Security > SSL/TLS Status в cPanel, където филтрите показват кои домейни са Active, Expired, Expiring Soon, Unsecured или имат проблем с AutoSSL. Проверете адреса със и без www, защото AutoSSL добавя варианта с www само ако и той мине проверката за собственост. Според документацията на cPanel AutoSSL прави сертификати за 90 дни и се опитва да ги смени сам преди изтичането.
Как да сменя адреса на WordPress от HTTP на HTTPS?
Най-лесно е от Tools > Site Health, където от WordPress 5.7 има бутон „Update your site to use HTTPS“, който сменя двата адреса наведнъж и ги връща, ако нещо не е наред. Другият начин е Settings > General, където двата адреса трябва да започват с https:// и да нямат наклонена черта накрая. Не сменяйте адресите, докато https:// не се отваря без предупреждение.
Как да пренасоча HTTP към HTTPS в .htaccess?
Добавете едно правило за пренасочване с код 301 в .htaccess, над блока # BEGIN WordPress, а не вътре в него, защото WordPress пренаписва блока при смяна на постоянните връзки. Преди това направете копие на файла, защото грешка в един ред може да спре сайта. Ако плъгин или правило в Cloudflare вече пренасочва към HTTPS, не добавяйте второ, защото двете могат да създадат цикъл.
Как да намеря смесеното съдържание на сайта?
Отворете сайта по HTTPS и натиснете Ctrl + Shift + J (на Mac Cmd + Option + J), за да видите конзолата в Chrome, после презаредете страницата и потърсете съобщенията Mixed Content. Конзолата показва само текущата страница, така че минете през началната страница, публикация, форма и, ако имате магазин, продукт, количката и поръчката. Без инструменти отворете view-source: пред адреса и търсете http:// в src, srcset и href на link.
Мога ли да сменя HTTP адресите в базата с phpMyAdmin?
Не правете замяна с REPLACE в phpMyAdmin. WordPress пази част от данните сериализирани, с дължината на всеки низ, и смяната на адреса без смяна на дължината ги поврежда. Използвайте wp search-replace в WP-CLI или плъгина Better Search Replace, първо като проба, след като сте направили копие на базата.
Защо Cloudflare в режим Flexible прави безкраен цикъл на пренасочване?
В режим Flexible Cloudflare праща заявките към сървъра по HTTP. Ако .htaccess или плъгин пренасочва всяка HTTP заявка към HTTPS, сървърът връща посетителя към HTTPS отново и отново до грешката ERR_TOO_MANY_REDIRECTS. Решението е режимът Full (strict) в SSL/TLS на Cloudflare, който изисква валиден сертификат на сървъра, какъвто издава AutoSSL.
Трябва ли ми HSTS?
Не е задължителен, защото HTTPS работи и без него. HSTS казва на браузъра да ползва само HTTPS за сайта за срока в max-age, а ако махнете HTTPS или сертификатът изтече през това време, сайтът е недостъпен до края на срока. Затова започнете с кратък срок, например 300 секунди, и не включвайте includeSubDomains и preload, освен ако всеки поддомейн работи по HTTPS.
Източници
- WordPress, HTTPS
- WordPress, Migrating WordPress
- WordPress Make, Improved HTTPS detection and migration in WordPress 5.7
- WordPress, wp_replace_insecure_home_url()
- WP-CLI, wp search-replace
- WP-CLI, wp db export
- Better Search Replace на wordpress.org
- cPanel, Guide to SSL
- cPanel, SSL/TLS Status
- cPanel, File Manager
- Apache HTTP Server, mod_rewrite
- Apache HTTP Server, mod_headers
- MDN, Mixed content
- web.dev, What is mixed content?
- web.dev, Fixing mixed content
- Chrome for Developers, Open Chrome DevTools
- Chrome for Developers, Network features reference
- MDN, Strict-Transport-Security
- Cloudflare, Encryption modes
- Cloudflare, Flexible
- Cloudflare, Full (strict)
- Cloudflare, ERR_TOO_MANY_REDIRECTS
- Cloudflare, Always Use HTTPS
- Cloudflare, Automatic HTTPS Rewrites
- Cloudflare, HTTP Strict Transport Security