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

Shady Nagy — Wed, 11 Feb 2026 00:00:00 GMT

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

Представьте себе: я только что установил 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”

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

Ваш сертификат (Часть A)
Промежуточный сертификат (Часть 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;
    }
}

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

listen 443 ssl http2;
- 443 = Порт HTTPS
- ssl = Включить SSL
- http2 = Включить HTTP/2 для лучшей производительности
- Это заменяет устаревшую директиву ssl on;
ssl_certificate теперь указывает на fullchain вместо только вашего сертификата
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 читает конфигурации сверху вниз. Когда приходил запрос:

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

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

Шаг 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, но не в моём браузере?

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

Брандмауэр блокирует порт 80 (моя проблема!) - Конфигурация перенаправления была правильной, но входящий HTTP-трафик никогда не достигал nginx.
Кеш браузера - Браузеры агрессивно кешируют перенаправления. Решение: Тестируйте в режиме инкогнито или очистите кеш.
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.

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

Решения:

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

Откройте ваш сайт в Chrome
Нажмите F12 (Инструменты разработчика)
Ищите предупреждения во вкладке 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: Почему мой сертификат показывается как “небезопасный” даже после всех этих исправлений?

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

Несоответствие имени сертификата:
- Сертификат для www.shadynagy.com, но вы посещаете shadynagy.com
- Решение: Получите сертификат, который покрывает оба (SAN сертификат)
Истёкший сертификат:
- Проверьте дату истечения: openssl x509 -in certificate.crt -noout -dates
- Решение: Обновите сертификат
Смешанный контент:
- HTTPS-страница загружает HTTP-ресурсы
- Проверьте консоль браузера на предупреждения
Неправильный домен в конфигурации nginx:
- server_name не соответствует домену, который вы посещаете
- Решение: Добавьте все варианты домена в server_name
Сертификат не доверенный:
- Используется самоподписанный сертификат
- Решение: Получите сертификат от доверенного 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 может показаться пугающей поначалу, но как только вы поймёте части, это довольно логично:

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

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

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

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

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

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

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

Email: info@shadynagy.com
Twitter: @ShadyNagy_
LinkedIn: Shady Nagy
GitHub: ShadyNagy

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

Блог о .NET и архитектуре ПО — Shady Nagy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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