Проблема со слабым SSL сертификатом при внешнем доступе

Дата: 2026-01-10
Статус: ✅ РЕШЕНО
Проблема: При подключении к https://denkart.cdto.life/, https://school.cdto.life/ и https://docs.cdto.life/ используется старый самоподписанный SSL сертификат со слабым ключом (1024 bit RSA) вместо Let's Encrypt

🚀 Быстрое решение

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

sudo /home/cdto/DENKART/scripts/fix-ssl-external-ip-routing.sh

Или вручную:

sudo iptables -t nat -A OUTPUT -d 89.179.242.240/32 -p tcp --dport 443 -j DNAT --to-destination 10.218.14.37:443
sudo netfilter-persistent save

Описание проблемы

Симптомы

При обращении к доменам через браузер:
- "Соединение не установлено: Вероятная угроза безопасности"
- "EE certificate key too weak"

При проверке SSL сертификата через внешний IP:

subject=C = PL, ST = Some-State, O = Mini Webservice Ltd
issuer=C = PL, ST = Some-State, CN = Mini Webservice Ltd
RSA Public-Key: (1024 bit)  # ❌ Слабый ключ!
Verify return code: 66 (EE certificate key too weak)

Важное открытие

Проблема НЕ на сервере! Диагностика показала:
- ✅ На сервере все правильно настроено
- ✅ Сертификаты Let's Encrypt существуют и правильные
- ✅ HAProxy использует правильные сертификаты
- ✅ При подключении к локальному IP (192.168.1.112) используется правильный Let's Encrypt сертификат
- ❌ При подключении через внешний IP (89.179.242.240) используется старый самоподписанный сертификат
- ❌ Старый сертификат "Mini Webservice Ltd" НЕ найден на сервере

Результаты диагностики

✅ Что работает правильно:

  1. Сертификаты Let's Encrypt:
  2. denkart.cdto.life: Let's Encrypt (до 2026-04-08)
  3. school.cdto.life: Let's Encrypt (до 2026-03-27)

  4. docs.cdto.life: Let's Encrypt (до 2026-04-08)

  5. HAProxy конфигурация:

  6. Использует правильные сертификаты из /etc/haproxy/certs/
  7. Явно указан дефолтный сертификат denkart.cdto.life.pem

  8. Конфигурация корректна

  9. Локальный доступ:

  10. При подключении к 192.168.1.112:443 используется правильный Let's Encrypt сертификат
  11. При подключении к 10.218.14.37:443 (IP контейнера) используется правильный Let's Encrypt сертификат

❌ Проблема при внешнем доступе:

  • При подключении к 89.179.242.240:443 используется старый самоподписанный сертификат
  • Старый сертификат "Mini Webservice Ltd" НЕ найден на сервере
  • Все домены (denkart.cdto.life, school.cdto.life, docs.cdto.life) показывают один и тот же старый сертификат

Возможные причины

1. SSL терминация на роутере (НАИБОЛЕЕ ВЕРОЯТНО)

Роутер может иметь встроенную SSL терминацию или прокси, который использует старый сертификат.

Признаки:
- Внешний IP (89.179.242.240) находится за роутером (192.168.1.1)
- Трафик проходит через роутер до сервера
- Старый сертификат не найден на сервере

Решение:
1. Проверить настройки роутера на наличие SSL терминации или HTTPS прокси
2. Отключить SSL терминацию на роутере, если включена
3. Убедиться, что проброс портов работает в режиме "pass-through" (без SSL терминации)

2. Прокси/CDN/балансировщик перед сервером

Возможно, перед сервером есть промежуточное устройство (прокси, CDN, балансировщик нагрузки), которое выполняет SSL терминацию.

Решение:
1. Проверить, нет ли прокси/CDN/балансировщика перед сервером
2. Обновить сертификат на промежуточном устройстве
3. Или отключить SSL терминацию на промежуточном устройстве

3. Неправильная настройка проброса портов на роутере

