Как да поправим грешката „Този сайт не може да осигури сигурна връзка”

Грешката "This site can't provide a secure connection" означава, че браузърът ви не е успял да завърши TLS ръкостискане с целевия сървър. Опитът за връзка е прекратен преди да бъде установен какъвто и да е криптиран канал, което оставя браузъра неспособен да провери самоличността на сървъра или да договори cipher suite.

Тази грешка се появява в Chrome, Firefox, Edge и Safari и почти винаги е придружена от специфичен код за грешка — най-често ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH или SSL_ERROR_HANDSHAKE_FAILURE_ALERT. Всеки код сочи към отделен слой на неизправност: конфигурацията на сертификата на сървъра, TLS стека на клиента или мрежовия път между тях. Идентифицирането на отговорния слой преди промяна на каквито и да е настройки ще ви спести значително време.

Какво всъщност се случва по време на TLS ръкостискане

Преди да преминем към решения, важно е да разберем механизма на неизправността. Когато браузърът ви се свърже с HTTPS сайт, той извършва TLS ръкостискане за милисекунди:

1. Браузърът изпраща съобщение ClientHello, обявявайки поддържаните TLS версии и cipher suites.
2. Сървърът отговаря с ServerHello, избирайки версия на протокола и cipher, след което представя своята верига от сертификати.
3. Браузърът валидира сертификата спрямо доверени root Certificate Authorities (CAs), проверява датата на изтичане, верифицира дали домейнът съответства на Subject Alternative Name (SAN) и потвърждава, че сертификатът не е отменен (чрез OCSP или CRL).
4. И двете страни извличат сесийни ключове и започват криптирана комуникация.

Неизправност на някоя от тези четири стъпки генерира съобщението "can't provide a secure connection". Кодът за грешка в панела с детайли на браузъра ви казва точно коя стъпка е пропаднала.

Основни причини, съпоставени с кодове за грешки

Ако кодът за грешка поставя отговорността върху администратора на сървъра и вие не контролирате сървъра, опциите ви са ограничени до свързване със собственика на сайта. Останалите раздели се фокусират върху грешки, които можете да разрешите от страна на клиента, последвани от корекции от страна на сървъра за администраторите.

Корекции от страна на клиента

1. Проверете сертификата преди да промените каквото и да е

Кликнете върху катинара (или иконата за предупреждение) в адресната лента и изберете Connection is secure > Certificate is valid. Проверете:

• Период на валидност: Датата "Not After" трябва да е в бъдещето.
• Издаден на: Домейнът в полето SAN на сертификата трябва да съответства точно на URL адреса, включително поддомейните.
• Издаден от: Веригата на CA трябва да завършва при root CA, на която вашата операционна система има доверие.

Ако сертификатът е изтекъл или не съответства и вие не притежавате сървъра, спрете тук и се свържете със собственика на сайта. Ако управлявате сървъра, преминете към раздела за сървърна страна по-долу.

2. Синхронизирайте системната дата и час

Валидирането на сертификати е чувствително към времето. Системен часовник, изместен дори с няколко минути, може да накара браузъра да заключи, че валиден сертификат е изтекъл, или че се използва сертификат, чийто срок на валидност все още не е настъпил.

Windows:

w32tm /resync /force

Алтернативно, кликнете с десен бутон върху системния часовник, изберете Adjust date/time и активирайте Set time automatically с услугата Windows Time.

Linux (systemd):

timedatectl set-ntp true
timedatectl status

macOS: Отворете System Settings > General > Date & Time и активирайте Set time and date automatically.

След синхронизирането рестартирайте браузъра и тествайте отново.

3. Изчистете SSL състоянието и кеша на браузъра

Браузърите кешират резултатите от валидирането на сертификати и HSTS (HTTP Strict Transport Security) политиките. Остарял кеш запис може да блокира достъпа дори след като проблем със сертификата от страна на сървъра е бил разрешен.

Chrome — изчистване на данните за сърфиране:

Отидете на chrome://settings/clearBrowserData, изберете All time, отметнете Cookies and other site data и Cached images and files, след което кликнете Clear data.

Chrome — изчистване на HSTS запис за конкретен домейн:

Отидете на chrome://net-internals/#hsts, въведете домейна под Delete domain security policies и кликнете Delete. Това е особено полезно, когато даден домейн е бил само HTTPS и сега е неправилно конфигуриран.

