Shady Nagy
HomeContact

Как я исправил проблемы с SSL-сертификатом на своём сайте - Полное руководство

By Shady Nagy
Published in Linux
February 11, 2026
7 min read
Как я исправил проблемы с SSL-сертификатом на своём сайте - Полное руководство

Table Of Contents

01
Проблема, с которой всё началось
02
Понимание того, что пошло не так
03
Решение №1: Исправление отсутствующего промежуточного сертификата
04
Решение №2: Принудительное перенаправление на HTTPS
05
Полный набор диагностических команд
06
Финальные файлы конфигурации
07
Результаты: Всё исправлено! ✅
08
Вопросы и ответы
09
Полезные онлайн-инструменты для тестирования SSL
10
Ключевые выводы
11
Заключительные мысли
12
Обратная связь и вопросы

Проблема, с которой всё началось

Представьте себе: я только что установил SSL-сертификат на свой сайт shadynagy.com. Всё выглядело отлично с моей стороны — сертификат был действителен, выдан Sectigo и имел достаточно времени до истечения срока действия (265 дней!). Но когда я провёл быструю проверку SSL на сайте WhyNoPadlock.com, я получил несколько разочаровывающих красных крестиков:

❌ Force HTTPS: Не принудительное использование SSL
❌ Invalid Intermediate: Отсутствует промежуточный (bundle) сертификат

Моё сердце упало. Какая польза от SSL-сертификата, если он не работает должным образом? Мои посетители могут видеть предупреждения о безопасности, поисковые системы могут ранжировать меня ниже, и что хуже всего — мой сайт может выглядеть непрофессионально.

Но вот хорошая новость: я всё исправил, и я покажу вам точно, как я это сделал, шаг за шагом.

Понимание того, что пошло не так

Прежде чем приступить к решениям, давайте разберёмся, что на самом деле означают эти ошибки:

Проблема №1: Отсутствующий промежуточный сертификат

Что такое промежуточный сертификат?

Представьте SSL-сертификаты как цепочку доверия:

  • Ваш браузер доверяет определённым “корневым” центрам сертификации (например, Sectigo)
  • Эти центры выдают “промежуточные” сертификаты суб-центрам
  • Эти суб-центры выдают сертификат вашего сайта

Ваш сайт должен отправлять КАК ваш сертификат, ТАК И промежуточный сертификат браузерам. Без промежуточного сертификата браузер не может проверить цепочку доверия.

Реальное влияние:

  • Некоторые браузеры показывают предупреждения о безопасности
  • Мобильные устройства часто не могут подключиться
  • Ваш сайт выглядит небезопасным для посетителей

Проблема №2: Нет перенаправления с HTTP на HTTPS

Что это означает?

Когда кто-то вводит http://shadynagy.com (без ‘s’), они должны автоматически перенаправляться на https://shadynagy.com. Без этого перенаправления:

  • Посетители могут получить доступ к вашему сайту через небезопасный HTTP
  • Поисковые системы видят дублированный контент (версии HTTP и HTTPS)
  • Вы теряете SEO-преимущества HTTPS

Решение №1: Исправление отсутствующего промежуточного сертификата

Шаг 1: Понимание первопричины

Я обнаружил, что моя конфигурация nginx использовала неправильную директиву. Вот что у меня было:

# ❌ НЕПРАВИЛЬНАЯ КОНФИГУРАЦИЯ
ssl_certificate /etc/nginx/ssl/shadynagy.com.crt;
ssl_trusted_certificate /etc/nginx/ssl/shadynagy.com.ca-bundle;

Проблема: ssl_trusted_certificate используется для OCSP stapling (функция производительности), а НЕ для отправки цепочки сертификатов браузерам!

Шаг 2: Создание полной цепочки сертификатов

Решение состоит в создании “fullchain” сертификата, который объединяет ваш сертификат с промежуточным сертификатом.

Команда:

cat /etc/nginx/ssl/shadynagy.com.crt /etc/nginx/ssl/shadynagy.com.ca-bundle > /etc/nginx/ssl/shadynagy.com-fullchain.crt

