Добавить в корзинуПозвонить
Найти в Дзене
Типичный Админ

Настройка HTTPS для 1С:Аналитики через реверс-прокси Nginx

Задача выглядела простой: обеспечить безопасный доступ к серверу «1С:Аналитика» (версия 1.87.3) по HTTPS с использованием купленного SSL-сертификата. Сервер крутится на Windows Server 2022, сертификат выпущен для домена *.mydomain.ru. Платформа внутри использует «1С:Элемент» и собственную Axiom JRE 11. План «в лоб» — активировать HTTPS непосредственно на сервере Аналитики — провалился, и в итоге
Оглавление

Задача выглядела простой: обеспечить безопасный доступ к серверу «1С:Аналитика» (версия 1.87.3) по HTTPS с использованием купленного SSL-сертификата. Сервер крутится на Windows Server 2022, сертификат выпущен для домена *.mydomain.ru. Платформа внутри использует «1С:Элемент» и собственную Axiom JRE 11. План «в лоб» — активировать HTTPS непосредственно на сервере Аналитики — провалился, и в итоге я пришёл к классической схеме с реверс-прокси Nginx. Рассказываю по шагам, как всё происходило.

Этап 1. Попытка прямого включения SSL в Аналитике

Сначала я действовал по официальной инструкции техподдержки «1С:Элемент», адаптируя её под Windows.

1. Подготовил контейнер PKCS#12 из имеющихся файлов сертификата, приватного ключа и цепочки через OpenSSL, разместил его в C:\ProgramData\1C\ans\wd\data\security\.

2. Импортировал сертификат в доверенные корневые сертификаты Java (keystore cacerts) встроенной Axiom JRE. Я попробовал выполнить команду:

"C:\Program Files\Axiom\AxiomJRE-Pro-11-Full\bin\keytool.exe" -importcert -trustcacerts -keystore "C:\Program Files\Axiom\AxiomJRE-Pro-11-Full\lib\security\cacerts" -storepass pass123 -noprompt -alias mydomain.ru -file C:\bsa\cert\mydomain.ru.crt

и получил ошибку:

Keystore was tampered with, or password was incorrect.

Я предположил, что пароль по умолчанию changeit нужно изменить, но в Java-дистрибутивах пароль по умолчанию для cacerts — именно changeit. Я использовал pass123, поэтому keytool и ругался. После замены пароля на changeit и запуска командной строки от имени администратора импорт успешно выполнился.

3. Поправил security.yml и server.yml:

  • В C:\ProgramData\1C\ans\wd\config\security.yml добавил хранилище serverCertificateStorePFX, указав путь к .p12 и пароль.
  • В C:\ProgramData\1C\ans\wd\config\server.yml изменил эндпоинт на https, порт — на 443, прописал server-certificate-store: serverCertificateStorePFX.

После перезапуска службы Аналитика действительно начала отвечать по HTTPS. Панель управления открылась, я даже успешно залогинился. Однако сразу после входа выскочила ошибка «Ошибка обращения к серверу».

2026/05/26-20:28:31.330 [webflux-worker-45](232) I! Exception - Ошибка проверки сертификата сервера: Certificate for <127.0.0.1> doesn't match any of the subject alternative names: [],error-id=2002.88038...

Более глубокое изучение показало: внутренний компонент ProxyHTTPService.GetHandler пытался установить HTTPS-соединение с 127.0.0.1, а сертификат был выпущен на *.mydomain.ru, но не на localhost. Жёсткая проверка SAN (Subject Alternative Names) обрывала соединение.

Дальше перепробовал несколько обходных путей:

  • Вернуть хранилище на defaultKeyStore и добавить туда сертификат;
  • Настроить integrationBus.yml, добавив блок secure-endpoint и параметры domain, host;
  • Прописать системные свойства JVM для отключения проверки hostname (-Dorg.apache.http.ssl.hostnameVerifier=allowAll и аналоги).

Ни одна из этих попыток не помогла. Стало ясно: механизм проверки вшит глубоко в HTTP-клиент платформы, и без перевыпуска сертификата с нужными SAN или модификации кода проблему не решить.

Вывод: прямое навешивание SSL на встроенный веб-сервер 1С:Аналитики упирается в жёсткое внутреннее ограничение, которое невозможно обойти без серьёзного вмешательства.

Этап 2. Выбор реверс-прокси и его преимущества

Выход нашёлся сам собой: вынести терминирование SSL на внешний веб-сервер, а Аналитику оставить на внутреннем HTTP. Такой подход даёт несколько весомых плюсов:

  • Нет необходимости модифицировать само приложение — достаточно настроек Nginx.
  • Простое управление сертификатами: продление, замена или добавление новых сертификатов не требует перезапуска Аналитики, достаточно перезагрузить конфиг Nginx.
  • Централизованная точка входа: через один Nginx можно маршрутизировать несколько сервисов, добавлять балансировку, кэширование или сжатие.
  • Безопасность: Nginx принимает на себя TLS-рукопожатие, защиту от медленных атак, легко настраиваются ограничения по IP и другие политики.
  • Изолированность от Java-тонкостей: не нужно копаться в JVM и хранилищах сертификатов.