Windows — изчистване на SSL състоянието на ниво операционна система:

Control Panel > Network and Internet > Internet Options > Content tab > Clear SSL State

Това изчиства кеша на сертификатите, използван от Internet Explorer, Edge (legacy) и някои Windows приложения.

Firefox: Отидете на about:preferences#privacy, превъртете до Cookies and Site Data и кликнете Clear Data.

4. Деактивирайте HTTPS инспекцията на антивируса

Продуктите за сигурност от производители като Avast, AVG, Kaspersky, ESET и Bitdefender извършват SSL/TLS прихващане — те действат като локален man-in-the-middle прокси, преподписвайки сертификати с техния собствен root CA. Когато техният root CA не е правилно инсталиран в хранилището за доверие на браузъра, или когато модулът за прихващане е дефектен, всяка HTTPS връзка се проваля.

За да проверите дали това е причината:

1. Временно деактивирайте функцията Web Shield, HTTPS Scanning или SSL Filtering в настройките на антивируса.
2. Презаредете страницата с грешка.
3. Ако грешката изчезне, антивирусът е виновникът.

Постоянното решение е да добавите засегнатия домейн в списъка с изключения на антивируса, вместо да деактивирате HTTPS сканирането глобално, което би намалило нивото ви на сигурност.

5. Актуализирайте браузъра

Съвременният TLS изисква поддръжка на браузъра за минимум TLS 1.2, и TLS 1.3 за оптимална сигурност. Браузъри по-стари от приблизително Chrome 70, Firefox 63 или Edge 79 може да нямат поддръжка на TLS 1.3 или да имат известни грешки при ръкостискане.

Chrome:

Отидете на chrome://settings/help. Chrome проверява за актуализации автоматично и ги инсталира при рестартиране.

Firefox:

Отидете на about:support, след което Check for Updates от менюто Help.

Поддържането на браузъра актуален също гарантира, че вграденото хранилище за root CA на браузъра е актуално, което е важно за сертификати, издадени от по-нови CA.

6. Проверете настройките на TLS протокола в браузъра

Chrome и Edge (базирани на Chromium):

Тези браузъри не предоставят превключватели за TLS версия в потребителския интерфейс от Chrome 84 насам. TLS 1.0 и 1.1 са постоянно деактивирани. Ако даден сайт изисква TLS 1.0 или 1.1, сайтът трябва да бъде актуализиран — няма решение от страна на клиента, нито трябва да има такова.

За да проверите за експериментални TLS флагове, отидете на chrome://flags и потърсете TLS. В повечето производствени версии няма да се появят приложими флагове.

Firefox:

Отидете на about:config и потърсете security.tls.version.min. Стойността трябва да е 3 (съответстваща на TLS 1.2). Задаването й на 1 или 2 за да се приспособите към дефектен сървър е риск за сигурността и трябва да се прави само в изолирани тестови среди.

Internet Explorer / Legacy Edge:

Отидете на Internet Options > Advanced > Security и се уверете, че Use TLS 1.2 и Use TLS 1.3 са отметнати. Премахнете отметките от Use SSL 3.0, Use TLS 1.0 и Use TLS 1.1.

7. Деактивирайте или проверете разширенията на браузъра

Разширения с мрежов достъп — особено VPN, блокери на реклами, инструменти за поверителност и превключватели на прокси — могат да прихващат или модифицират TLS връзки. За да изолирате конфликт с разширение:

Отидете на chrome://extensions/ и деактивирайте всички разширения. Презаредете страницата с грешка. Ако грешката се разреши, активирайте разширенията едно по едно, презареждайки след всяко, докато не идентифицирате проблемното разширение.

8. Сменете DNS резолвера

DNS не влияе пряко на TLS, но DNS резолвер, връщащ неправилни IP адреси (поради отравяне, филтриране или намеса на ISP), може да насочи браузъра ви към сървър, представящ сертификат за грешен домейн, причинявайки грешка ERR_CERT_COMMON_NAME_INVALID.

Преминаването към публичен резолвер елиминира DNS манипулацията на ниво ISP:

Windows — промяна на DNS чрез PowerShell:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")

Заменете "Ethernet" с действителното име на вашия интерфейс (използвайте Get-NetAdapter за изброяване на интерфейсите).