Что это делает:

  • cat - Конкатенирует (объединяет) файлы
  • Первый файл: Сертификат вашего сайта
  • Второй файл: Промежуточный CA bundle
  • > - Выводит в новый файл с именем “fullchain”

Объяснение на примере: Представьте, что у вас есть две части головоломки:

  1. Ваш сертификат (Часть A)
  2. Промежуточный сертификат (Часть B)

Вы склеиваете их вместе, чтобы создать одну полную головоломку, которую браузеры могут понять.

Шаг 3: Обновление конфигурации Nginx

Откройте файл конфигурации SSL:

nano /etc/nginx/conf.d/shadynagy.com-ssl.conf

Обновите до этого:

server {
    listen 443 ssl http2;  # Порт 443 с SSL и HTTP/2
    
    # ✅ ПРАВИЛЬНО - Используйте сертификат fullchain
    ssl_certificate /etc/nginx/ssl/shadynagy.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/shadynagy.com.key;
    
    # Опционально: Сохраните для OCSP stapling (повышение производительности)
    ssl_trusted_certificate /etc/nginx/ssl/shadynagy.com.ca-bundle;
    
    root /var/www/shady-nagy.com/html;
    index index.html index.htm;
    server_name shadynagy.com www.shadynagy.com;
    
    access_log /var/log/nginx/nginx.vhost.access.log;
    error_log /var/log/nginx/nginx.vhost.error.log;
    
    location / {
        try_files $uri $uri/ =404;
    }
}

Объяснение ключевых изменений:

  1. listen 443 ssl http2;

    • 443 = Порт HTTPS
    • ssl = Включить SSL
    • http2 = Включить HTTP/2 для лучшей производительности
    • Это заменяет устаревшую директиву ssl on;

  2. ssl_certificate теперь указывает на fullchain вместо только вашего сертификата

  3. ssl_trusted_certificate сохранён для OCSP stapling (опционально, но рекомендуется)

Шаг 4: Тестирование и применение изменений

Протестируйте конфигурацию:

nginx -t

Ожидаемый вывод:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Если вы видите какие-либо ошибки, дважды проверьте пути к файлам и синтаксис!

Примените изменения:

systemctl reload nginx

Почему reload вместо restart?

  • reload применяет изменения без разрыва соединений
  • restart ненадолго выведет ваш сайт из строя

✅ Преимущества этого исправления

  • ✅ Все браузеры могут проверить ваш SSL-сертификат
  • ✅ Больше никаких предупреждений “Недействительный сертификат”
  • ✅ Мобильные устройства подключаются правильно
  • ✅ Лучшее доверие и SEO-рейтинги
  • ✅ Профессиональный внешний вид

Решение №2: Принудительное перенаправление на HTTPS

Путь исследования

Сначала я проверил мою конфигурацию HTTP:

cat /etc/nginx/conf.d/shadynagy.com.conf

Я обнаружил это:

# ❌ СЛОМАННАЯ КОНФИГУРАЦИЯ
server {
    listen 80;
    root /var/www/shady-nagy.com/html;
    server_name shadynagy.com www.shadynagy.com;
    
    location / {
        try_files $uri $uri/ =404;
    }
    
    return 301 https://$server_name$request_uri;  # Никогда не достигается!
}

Проблема: Nginx читает конфигурации сверху вниз. Когда приходил запрос:

  1. Он соответствовал блоку location /
  2. Обрабатывал запрос
  3. НИКОГДА не достигал строки перенаправления

Это как поставить знак “Объезд” ПОСЛЕ дороги!

Шаг 1: Создание правильной конфигурации перенаправления

Исправление:

# ✅ ПРАВИЛЬНАЯ КОНФИГУРАЦИЯ
server {
    listen 80;
    listen [::]:80;  # Также слушать на IPv6
    server_name shadynagy.com www.shadynagy.com;
    
    # Перенаправить ВЕСЬ HTTP-трафик на HTTPS
    return 301 https://$host$request_uri;
}

Что делает каждая часть:

  • listen 80; - Слушать HTTP-запросы (порт 80)
  • listen [::]:80; - Также слушать IPv6 HTTP-запросы
  • server_name - К каким доменам это применяется
  • return 301 - Отправить постоянное перенаправление (код статуса 301)
  • $host - Домен, который ввёл пользователь (сохраняет www vs без-www)
  • $request_uri - Путь, который они запросили (например, /about или /contact)

