Настройка SSL/TLS сертификата для сайта под ключ

Без HTTPS современный сайт — не сайт. Настройка SSL-сертификата для сайта на Nginx — задача, которую нельзя отложить. Браузеры помечают его как небезопасный, Google снижает позиции, а API (PWA, Geolocation, Service Workers) перестают работать. Правильная установка SSL на Nginx включает выбор сертификата, настройку HSTS и OCSP Stapling. Transport Layer Security — протокол, обеспечивающий шифрование и целостность данных. Разберём, как настроить SSL/TLS сертификат для сайта на Nginx от начала до конца.

Мы решали задачи HTTPS для 200+ проектов — от простых DV-блогов до мультидоменных конфигураций с Wildcard. Типичные ошибки: неправильная цепочка или редирект 302 вместо 301. Оценим ваш проект за час бесплатно. Закажите настройку SSL — получите надёжную защиту.

Выбор SSL-сертификата по типу и задачам

Для большинства: Let's Encrypt DV (бесплатно) или платный аналог от Comodo/Sectigo. Бесплатный сертификат экономит до 15 000 рублей в год по сравнению с платным.

Основные проблемы, решаемые настройкой SSL

HSTS — заголовок, предписывающий браузеру использовать только HTTPS. Без него возможна атака SSL stripping — перенаправление на HTTP. Мы включаем HSTS с параметром max-age=63072000; includeSubDomains; preload. Это обеспечивает, что даже при первом заходе браузер сразу использует HTTPS, исключая атаки SSL stripping.

Почему HSTS критичен для безопасности? Потому что он исключает возможность перехвата трафика на этапе первого подключения. Без HSTS браузер может временно перейти на HTTP, и злоумышленник этим воспользуется.

OCSP Stapling ускоряет проверку статуса сертификата. Сервер сам запрашивает у OCSP-ответчика подтверждение и передаёт его браузеру, минуя задержки. Без Stapling браузер делает отдельный запрос, увеличивая TTFB. Включаем ssl_stapling on в Nginx.

Let's Encrypt vs платные сертификаты: что выбрать?

Для обычных сайтов Let's Encrypt — оптимальный выбор. Платные нужны для OV/EV или если клиент требует поддержки от вендора. По скорости настройки Let's Encrypt выигрывает в 3-5 раз — весь процесс занимает менее часа.

Как работает OCSP Stapling?

OCSP Stapling — техника, при которой сервер периодически запрашивает OCSP-ответ и "сшивает" его с сертификатом. Браузеру не нужно обращаться к OCSP-серверу самостоятельно. Это снижает TTFB и повышает приватность, так как браузер не сообщает OCSP-серверу, какие сайты посещает. Для корректной работы stapling необходимо указать доверенный сертификат: ssl_trusted_certificate. Рекомендуется использовать резолверы Cloudflare (1.1.1.1) или Google (8.8.8.8). Без stapling каждый клиент делает отдельный запрос к OCSP-серверу, что увеличивает TTFB. Правильная настройка может сократить время загрузки на 100-200 мс.

Процесс настройки SSL: от анализа до деплоя

Используем Certbot для Let's Encrypt или OpenSSL для платных. Стек: Nginx на Ubuntu, TLSv1.2/1.3, современные шифры (ECDHE+AESGCM). Мониторинг: SSL Labs, Prometheus.

Процесс:

1. Аудит текущей конфигурации — ищем неправильные редиректы, смешанный контент.
2. Выбор типа сертификата (DV/OV/EV/Wildcard) с учётом бизнес-задач.
3. Генерация CSR и закрытого ключа.
4. Установка сертификата на сервер с тестированием.
5. Настройка HSTS, OCSP Stapling, ssl_session_cache.
6. Настройка HTTP → HTTPS редиректа (301).
7. Проверка в SSL Labs (цель — A+).
8. Документация по продлению и закладка в мониторинг.

Что входит в настройку SSL под ключ?

• Аудит текущей HTTPS-конфигурации
• Выбор оптимального типа сертификата (DV, OV, EV, Wildcard)
• Генерация CSR и установка сертификата
• Настройка HSTS, OCSP Stapling, шифров и протоколов
• Редирект HTTP на HTTPS (301)
• Тестирование через SSL Labs (оценка A+)
• Инструкция по продлению и мониторингу
• Часовая пост-деплой консультация

Стоимость настройки SSL под ключ — от 5 000 до 15 000 рублей в зависимости от сложности. Закажите настройку SSL — получите бесплатную оценку проекта за час.

Пример конфигурации Nginx