Проброс портов на роутере может быть настроен неправильно:
- Перенаправляет трафик не туда, куда нужно
- Использует SSL терминацию вместо pass-through
- Перенаправляет на другой порт или другой сервер

Решение:
1. Проверить настройки проброса портов на роутере:
Внешний IP: 89.179.242.240:443 → Внутренний IP: 192.168.1.112:443
2. Убедиться, что проброс работает в режиме "pass-through" (TCP forwarding)
3. Не использовать режим "SSL termination" или "HTTPS proxy"

4. Провайдер/ISP перехватывает HTTPS трафик

Некоторые провайдеры могут перехватывать HTTPS трафик для мониторинга или фильтрации.

Решение:
- Обратиться к провайдеру для уточнения
- Попросить отключить SSL терминацию/перехват трафика
- Использовать VPN для обхода перехвата (не рекомендуется для продакшена)

5. Кэширование SSL сессий

SSL сессии могут быть закэшированы на промежуточных устройствах (роутер, прокси, CDN).

Решение:
- Подождать 10-15 минут для истечения SSL сессий
- Очистить кэш браузера
- Попробовать другой браузер или устройство

Решение ✅

✅ Проблема решена!

Причина: Трафик с сервера к внешнему IP (89.179.242.240) проходит через OUTPUT chain iptables, а не через PREROUTING. Поэтому требуется дополнительное правило DNAT в OUTPUT chain.

Исправление: Добавлено правило OUTPUT в iptables для перенаправления трафика к внешнему IP на контейнер.

Автоматическое исправление

sudo /home/cdto/DENKART/scripts/fix-ssl-external-ip-routing.sh

Скрипт автоматически:
1. Проверит существующие правила iptables
2. Добавит правило OUTPUT (если отсутствует)
3. Сохранит правила для автоматической загрузки после перезагрузки
4. Проверит SSL сертификаты после исправления

Ручное исправление

# Добавление правила OUTPUT в iptables
sudo iptables -t nat -A OUTPUT -d 89.179.242.240/32 -p tcp --dport 443 -j DNAT --to-destination 10.218.14.37:443

# Сохранение правил
sudo netfilter-persistent save
# или
sudo iptables-save | sudo tee /etc/iptables/rules.v4

Проверка решения

После применения исправления все три домена должны использовать правильные Let's Encrypt сертификаты:

# Проверка всех доменов
for domain in denkart.cdto.life school.cdto.life docs.cdto.life; do
    echo "=== $domain ==="
    openssl s_client -connect 89.179.242.240:443 -servername "$domain" < /dev/null 2>&1 | grep -E "subject=|issuer=|Verify return code" | head -3
    echo ""
done

Ожидаемый результат:

=== denkart.cdto.life ===
subject=CN = denkart.cdto.life
issuer=C = US, O = Let's Encrypt, CN = R12
Verify return code: 0 (ok)

=== school.cdto.life ===
subject=CN = school.cdto.life
issuer=C = US, O = Let's Encrypt, CN = R13
Verify return code: 0 (ok)

=== docs.cdto.life ===
subject=CN = docs.cdto.life
issuer=C = US, O = Let's Encrypt, CN = R13
Verify return code: 0 (ok)

Дополнительные шаги (если проблема сохраняется)

Шаг 1: Проверка настроек роутера

  1. Войдите в панель управления роутером (обычно 192.168.1.1 или 192.168.0.1)
  2. Найдите раздел "Port Forwarding" / "Виртуальные серверы" / "Проброс портов"
  3. Проверьте настройку для порта 443:
    Внешний порт: 443 (TCP) Внутренний IP: 192.168.1.112 Внутренний порт: 443 (TCP)
  4. Убедитесь, что режим - "TCP forwarding" или "Pass-through", а НЕ "SSL termination" или "HTTPS proxy"

Шаг 2: Проверка SSL терминации на роутере

  1. В панели управления роутером найдите раздел "Firewall" / "Security" / "SSL"
  2. Проверьте, нет ли включенной опции "SSL Termination" или "HTTPS Proxy"
  3. Если есть - отключите её
  4. Перезагрузите роутер