Пример в действии:

Если кто-то посещает: http://www.shadynagy.com/how-i-fixed-ssl-certificate-issues-on-my-website-a-complete-guide
Они перенаправляются на: https://www.shadynagy.com/how-i-fixed-ssl-certificate-issues-on-my-website-a-complete-guide

Шаг 2: Применение и тестирование

Протестируйте конфигурацию:

nginx -t

Перезагрузите nginx:

systemctl reload nginx

Протестируйте перенаправление:

curl -I http://shadynagy.com

Ожидаемый вывод:

HTTP/1.1 301 Moved Permanently
Location: https://shadynagy.com/

Отлично! Но подождите…

Неожиданный поворот: Брандмауэр блокировал порт 80!

Когда я тестировал в браузере, это всё равно не работало! После некоторого расследования:

firewall-cmd --list-all

Вывод:

services: https

Заметили, чего не хватает? HTTP (порт 80)!

Перенаправление было настроено идеально, но мой брандмауэр блокировал входящий HTTP-трафик. Это как установить входную дверь, но построить стену перед ней!

Шаг 3: Открытие брандмауэра

Добавьте сервис HTTP:

firewall-cmd --permanent --add-service=http

Перезагрузите брандмауэр:

firewall-cmd --reload

Убедитесь, что это сработало:

firewall-cmd --list-all

Теперь вы должны увидеть:

services: http https

✅ Преимущества этого исправления

  • ✅ Все посетители автоматически используют HTTPS
  • ✅ Нет проблем с дублированным контентом для SEO
  • ✅ Лучшая безопасность для ваших посетителей
  • ✅ Улучшенные рейтинги в поисковых системах
  • ✅ Зелёный замок в браузерах
  • ✅ Создаёт доверие у посетителей

Полный набор диагностических команд

Вот все команды, которые я использовал во время устранения неполадок:

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

# Найти все серверные блоки, слушающие порт 80
grep -r "listen 80" /etc/nginx/


# Проверить синтаксис конфигурации nginx
nginx -t


# Показать полную конфигурацию nginx
nginx -T


# Просмотреть конкретный серверный блок
nginx -T 2>/dev/null | grep -A 15 "server_name shadynagy.com"

Проверка статуса Nginx

# Работает ли nginx?
systemctl status nginx


# Перезагрузить nginx (применить изменения без простоя)
systemctl reload nginx


# Перезапустить nginx (кратковременный простой)
systemctl restart nginx


# Проверить логи ошибок
tail -20 /var/log/nginx/error.log

Тестирование перенаправления HTTP на HTTPS

# Тестировать перенаправление (обходит кеш браузера)
curl -I http://shadynagy.com


# Следовать всем перенаправлениям
curl -IL http://shadynagy.com

Проверка статуса портов

# Слушает ли nginx на порту 80?
ss -tlnp | grep :80


# Слушает ли nginx на порту 443?
ss -tlnp | grep :443

Проверка брандмауэра

# Список всех правил брандмауэра
firewall-cmd --list-all


# Добавить HTTP постоянно
firewall-cmd --permanent --add-service=http


# Добавить HTTPS постоянно
firewall-cmd --permanent --add-service=https


# Применить изменения
firewall-cmd --reload

Финальные файлы конфигурации

HTTP конфигурация (Порт 80)

Файл: /etc/nginx/conf.d/shadynagy.com.conf

server {
    listen 80;
    listen [::]:80;
    server_name shadynagy.com www.shadynagy.com;
    
    return 301 https://$host$request_uri;
}

HTTPS конфигурация (Порт 443)

Файл: /etc/nginx/conf.d/shadynagy.com-ssl.conf