Linux:

sudo nano /etc/resolv.conf

Добавете:

nameserver 1.1.1.1
nameserver 8.8.8.8

Препоръчани публични резолвери:

9. Нулирайте мрежовия стек (Windows)

Повреден каталог на Winsock или TCP/IP стек може да причини периодични TLS неизправности, които изглеждат несвързани със сертификати. Изпълнете следното като Администратор:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Рестартирайте машината след изпълнение на всичките пет команди. Не пропускайте рестартирането — netsh winsock reset в частност изисква рестартиране, за да влезе в сила.

Корекции от страна на сървъра за администратори

Ако управлявате уеб сървъра, представящ сертификата, следните са най-честите причини от страна на сървъра и тяхното отстраняване.

Изтекъл или неправилно конфигуриран SSL сертификат

Изтекъл сертификат е единствената най-честа причина за тази грешка на ниво сървър. Ако управлявате сайт в среда VPS Hosting, подновяването на сертификата трябва да бъде автоматизирано.

Проверете изтичането на сертификата от командния ред:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Автоматизирайте подновяването с Certbot (Let's Encrypt):

sudo certbot renew --dry-run

Добавете cron задача или systemd таймер за изпълнение на certbot renew два пъти дневно — сертификатите на Let's Encrypt изтичат на всеки 90 дни, а Certbot подновява само когато остават по-малко от 30 дни.

0 0,12 * * * root certbot renew --quiet

Ако имате нужда от търговски валидиран сертификат с разширена валидация или wildcard покритие, SSL сертификати от доверена CA осигуряват веригата на доверие, изисквана от всички основни браузъри.

Непълна верига от сертификати

Много честа неправилна конфигурация: сървърът представя само крайния сертификат без междинните CA сертификати. Браузърът не може да изгради път на доверие до root CA, която разпознава, което води до ERR_CERT_AUTHORITY_INVALID.

Диагностициране с SSL Labs:

Пуснете домейна си през SSL Labs Server Test (външен инструмент). Проблем с веригата ще бъде маркиран незабавно.

Корекция в Nginx:

Директивата ssl_certificate трябва да сочи към файл, съдържащ пълната верига — вашият сертификат, последван от всички междинни сертификати:

cat your_domain.crt intermediate.crt > fullchain.crt

ssl_certificate /etc/nginx/ssl/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;

Корекция в Apache:

SSLCertificateFile /etc/apache2/ssl/your_domain.crt
SSLCertificateKeyFile /etc/apache2/ssl/your_domain.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt

Остарели TLS версии и слаби cipher suites

Браузърите са премахнали поддръжката за TLS 1.0 и TLS 1.1. Ако вашият сървър предлага само тези версии на протокола, съвременните браузъри ще откажат връзката изцяло.

Препоръчана TLS конфигурация за Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;

Препоръчана TLS конфигурация за Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

След промяна на конфигурацията на сървъра, тествайте с:

openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

Несъответствие на домейна в сертификата

Ако вашият сертификат покрива www.example.com, но потребителите достъпват example.com (или обратното), браузърът ще докладва несъответствие на домейна. Правилното решение е да издадете сертификат с двете имена в полето SAN, или да използвате wildcard сертификат (*.example.com).

При настройване на нов домейн в среда Dedicated Servers, винаги проверявайте дали полето SAN покрива всеки вариант на хостнейм, на който сървърът ще отговаря, преди да пуснете сайта в продукция.

Блокиране на смесено съдържание

Страница, заредена по HTTPS, която препраща към HTTP ресурси (изображения, скриптове, стилови таблици), задейства предупреждения за смесено съдържание. Въпреки че това не генерира директно грешката "can't provide a secure connection", може да причини частични неизправности на страницата, погрешно диагностицирани като TLS грешки.

Проверете за смесено съдържание с:

curl -s https://yourdomain.com | grep -Eo 'src="http://[^"]*"|href="http://[^"]*"'

Сравнение на причините от страна на клиента и сървъра

Съображения за хостинг средата

Хостинг средата, която използвате, пряко влияе върху това колко лесно можете да разрешите TLS проблеми от страна на сървъра.

При Споделен уеб хостинг, управлението на сертификати обикновено се извършва чрез контролния панел. Повечето съвременни платформи за споделен хостинг включват безплатна интеграция с Let's Encrypt, но имате ограничен контрол върху настройките на TLS протокола за целия сървър.

При VPS с cPanel, получавате достъп до AutoSSL за автоматизирано осигуряване на сертификати и можете да конфигурирате директно TLS настройките на Apache или Nginx. Това е препоръчваната среда за сайтове, при които прецизността на TLS конфигурацията е от значение.

При bare-metal Dedicated Servers, имате пълен контрол върху целия TLS стек — версия на OpenSSL, избор на cipher suite, OCSP stapling, HSTS preloading и certificate pinning — но също така носите пълна отговорност за поддържане на конфигурацията актуална.

Практически контролен списък за вземане на решения

Използвайте този контролен списък за систематично диагностициране на грешката, вместо да прилагате корекции на случаен принцип:

• Появява ли се грешката на всички HTTPS сайтове или само на един?
• Всички сайтове: фокусирайте се върху системния часовник, HTTPS сканирането на антивируса, актуализацията на браузъра, хранилището за root CA на операционната система.
• Един сайт: проблемът почти сигурно е от страна на сървъра.

• Какво казва конкретният код за грешка?
• ERR_CERT_DATE_INVALID: проверете първо системния часовник, след това изтичането на сертификата.
• ERR_CERT_AUTHORITY_INVALID: проверете пълнотата на веригата от сертификати.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH: сървърът използва остарял TLS или неподдържани ciphers.
• ERR_CERT_COMMON_NAME_INVALID: SAN на сертификата не съответства на домейна.

• Изчезва ли грешката в друга мрежа?
• Да: причината е защитна стена, прокси или TLS инспекция на ниво ISP.

• Изчезва ли грешката при деактивиран антивирус?
• Да: конфигурирайте изключение за домейна в настройките за HTTPS сканиране на антивируса.

• Вие ли сте администраторът на сървъра?
• Изпълнете диагностика с openssl s_client и SSL Labs тест преди да докосвате какъвто и да е конфигурационен файл.
• Автоматизирайте подновяването на сертификата незабавно след разрешаване на непосредствения проблем.

Често задавани въпроси

Защо "This site can't provide a secure connection" се появява само на един уебсайт?

Когато грешката е изолирана до един домейн, основната причина почти винаги е от страна на сървъра: изтекъл сертификат, непълна верига от сертификати, несъответствие на домейното име в полето SAN на сертификата, или сървърът е конфигуриран да използва само остарели TLS версии (1.0 или 1.1), които съвременните браузъри вече не приемат.

Може ли VPN да причини тази грешка?

Да. Някои VPN клиенти насочват DNS заявките през собствените си резолвери или извършват инспекция на трафика, която пречи на TLS ръкостисканията. Ако грешката се появява само докато VPN е активен, деактивирайте функцията "split tunneling" или "SSL inspection" на VPN, или добавете засегнатия домейн като изключение.

Изчистването на кеша винаги ли поправя SSL грешките?

Не. Изчистването на кеша разрешава грешки, причинени от остарели HSTS политики или кеширани невалидни отговори на сертификати. То няма ефект върху проблеми със сертификати от страна на сървъра, проблеми със системния часовник или прихващане от антивирус. Използвайте изчистването на кеша като първа стъпка, а не като универсално решение.

Как да проверя дали SSL сертификатът на моя сървър е правилно конфигуриран без браузър?

Използвайте OpenSSL от всяка машина с мрежов достъп:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Изходът показва пълната верига от сертификати, договорената TLS версия, избрания cipher suite и всякакви грешки при верификацията. Това е най-надеждният метод за диагностика на TLS проблеми от страна на сървъра.

Каква е разликата между ERR_SSL_PROTOCOL_ERROR и ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_PROTOCOL_ERROR показва, че сървърът е изпратил отговор, който не съответства на никакъв разпознат TLS формат на запис — често причинено от сървър, изпращащ HTTP отговор на порт 443, неправилно конфигуриран load balancer или защитна стена, прекъсваща връзката по средата на ръкостискането. ERR_SSL_VERSION_OR_CIPHER_MISMATCH означава, че ръкостискането е започнало правилно, но клиентът и сървърът не са могли да се споразумеят за взаимно поддържана TLS версия или cipher suite, обикновено защото сървърът поддържа само остарели протоколи.