Шаг 3: Проверка других устройств на пути

Если после проверки роутера проблема сохраняется:

  1. Проверьте, нет ли другого устройства (балансировщик, прокси, CDN) перед сервером
  2. Проверьте настройки провайдера (возможно, они используют прокси/CDN)
  3. Обратитесь к провайдеру для уточнения

Шаг 4: Альтернативное решение - использование другого порта

Если проблема не решается на уровне роутера/провайдера:

  1. Настроить HAProxy на другой порт (например, 4443)
  2. Настроить проброс порта 443 → 192.168.1.112:4443
  3. Использовать порт 4443 для HTTPS

ВНИМАНИЕ: Это не решит проблему полностью, так как браузеры будут использовать стандартный порт 443.

Диагностика

Автоматическая диагностика

Используйте скрипт диагностики:

sudo /home/cdto/DENKART/scripts/diagnose-ssl-certificate-issue.sh

Скрипт автоматически проверит:
1. Сертификаты Let's Encrypt
2. Сертификаты в HAProxy
3. Конфигурацию HAProxy
4. SSL изнутри контейнера (правильный путь)
5. SSL через локальный IP (правильный путь)
6. SSL через внешний IP (проблемный путь)
7. Маршрутизацию iptables
8. Процессы на порту 443

Ручная проверка

# Проверка через локальный IP (должен работать правильно)
openssl s_client -connect 192.168.1.112:443 -servername denkart.cdto.life < /dev/null 2>&1 | grep -E "subject=|issuer=|Verify return code"

# Проверка через внешний IP (показывает проблему)
openssl s_client -connect 89.179.242.240:443 -servername denkart.cdto.life < /dev/null 2>&1 | grep -E "subject=|issuer=|Verify return code"

# Проверка маршрутизации
sudo iptables -t nat -L PREROUTING -n -v | grep 443

Текущий статус

✅ Что исправлено на сервере:

  1. ✅ Обновлена конфигурация HAProxy с явным указанием дефолтного сертификата
  2. ✅ Все сертификаты Let's Encrypt правильно настроены
  3. ✅ HAProxy перезапущен и работает корректно
  4. ✅ При локальном доступе используется правильный сертификат

⚠️ Что требует решения:

  1. ⏳ Проверка и настройка роутера (отключение SSL терминации, если включена)
  2. ⏳ Проверка проброса портов на роутере
  3. ⏳ Проверка, нет ли прокси/CDN перед сервером
  4. ⏳ Возможно, обращение к провайдеру

Связанные файлы

  • Скрипт диагностики: /home/cdto/DENKART/scripts/diagnose-ssl-certificate-issue.sh
  • Скрипт исправления: /home/cdto/DENKART/scripts/fix-ssl-weak-certificate.sh
  • Конфигурация HAProxy: /etc/haproxy/haproxy.cfg (в контейнере BBB-CONT22-1)
  • Документация: /home/cdto/DENKART/docs/troubleshooting/ssl-weak-certificate-fix.md
  • Документация по пробросу портов: /home/cdto/DENKART/docs/setup/router-port-forwarding.md

Рекомендации

  1. Немедленные действия:
  2. Проверить настройки роутера на наличие SSL терминации
  3. Отключить SSL терминацию, если включена

  4. Проверить настройки проброса портов

  5. Если проблема сохраняется:

  6. Обратиться к провайдеру для уточнения
  7. Проверить, нет ли прокси/CDN перед сервером

  8. Рассмотреть использование VPN для обхода (не для продакшена)

  9. Долгосрочное решение:

  10. Настроить мониторинг SSL сертификатов
  11. Настроить автоматическое обновление сертификатов
  12. Документировать настройки роутера и провайдера

Статус: ✅ Проблема решена
Решение: Добавлено правило OUTPUT в iptables для перенаправления трафика к внешнему IP
Приоритет: Высокий (влияет на безопасность и доступность)
Дата исправления: 2026-01-10