server {
    listen 443 ssl http2;
    
    ssl_certificate /etc/nginx/ssl/shadynagy.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/shadynagy.com.key;
    ssl_trusted_certificate /etc/nginx/ssl/shadynagy.com.ca-bundle;
    
    root /var/www/shady-nagy.com/html;
    index index.html index.htm index.nginx-debian.html;
    server_name shadynagy.com www.shadynagy.com;
    
    access_log /var/log/nginx/nginx.vhost.access.log;
    error_log /var/log/nginx/nginx.vhost.error.log;
    
    location / {
        add_header Cache-Control "no-cache, no-store, must-revalidate";
        add_header Pragma "no-cache";
        add_header Expires 0;
        try_files $uri $uri/ =404;
    }
}

Результаты: Всё исправлено! ✅

После внедрения всех исправлений мой тест SSL на WhyNoPadlock.com показал:

✅ SSL Connection - Пройдено
✅ Valid Certificate - SSL-сертификат установлен правильно
✅ Force HTTPS - Веб-сервер принудительно использует SSL
✅ Domain Matching - Сертификат соответствует имени домена
✅ Signature - Используется sha256WithRSAEncryption
✅ Expiration Date - Сертификат актуален (истекает 2026-11-03)
✅ Mixed Content - Нет смешанного контента

Идеальный результат!

Вопросы и ответы

В1: Зачем мне нужен промежуточный сертификат?

О: Промежуточный сертификат создаёт “цепочку доверия” от вашего сайта к доверенному корневому центру. Без него:

  • Браузеры не могут проверить, что ваш сертификат легитимен
  • Посетители видят страшные предупреждения о безопасности
  • Мобильные устройства часто не могут подключиться
  • Ваш сайт выглядит непрофессионально и небезопасно

Думайте об этом так: если кто-то представляется как “Джон, друг Сары,” вы можете не доверять ему. Но если Сара ваш лучший друг и она ручается за Джона, вы доверяете ему. Промежуточный сертификат — это Сара, ручающаяся за сертификат вашего сайта.

В2: В чём разница между ssl_certificate и ssl_trusted_certificate в nginx?

О: Отличный вопрос!

  • ssl_certificate: Это то, что nginx отправляет браузерам, чтобы доказать идентичность вашего сайта. Он должен содержать ваш сертификат И промежуточный сертификат (fullchain).

  • ssl_trusted_certificate: Используется для OCSP stapling, функции производительности. Nginx использует это для проверки статуса отзыва сертификата от имени клиентов. Он не отправляется браузерам.

Аналогия:

  • ssl_certificate = Ваше удостоверение личности, которое вы показываете людям
  • ssl_trusted_certificate = Ваша личная копия правил, на которую вы ссылаетесь для себя

В3: Почему использовать $host вместо $server_name в перенаправлениях?

О:

  • $host: Точный домен, который пользователь ввёл в браузере (например, www.shadynagy.com или shadynagy.com)
  • $server_name: Первый server_name в вашей конфигурации

Пример сценария:

  • Ваша конфигурация имеет: server_name shadynagy.com www.shadynagy.com;
  • Пользователь посещает: http://www.shadynagy.com

С $server_name: Перенаправляет на https://shadynagy.com (убирает www)
С $host: Перенаправляет на https://www.shadynagy.com (сохраняет www)

Использование $host уважает то, что ввёл пользователь, и предотвращает ненужные дополнительные перенаправления.

В4: Почему перенаправление работало с curl, но не в моём браузере?

О: Это обычно одна из трёх проблем:

  1. Брандмауэр блокирует порт 80 (моя проблема!) - Конфигурация перенаправления была правильной, но входящий HTTP-трафик никогда не достигал nginx.

  2. Кеш браузера - Браузеры агрессивно кешируют перенаправления. Решение: Тестируйте в режиме инкогнито или очистите кеш.

  3. DNS-кеш - Ваш компьютер может иметь старые DNS-записи. Решение: Очистите DNS-кеш или подождите несколько часов.

Совет профессионала: Всегда тестируйте сначала с curl -I, потому что он обходит всё кеширование!

В5: Должен ли я использовать return или rewrite для HTTPS перенаправлений?

О: Всегда используйте return для перенаправлений!

return (рекомендуется):

return 301 https://$host$request_uri;
  • Быстрее (nginx немедленно прекращает обработку)
  • Более ясное намерение
  • Менее подвержен ошибкам

rewrite (избегайте для простых перенаправлений):

