Типичные проблемы TLS
| Проблема | Серьёзность |
|---|---|
| Включены TLS 1.0 / 1.1 | Критическая — устаревшие, уязвимые, современные браузеры отклоняют |
| Сертификат истёк | Высокая — браузер показывает предупреждение, пользователи уходят |
| Сертификат истекает скоро (< 14 дней) | Высокая — срочно обновить |
| Самоподписанный сертификат | Высокая — нет доверенного CA, предупреждение браузера |
| Несоответствие домена | Высокая — браузер блокирует соединение |
Диагностика
# Проверьте, принимает ли сервер TLS 1.1
openssl s_client -connect yoursite.com:443 -tls1_1 2>/dev/null | grep "Cipher"
# Если показывает cipher — TLS 1.1 ещё активен
# То же для TLS 1.0
openssl s_client -connect yoursite.com:443 -tls1 2>/dev/null | grep "Cipher"
# Проверьте срок действия сертификата
openssl s_client -connect yoursite.com:443 2>/dev/null | openssl x509 -noout -dates
Vercel / Netlify
TLS управляется платформой, сертификаты обновляются автоматически. Если vibeblame всё равно сообщает о проблеме — скорее всего кастомный домен не прошёл верификацию. Проверьте настройки домена в панели платформы.
Cloudflare
TLS управляется автоматически. Чтобы отключить TLS 1.0 / 1.1:
Cloudflare Dashboard -> SSL/TLS -> Edge Certificates -> Minimum TLS Version -> выберите TLS 1.2
Nginx (VPS / self-hosted)
server {
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yoursite.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yoursite.com/privkey.pem;
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;
ssl_prefer_server_ciphers off;
ssl_stapling on;
ssl_stapling_verify on;
}
nginx -t && nginx -s reload
Apache
# httpd.conf или ssl.conf
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
apachectl configtest && systemctl restart apache2
Vue (Nuxt) и Angular
TLS настраивается на уровне инфраструктуры — не в коде Nuxt или Angular-приложения. Используйте конфигурации Nginx, Cloudflare, Vercel или Netlify из этого гайда в зависимости от вашего хостинга.
Локальный HTTPS для разработки на Nuxt:
# Создайте локальный доверенный сертификат
brew install mkcert && mkcert -install
mkcert localhost
// nuxt.config.ts
export default defineNuxtConfig({
devServer: {
https: {
key: './localhost-key.pem',
cert: './localhost.pem',
},
},
})
Локальный HTTPS для разработки на Angular:
mkcert localhost
ng serve --ssl --ssl-key localhost-key.pem --ssl-cert localhost.pem
В продакшене разворачивайте за Nginx, Cloudflare или управляемой платформой и настраивайте TLS там.
WordPress / PHP на shared hosting
На shared hosting (cPanel, Plesk) прямого доступа к конфигу сервера обычно нет. Варианты:
- Cloudflare (бесплатный план) — добавьте сайт в Cloudflare, выставьте Minimum TLS Version: 1.2. Cloudflare будет терминировать TLS до того, как запрос дойдёт до хостинга.
- Панель управления хостингом — многие хосты предоставляют раздел SSL/TLS в cPanel или Plesk с выбором минимальной версии протокола.
- Поддержка хостинга — попросите отключить TLS 1.0 / 1.1 для вашего домена.
Для управления сертификатами на cPanel используйте встроенную интеграцию с Let's Encrypt (раздел "SSL/TLS" или "Let's Encrypt SSL") — она сама обновляет сертификаты.
Tilda
TLS управляется Tilda. Если сертификат выпущен через Tilda — ничего настраивать не нужно; при проблеме обращайтесь в поддержку.
Если домен проходит через Cloudflare, выставьте Minimum TLS Version: 1.2 как описано выше.
Автообновление сертификатов Let's Encrypt (self-hosted)
# Установите certbot
apt install certbot python3-certbot-nginx # или python3-certbot-apache
# Выпустите сертификат
certbot --nginx -d yoursite.com -d www.yoursite.com
# Проверьте обновление
certbot renew --dry-run
# Добавьте в cron (дважды в день)
crontab -e
# Добавьте:
0 0,12 * * * certbot renew --quiet --post-hook "nginx -s reload"
Несоответствие домена
Возникает, когда сертификат выпущен для yoursite.com, а запрос приходит на www.yoursite.com, или наоборот.
Выпустите сертификат для обоих вариантов:
certbot --nginx -d yoursite.com -d www.yoursite.com
И добавьте редирект, чтобы использовался только один вариант:
server {
listen 80;
server_name www.yoursite.com;
return 301 https://yoursite.com$request_uri;
}
Проверка
openssl s_client -connect yoursite.com:443 2>/dev/null | openssl x509 -noout -text | grep -E "Not After|DNS:"
Для полного отчёта с оценкой используйте SSL Labs. Цель — оценка A или A+.