server {
    listen 443 ssl http2;
    server_name example.ru www.example.ru;

    ssl_certificate     /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/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;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 1.1.1.1 valid=300s;
    ssl_trusted_certificate /etc/letsencrypt/live/example.ru/chain.pem;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;
}

server {
    listen 80;
    server_name example.ru www.example.ru;
    return 301 https://example.ru$request_uri;
}

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

# Генерация CSR
openssl req -new -newkey rsa:2048 -nodes \
    -keyout example.ru.key \
    -out example.ru.csr \
    -subj "/C=RU/ST=Moscow/L=Moscow/O=Компания ООО/CN=example.ru"
# Далее загружаем CSR в панель УЦ, проходим верификацию, получаем сертификат.
# В Nginx указываем пути:
# ssl_certificate /etc/ssl/example.ru/fullchain.crt;
# ssl_certificate_key /etc/ssl/example.ru/example.ru.key;

Проверка SSL-конфигурации: методы и инструменты

• SSL Labs — полный анализ, цель A+.
• openssl s_client -connect example.ru:443 — ручная проверка.
• curl -vI https://example.ru — заголовки и TLS.

Типичные ошибки при настройке SSL

• Неправильная цепочка сертификатов: часто забывают установить промежуточные. Проверяем openssl s_client -showcerts.
• Редирект 302 вместо 301: поисковики не обновляют индексы. Используем 301.
• Смешанный контент: HTTPS-страница загружает скрипты по HTTP. Браузер блокирует. Проверяем через DevTools.
• Устаревшие протоколы: оставляют TLSv1.0/1.1 — уязвимости. Отключаем, оставляем v1.2/1.3.

Свяжитесь с нами для консультации — мы поможем выбрать оптимальный сертификат и настроим всё под ключ. Закажите настройку SSL — получите бесплатную оценку проекта за час.

Безопасность веб-приложений: HTTPS, CSP, XSS, CSRF, WAF, защита от DDoS

Взлом сайта редко выглядит как в кино. Чаще это: бот нашёл endpoint /admin/export без авторизации, скачал базу клиентов, закрыл соединение. Или: через устаревший плагин WordPress залил веб-шелл, теперь сервер рассылает спам. Или тише: XSS в поле комментария позволяет красть session cookies администраторов, и никто не замечает месяцами. Мы такие случаи разбирали десятками — каждый раз уязвимость можно было закрыть на этапе разработки или аудита.

Безопасность веб-приложений — не одна настройка. Это слои защиты, каждый из которых закрывает отдельный класс атак. Закажите аудит — оценим проект и дадим план работ под ключ за 2–4 недели.

HTTPS и правильная конфигурация TLS

HTTPS — минимальный обязательный уровень. Но «есть SSL-сертификат» и «правильно настроен TLS» — разные вещи.

В конфигурации Nginx/Apache проверяем:

• Протоколы: только TLS 1.2 и TLS 1.3, SSLv3 и TLS 1.0/1.1 — отключены
• Cipher suites: предпочитать ECDHE (Forward Secrecy), убрать NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — браузер больше не делает незащищённых запросов
• OCSP Stapling — ускоряет проверку отзыва сертификата
• Redirect 301 с HTTP на HTTPS — и в конфиге сервера, и в коде (двойной редирект = потеря SEO-веса)

Проверка: SSL Labs (ssllabs.com/ssltest) должен показывать A или A+. Если B — конфигурация слабая.

Let's Encrypt + Certbot для продакшена — стандарт. Автоматическое обновление через certbot renew в cron. Wildcard-сертификат для поддоменов через DNS-01 challenge.

Content Security Policy: самая мощная и самая сложная защита

CSP — HTTP-заголовок, который говорит браузеру, откуда разрешено загружать ресурсы. Правильно настроенный CSP полностью блокирует большинство XSS-атак, даже если уязвимость есть в коде.

Проблема: сломать сайт неправильным CSP проще простого. default-src 'none' — и перестают работать шрифты, картинки, JS. Поэтому начинаем с Content-Security-Policy-Report-Only — CSP логирует нарушения, но ничего не блокирует. Смотрим репорты 2–4 недели, дорабатываем политику, потом переключаем на боевой режим.

Пример реальной политики для сайта с Google Analytics, Google Fonts и Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — случайная строка, генерируется на сервере для каждого запроса. Inline-скрипты с правильным nonce разрешены, без nonce — заблокированы. Это ломает XSS через <script>alert(1)</script> полностью.

'unsafe-inline' в style-src — компромисс для inline-стилей. Лучше убрать, перенеся все стили в CSS-файлы, но это требует рефакторинга.

Почему XSS остаётся самой частой уязвимостью?