rewrite ^ https://$host$request_uri permanent;
  • Медленнее (использует движок регулярных выражений)
  • Более сложный
  • Легко создать бесконечные циклы

Правило большого пальца: Используйте return для перенаправлений, используйте rewrite только когда вам нужно изменить структуру URL.

В6: В чём разница между reload и restart для nginx?

О:

systemctl reload nginx (рекомендуется):

  • Применяет изменения конфигурации плавно
  • Сохраняет существующие соединения активными
  • Без простоя
  • Тестирует конфигурацию перед применением (не перезагрузит, если конфигурация сломана)

systemctl restart nginx (используйте экономно):

  • Полностью останавливает nginx, затем запускает его снова
  • Разрывает все активные соединения
  • Кратковременный простой (обычно от миллисекунд до секунд)
  • Полезно, когда reload не работает

Когда перезапускать вместо перезагрузки:

  • При добавлении новых модулей
  • Когда reload не подхватывает изменения
  • При отладке странных проблем

В7: Как узнать, блокирует ли мой брандмауэр трафик?

О: Выполните эти диагностические команды:

# Проверьте, слушает ли nginx на порту 80
ss -tlnp | grep :80
# Если вы видите nginx здесь, он слушает


# Проверьте правила брандмауэра
firewall-cmd --list-all
# Ищите 'http' в списке сервисов


# Тестируйте извне вашего сервера
curl -I http://your-domain.com
# Если истекает время ожидания, брандмауэр может блокировать

Если nginx слушает НО curl извне истекает время → брандмауэр - это проблема!

В8: Мой SSL-тест показывает предупреждения “Mixed Content”. Что это означает?

О: Смешанный контент возникает, когда ваша HTTPS-страница загружает ресурсы (изображения, скрипты, CSS) через HTTP.

Пример проблемы:

<!-- ❌ ПЛОХО - Загрузка изображения через HTTP на HTTPS-странице -->
<img src="http://shadynagy.com/image.jpg">

Решения:

<!-- ✅ ХОРОШО - Используйте HTTPS -->
<img src="https://shadynagy.com/image.jpg">


<!-- ✅ ХОРОШО - Используйте protocol-relative URL -->
<img src="//shadynagy.com/image.jpg">


<!-- ✅ ЛУЧШЕ ВСЕГО - Используйте относительный URL -->
<img src="/image.jpg">

Проверка на смешанный контент:

  1. Откройте ваш сайт в Chrome
  2. Нажмите F12 (Инструменты разработчика)
  3. Ищите предупреждения во вкладке Console

В9: Нужно ли мне делать это каждый раз, когда я обновляю свой SSL-сертификат?

О: Частично, да.

Что вам нужно сделать снова:

  • Создать новый сертификат fullchain (объединив новый сертификат + промежуточный)
  • Заменить старый файл fullchain

Что вам НЕ нужно делать снова:

  • Изменять файлы конфигурации nginx (они будут ссылаться на те же пути)
  • Изменять правила брандмауэра
  • Настраивать перенаправления

Совет профессионала: Автоматизируйте обновление сертификатов с Let’s Encrypt/Certbot, который обрабатывает fullchain автоматически!

В10: Могу ли я протестировать мою конфигурацию SSL перед тем, как сделать её живой?

О: Абсолютно! Вот как:

1. Тестируйте синтаксис конфигурации nginx:

nginx -t

2. Тестируйте локально с curl:

# Тестировать перенаправление
curl -I http://localhost


# Тестировать HTTPS (может получить предупреждение о сертификате при локальном тестировании)
curl -Ik https://localhost

3. Используйте онлайн-инструменты:

  • SSL Labs - Комплексный SSL-тест
  • WhyNoPadlock - Быстрая проверка SSL
  • SSL Shopper - Проверка цепочки сертификатов

4. Тестируйте в промежуточной среде: Если возможно, настройте тестовый поддомен (например, staging.shadynagy.com) и сначала тестируйте там.

В11: Что такое HTTP/2 и почему вы его добавили?

О: HTTP/2 - это более новая, быстрая версия протокола HTTP.

