Как исправить протокол HTTP на HTTPS в WSDL-описании 1С при работе через обратный прокси?

Системный администратор 1С v8.3 (Управляемые формы) 1С:Документооборот IT и автоматизация бизнеса
← На главную

При публикации веб-сервисов 1С для работы внешних приложений, таких как мобильный клиент 1С:Документооборот, системные администраторы часто сталкиваются с классической проблемой: внешнее соединение защищено SSL (HTTPS), но внутренний сервер работает по протоколу HTTP. В этой ситуации платформа 1С генерирует WSDL-описание, в котором в поле soapbind:address location жестко прописан протокол http. Мобильное приложение, получив такой файл, пытается продолжить работу без шифрования и терпит неудачу. Рассмотрим подробно, как решить эту задачу несколькими способами.

Анализ проблемы: почему мобильное приложение 1С выдает ошибку?

Разберем стандартную архитектуру: на внешнем контуре стоит Apache или Nginx с настроенным SSL-сертификатом. Он перенаправляет (проксирует) запросы на внутренний сервер IIS, где опубликована база 1С. Поскольку внутренний обмен идет по HTTP, платформа 1С «не знает», что клиент на самом деле обращается через защищенное соединение. При формировании WSDL-файла (ответ на запрос с параметром ?wsdl), 1С подставляет тот протокол, по которому запрос пришел на IIS. В итоге внешний клиент получает ссылку вида http://domain.ru/base/ws/service.1cws, хотя ожидает https.

Проанализируем ситуацию: даже если прокси-сервер корректно передает заголовки, платформа 1С в большинстве случаев игнорирует их при генерации тела XML-ответа. Это приводит к тому, что мобильное приложение не может авторизоваться или выполнить вызов метода веб-сервиса.

Способ 1: Настройка внутреннего SSL (решение через «петлю» доверия)

Наиболее надежный метод, к которому пришел автор обсуждения, — это включение HTTPS на внутреннем сервере IIS. Это заставляет 1С генерировать WSDL с правильным протоколом изначально. Рассмотрим этот процесс по шагам:

  1. Выпуск самоподписанного сертификата: На внутреннем сервере IIS создадим самоподписанный сертификат для доменного имени или IP-адреса сервера.
  2. Настройка привязки (Binding): В консоли управления IIS добавим для сайта https привязку на порту 443 (или любом другом свободном), выбрав созданный сертификат.
  3. Изменение конфигурации Apache: Теперь обратный прокси должен обращаться к IIS не по http://192.168.1.120, а по https://192.168.1.120.

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


SSLProxyEngine On
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off

ProxyPass /docum https://192.168.1.120/docum
ProxyPassReverse /docum https://192.168.1.120/docum

Преимущество метода: Платформа 1С получает запрос по HTTPS и автоматически формирует корректный location в WSDL. Вам не нужно вмешиваться в структуру XML-файла вручную.

Способ 2: Использование модуля замены в Apache (mod_substitute)

Если вы не хотите или не можете настраивать SSL на внутреннем сервере, можно воспользоваться «хирургическим» вмешательством в трафик. Модуль mod_substitute позволяет изменять содержимое ответа на лету. Мы найдем в WSDL строчку с http:// и заменим её на https://.

Проанализируем пример конфигурации для Apache:


<Location /docum>
    AddOutputFilterByType SUBSTITUTE text/xml application/xml
    Substitute "s|http://external-name.ru|https://external-name.ru|ni"
    
    ProxyPass http://192.168.1.120/docum
    ProxyPassReverse http://192.168.1.120/docum
</Location>

В данном примере флаги ni означают: n — использовать регулярные выражения, i — игнорировать регистр. Этот метод позволяет обмануть мобильное приложение, исправляя WSDL прямо в процессе передачи данных от 1С к клиенту.

Способ 3: Решение для пользователей Nginx (sub_filter)

Если в роли обратного прокси выступает Nginx, задача решается аналогично через модуль ngx_http_sub_module. Выясним, как должна выглядеть секция server:


location /docum {
    proxy_pass http://192.168.1.120/docum;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # Подмена протокола в теле ответа (WSDL)
    sub_filter 'http://$host' 'https://$host';
    sub_filter_once off;
    sub_filter_types text/xml application/xml;
}

Обратите внимание на директиву sub_filter_types. По умолчанию Nginx обрабатывает только text/html. Поскольку 1С отдает WSDL в формате text/xml или application/xml, этот параметр критически важен для работы замены.

Важные нюансы работы с мобильной платформой 1С

При настройке публикации через прокси следует учитывать особенности работы мобильного приложения 1С:Документооборот и других решений на мобильной платформе:

Выводы и рекомендации

Рассмотрев все варианты, мы видим, что самый стабильный способ — это настройка внутреннего HTTPS на IIS с самоподписанным сертификатом. Это избавляет от необходимости парсить и изменять XML-код ответов, что может быть ресурсозатратно при большом количестве запросов. Однако, если доступ к IIS ограничен, методы подмены строк через mod_substitute (для Apache) или sub_filter (для Nginx) являются отличной альтернативой, позволяющей запустить мобильное приложение 1С в защищенном режиме за считанные минуты.

← На главную