В моём случае к тому же уже имелся рабочий конфиг Nginx для другого продукта на той же платформе — «1С:Элемент». Оставалось адаптировать его под Windows и порты Аналитики.

Этап 3. Настройка Nginx в качестве реверс-прокси

Исходные данные:

  • Сервер: Windows Server 2022.
  • Nginx 1.31.1 установлен в C:\nginx.
  • Сертификаты: mydomain.ru.fullchain и mydomain.ru.key лежат в C:\bsa\cert\.
  • Аналитика слушает HTTP на порту 8181 (адрес 127.0.0.1:8181 — я изменил этот параметр в C:\ProgramData\1C\ans\wd\config\server.yml, чтобы «голая» незащищённая Аналитика была недоступна внешним клиентам).
  • Домен для доступа: analytics.mydomain.ru.

Я создал файл C:\nginx\conf.d\analytics.conf с такой конфигурацией:

map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream analytics_backend {
server 127.0.0.1:8181;
}
server {
listen 80;
server_name analytics.mydomain.ru;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
http2 on;
server_name analytics.mydomain.ru;
ssl_certificate C:/bsa/cert/mydomain.ru.fullchain;
ssl_certificate_key C:/bsa/cert/mydomain.ru.key;
ssl_protocols TLSv1.2 TLSv1.3;
client_body_buffer_size 1m;
location / {
proxy_pass http://analytics_backend/;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 86400;
proxy_send_timeout 86400;
proxy_connect_timeout 86400;
proxy_buffering off;
}
access_log C:/nginx/logs/analytics.access.log;
error_log C:/nginx/logs/analytics.error.log warn;
}

Важный нюанс: в Windows пути к файлам в директивах Nginx пишутся с прямыми слешами, например C:/bsa/cert/....

Проверил, что в основном nginx.conf есть

include C:/nginx/conf.d/*.conf;

и запустил Nginx вручную:

C:\nginx\nginx.exe

Переход в браузере по https://analytics.mydomain.ru/ открыл панель Аналитики — HTTPS работает, все внутренние запросы теперь ходят по HTTP на 127.0.0.1:8181 и не проверяют сертификат. Задача решена!

Этап 4. Превращаем Nginx в службу Windows

Ручной запуск годится только для тестов. Чтобы прокси автоматически стартовал при загрузке системы, оформим его как службу. Вариант с sc create отметаю: при остановке такой службы Windows просто «убьёт» процесс nginx без корректного завершения, что чревато потерянными логами и долгим освобождением порта.

Поэтому я использовал NSSM (Non-Sucking Service Manager) — крохотную утилиту, которая оборачивает консольную программу в полноценную службу и при остановке отправляет nginx -s quit, давая ему время на graceful shutdown.

1. Скачал последний NSSM с nssm.cc, распаковал, взял nssm.exe из папки win64 и положил в C:\nginx.

2. Остановил ручной экземпляр nginx:

C:\nginx\nginx.exe -s quit.

3. Запустил от администратора командную строку и выполнил:

C:\nginx\nssm.exe install nginx-analytics-proxy

4. В открывшемся окне указал:

  • Application Path: C:\nginx\nginx.exe
  • Startup directory: C:\nginx
  • На вкладке Details → Display name: Nginx reverse proxy for 1C Analytics

5. Нажал Install service.

Служба создалась. В оснастке services.msc поставил тип запуска «Автоматически» и запустил её. Можно и через командную строку:

net start nginx-analytics-proxy

Проверил, что после перезагрузки сервера служба стартует сама — всё отлично.

Теперь для перезагрузки конфигурации (например, после смены сертификата) достаточно выполнить:

C:\nginx\nginx.exe -s reload

Без остановки обслуживания.

Итоговая картина

Схема получилась надёжной и прозрачной:

  • Внешние клиенты обращаются по https://analytics.mydomain.ru → Nginx принимает TLS, проверяет сертификат.
  • Nginx проксирует запросы на внутренний http://127.0.0.1:8181, где работает сама Аналитика (привязана к localhost, снаружи не доступна).
  • Все компоненты Аналитики видят только HTTP и не спотыкаются о проверки сертификатов.
  • Nginx работает как системная служба и перезапускается вместе с сервером.

Потраченное на эксперименты с прямым SSL время не пропало даром: я глубже разобрался в устройстве платформы и окончательно убедился в преимуществах реверс-прокси. К тому же теперь у меня есть универсальный конфиг, который легко адаптировать для других сервисов на этой же платформе. В будущем, вероятно, настрою аналогичный прокси на Angie, но это уже совсем другая история.

Донаты принимаются на кошельки:

Yoomoney:

4100118091867315

Карта Т-Банк (бывший Тиньков):

2200 7017 2612 2077

Карта Альфа-Банк:

2200 1539 1357 2013