Преимущества:

  • ✅ Мультиплексирование: Несколько файлов загружаются одновременно по одному соединению
  • ✅ Сжатие заголовков: Меньшие запросы/ответы
  • ✅ Server push: Сервер может отправлять файлы до того, как браузер запросит
  • ✅ Лучшая производительность на мобильных устройствах

Как включить:

listen 443 ssl http2;  # Просто добавьте 'http2' здесь!

Требования:

  • Должен быть включён HTTPS (HTTP/2 требует SSL)
  • Nginx 1.9.5 или новее
  • OpenSSL 1.0.2 или новее

Проверка:

curl -I --http2 https://shadynagy.com
# Ищите "HTTP/2 200" в ответе

В12: Что произойдёт, если я забуду сделать правила брандмауэра постоянными?

О: Если вы не используете --permanent, ваши правила брандмауэра исчезнут при перезагрузке сервера!

Непостоянные (потеряны при перезагрузке):

firewall-cmd --add-service=http  # ❌ Исчезнут после перезагрузки

Постоянные (переживают перезагрузку):

firewall-cmd --permanent --add-service=http  # ✅ Остаются после перезагрузки
firewall-cmd --reload  # Применить немедленно

Проверка, является ли правило постоянным:

# Показать runtime (текущие) правила
firewall-cmd --list-all


# Показать постоянные (сохранённые) правила
firewall-cmd --permanent --list-all

Если они не совпадают, вам нужно сделать ваши изменения постоянными!

В13: Как часто мне следует проверять мой SSL-сертификат?

О: Вот хороший график обслуживания:

Ежемесячно:

  • Проверьте дату истечения сертификата
  • Запустите быструю проверку SSL на WhyNoPadlock.com

Перед истечением:

  • Обновите сертификат за 30 дней до его истечения
  • Немедленно протестируйте новый сертификат
  • Настройте автоматическое обновление, если возможно

После обновлений сервера:

  • Тестируйте SSL после любых обновлений nginx/OpenSSL
  • Проверьте, что перенаправления всё ещё работают

Настройте мониторинг: Многие сервисы предлагают бесплатный мониторинг SSL:

  • UptimeRobot
  • Pingdom
  • Мониторинг SSL Labs

Они отправят вам email перед истечением срока действия вашего сертификата!

В14: Что если у меня несколько доменов на одном сервере?

О: Вам нужен отдельный серверный блок для каждого домена.

Пример для нескольких доменов:

# Домен 1: shadynagy.com
server {
    listen 80;
    server_name shadynagy.com www.shadynagy.com;
    return 301 https://$host$request_uri;
}


server {
    listen 443 ssl http2;
    server_name shadynagy.com www.shadynagy.com;
    ssl_certificate /etc/nginx/ssl/shadynagy.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/shadynagy.com.key;
    root /var/www/shadynagy.com;
}


# Домен 2: myotherdomain.com
server {
    listen 80;
    server_name myotherdomain.com www.myotherdomain.com;
    return 301 https://$host$request_uri;
}


server {
    listen 443 ssl http2;
    server_name myotherdomain.com www.myotherdomain.com;
    ssl_certificate /etc/nginx/ssl/myotherdomain.com-fullchain.crt;
    ssl_certificate_key /etc/nginx/ssl/myotherdomain.com.key;
    root /var/www/myotherdomain.com;
}

Альтернатива: Используйте wildcard сертификат или мультидоменный (SAN) сертификат, чтобы покрыть несколько доменов одним сертификатом.

В15: Почему мой сертификат показывается как “небезопасный” даже после всех этих исправлений?

О: Проверьте эти распространённые проблемы:

  1. Несоответствие имени сертификата:

    • Сертификат для www.shadynagy.com, но вы посещаете shadynagy.com
    • Решение: Получите сертификат, который покрывает оба (SAN сертификат)

  2. Истёкший сертификат:

    • Проверьте дату истечения: openssl x509 -in certificate.crt -noout -dates
    • Решение: Обновите сертификат

  3. Смешанный контент:

    • HTTPS-страница загружает HTTP-ресурсы
    • Проверьте консоль браузера на предупреждения

  4. Неправильный домен в конфигурации nginx:

    • server_name не соответствует домену, который вы посещаете
    • Решение: Добавьте все варианты домена в server_name

  5. Сертификат не доверенный:

    • Используется самоподписанный сертификат
    • Решение: Получите сертификат от доверенного CA (Let’s Encrypt бесплатный!)