XSS (Cross-Site Scripting) — инъекция JS-кода через пользовательский ввод. По статистике OWASP, XSS входит в топ-3 уязвимостей веб-приложений. Три типа:

Защита: никогда не вставлять пользовательский ввод в HTML без эскейпинга. В PHP — htmlspecialchars() с ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безопасен, {!! $var !!} — опасен. В React — {variable} безопасен, dangerouslySetInnerHTML — опасен. Для Rich Text — htmlpurifier на PHP или DOMPurify в браузере.

CSRF: защита форм и API

CSRF (Cross-Site Request Forgery) — злоумышленник заставляет браузер жертвы отправить запрос от её имени. Пример: пользователь авторизован в банке, открывает вредоносную страницу, она делает fetch('https://bank.ru/transfer?to=evil&amount=50000') — если банк не защищён, деньги уходят.

CSRF-токены — стандартная защита для форм: сервер генерирует случайный токен, хранит в сессии, вставляет в форму как hidden field. При POST-запросе токен сверяется. Злоумышленник не знает токен. Laravel делает это автоматически через @csrf.

SameSite cookies — современная защита: SameSite=Strict или SameSite=Lax запрещает браузеру отправлять cookie в cross-site запросах. Работает во всех современных браузерах.

API без сессий (JWT, Bearer tokens) — CSRF неактуален, если токен не хранится в cookie (а в Authorization header или localStorage). Но localStorage уязвим к XSS — поэтому для чувствительных данных предпочтительны HttpOnly cookies с SameSite.

WAF и защита от DDoS

WAF (Web Application Firewall) — фильтрует HTTP-трафик на предмет атак: SQL injection, XSS, path traversal, известные exploit patterns. Варианты:

• Cloudflare WAF — облачный, правила OWASP Top 10 из коробки, кастомные правила через выражения. Managed Rules автоматически блокируют новые угрозы.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гибко, но требует настройки и мониторинга ложных срабатываний.
• AWS WAF — для инфраструктуры на AWS, интегрируется с CloudFront и ALB.

DDoS-защита. Cloudflare на уровне L3/L4/L7 — де-факто стандарт для большинства сайтов. Автоматическое смягчение volumetric атак, Under Attack Mode при активной атаке. Для критичной инфраструктуры — Cloudflare Magic Transit или специализированные решения (Qrator, StormWall для российского рынка).

Rate Limiting на уровне приложения — дополнительный слой. Laravel ThrottleRequests middleware: 60 запросов в минуту на IP для общих endpoint, 5 — для /login и /password/reset. Redis как хранилище счётчиков — обязательно для горизонтально масштабируемых систем (иначе лимиты не синхронизируются между серверами).

Другие обязательные меры

Заголовки безопасности. Помимо CSP: X-Frame-Options: DENY (защита от clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (ограничение доступа к API браузера: камера, микрофон, геолокация).

SQL injection. Prepared statements везде. Никаких конкатенаций пользовательского ввода в SQL-строки. ORM (Eloquent, Doctrine) защищает по умолчанию. $wpdb->prepare() в WordPress — обязательно.

Обновления зависимостей. composer audit и npm audit — в CI/CD пайплайн. Dependabot или Renovate для автоматических PR с обновлениями. Критичные CVE — патчить в течение 24 часов.

Секреты и конфигурация. .env — никогда в Git. Секреты в production — через переменные окружения CI/CD (GitHub Secrets, GitLab CI Variables) или HashiCorp Vault. Проверка на утечки: git-secrets, truffleHog в pre-commit hooks.

Как мы работаем

1. Аудит — сканирование кода, конфигураций, зависимостей, ручная проверка бизнес-логики.
2. Проектирование — план устранения уязвимостей, подбор стека (CSP, WAF, rate limiting).
3. Реализация — настройка TLS, CSP, заголовков, внедрение Rate Limiting, WAF.
4. Тестирование — повторный пентест, нагрузочное тестирование, проверка ложных срабатываний.
5. Деплой и мониторинг — включение боевого CSP, настройка алертов, обучение команды.

Что входит в работу

• Отчёт с найденными уязвимостями и рекомендациями (PDF + code snippets)
• Готовая конфигурация TLS (Nginx/Apache)
• Политика CSP с режимом Report-Only и боевой версией
• Настройка WAF и Rate Limiting
• План обновлений зависимостей
• Доступы к инструментам мониторинга (Sentry, Datadog)
• 30 дней постаудит-поддержки (консультации, правки)

Сроки и стоимость

Бюджет рассчитывается индивидуально — напишите нам, чтобы оценить проект.