Быстрая диагностика:

# Проверьте, какой сертификат обслуживается
openssl s_client -connect shadynagy.com:443 -servername shadynagy.com

Полезные онлайн-инструменты для тестирования SSL

🔗 SSL Labs - Наиболее комплексный SSL-тест, даёт вам оценку от A до F

🔗 WhyNoPadlock - Быстрая визуальная проверка распространённых SSL-проблем

🔗 SSL Shopper - Проверяет установку сертификата и цепочку

🔗 Security Headers - Тестирует HTTP заголовки безопасности

🔗 High-Tech Bridge - Детальная оценка SSL/TLS и безопасности

Ключевые выводы

Для промежуточных сертификатов:

✅ Всегда создавайте сертификат fullchain (сертификат + CA bundle)
✅ Используйте директиву ssl_certificate для fullchain
✅ Используйте ssl_trusted_certificate только для OCSP stapling
✅ Тестируйте онлайн-инструментами после установки

Для HTTPS перенаправлений:

✅ Используйте return 301 для перенаправлений (не rewrite)
✅ Размещайте перенаправление ПЕРЕД блоками location
✅ Используйте $host для сохранения ввода домена пользователем
✅ Не забудьте открыть порт 80 в брандмауэре!

Для тестирования:

✅ Всегда тестируйте конфигурацию nginx с nginx -t перед перезагрузкой
✅ Используйте curl для обхода кеша браузера
✅ Проверяйте правила брандмауэра с firewall-cmd --list-all
✅ Проверяйте прослушивание портов с ss -tlnp

Для обслуживания:

✅ Настройте оповещения об истечении сертификата
✅ Делайте правила брандмауэра постоянными
✅ Поддерживайте nginx и OpenSSL обновлёнными
✅ Регулярно тестируйте конфигурацию SSL

Заключительные мысли

Конфигурация SSL может показаться пугающей поначалу, но как только вы поймёте части, это довольно логично:

  1. Цепочка сертификатов - Докажите свою идентичность
  2. HTTPS перенаправление - Принудительно используйте безопасные соединения
  3. Правила брандмауэра - Разрешите трафику достигать вашего сервера

Разбивка проблемы на эти компоненты значительно облегчила диагностику и исправление.

Самый важный урок? Когда что-то не работает, проверяйте слой за слоем:

  • Правильно ли настроен nginx? (nginx -t)
  • Слушает ли nginx? (ss -tlnp)
  • Разрешает ли брандмауэр трафик? (firewall-cmd --list-all)
  • Работает ли это локально? (curl -I http://localhost)

Этот систематический подход сэкономил мне часы разочарования!

Обратная связь и вопросы

Мы будем рады услышать ваши отзывы об этом руководстве! Если у вас есть какие-либо вопросы или предложения по улучшению, пожалуйста, не стесняйтесь обращаться. Вы можете оставить комментарий ниже или связаться с нами через следующие каналы:

  1. Email: info@shadynagy.com
  2. Twitter: @ShadyNagy_
  3. LinkedIn: Shady Nagy
  4. GitHub: ShadyNagy

Нашли это полезным? Поделитесь этим с кем-то, кто борется с конфигурацией SSL!

Tags

#SSL#HTTPS#SSLCertificate#Nginx#RockyLinux#Linux#WebSecurity#SSLTroubleshooting#ServerConfiguration#IntermediateCertificate#Firewall#Firewalld#CertificateChain#HTTPSRedirect#NginxSSL#ForceHTTPS#Sectigo#LetsEncrypt#WebServerSetup#SSLConfiguration#TLS#RockyLinux9

Share

Shady Nagy

Shady Nagy

Software Innovation Architect

Topics

AI
Angular
dotnet
GatsbyJS
Github
Linux
MS SQL
Oracle
Shady Nagy
© 2026, All Rights Reserved.

Quick Links

Contact Us

Legal Stuff

Privacy NoticeCookie PolicyTerms Of Use

Social Media

githubtwitterlinkedin