Как устранить ошибку отправки почты с SSL в 1С v8.3 в клиент-серверном режиме на Windows Server 2008 R2?

← На главную

Отправка электронной почты непосредственно из среды 1С:Предприятие — одна из базовых функций современных учетных систем. Однако при переходе на защищенное соединение (SSL/TLS) на устаревших серверных операционных системах, таких как Windows Server 2008 R2, администраторы и разработчики часто сталкиваются с труднообъяснимыми сбоями. Особенно загадочной выглядит ситуация, когда в файловой базе под учетной записью администратора почта уходит без проблем, а при переносе базы в клиент-серверный режим (на MS SQL) система выдает ошибку:

{ОбщийМодуль.УправлениеЭлектроннойПочтой.Модуль(1145)}: Ошибка при вызове метода контекста (Подключиться): SMTP SERVER BUG (invalid challenge): ￮￮@TX Can not authenticate to SMTP server: 334

В этой статье мы подробно разберем, почему возникает эта ошибка, проанализируем разницу в поведении файлового и серверного режимов 1С, и шаг за шагом настроим операционную систему и окружение для стабильной работы почты.

Выясняем причину: почему в файловом режиме работает, а в серверном — нет?

Для того чтобы понять природу этой проблемы, нам необходимо рассмотреть, как именно исполняется код в различных режимах работы платформы «1С:Предприятие 8.3».

Когда мы запускаем базу в файловом режиме, весь код (включая процедуры общего модуля УправлениеЭлектроннойПочтой) выполняется на стороне клиентского приложения непосредственно на компьютере пользователя. Процесс выполняется в контексте текущей учетной записи Windows (например, Администратора). Этот пользователь имеет полные права в системе, доступ к сети, локальным криптографическим сертификатам, системному реестру и настройкам прокси-сервера.

В клиент-серверном режиме ситуация кардинально меняется. Практически все операции по отправке почты выполняются на сервере приложений 1С в контексте рабочих процессов rphost.exe. По умолчанию служба «Агент сервера 1С:Предприятия» работает под специальной локальной учетной записью (обычно это USR1CV8 или NetworkService). Эта учетная запись имеет крайне ограниченные права в операционной системе Windows Server.

Из-за этих ограничений возникают следующие проблемы:

Отсутствие необходимых сертификатов шифрования. Учетная запись USR1CV8 не имеет доступа к хранилищу доверенных корневых сертификатов текущего пользователя-администратора. Из-за этого при установке защищенного SSL-соединения сервер 1С не может проверить валидность SSL-сертификата почтового сервера (например, Gmail или Zoho).
Блокировка портов брандмауэром. Сетевые правила для учетной записи службы могут отличаться от правил для интерактивного пользователя. Брандмауэр или антивирусное ПО могут блокировать исходящие соединения процесса rphost.exe на порты 465 и 587.
Проблемы с авторизацией TLS. Операционная система Windows Server 2008 R2 по умолчанию не поддерживает современные протоколы шифрования TLS 1.2 для системных служб без установки специальных обновлений и настройки реестра.

Анализируем ошибку SMTP SERVER BUG (invalid challenge): 334

Давайте разберем по шагам, что происходит на уровне почтового протокола SMTP при возникновении этой ошибки.

Во время сессии авторизации платформа 1С отправляет почтовому серверу запрос на авторизацию. В ответ сервер присылает код ответа 334, который сигнализирует о готовности принять зашифрованные учетные данные (логин и пароль в формате Base64). Вместе с кодом 334 сервер присылает строку-вызов (challenge) — например, 334 VXNlcm5hbWU6 (что переводится как «Username:»).

Почтовый клиент 1С ожидает получить корректную строку, но из-за некорректного SSL/TLS-рукопожатия (handshake) или искажения сетевого трафика антивирусным ПО, встроенная в 1С почтовая библиотека получает поврежденный буфер данных. Вместо понятного текста библиотека видит бинарный мусор (в логе он отображается нечитаемыми символами вроде ￮￮@TX). Платформа расценивает это как баг почтового сервера и аварийно прерывает сессию.

Решение 1. Включение поддержки TLS 1.2 в Windows Server 2008 R2

Современные почтовые гиганты (Google, Zoho, Yandex) из соображений безопасности давно отключили поддержку старых протоколов SSL v3, TLS 1.0 и TLS 1.1. Они требуют обязательного использования протокола TLS 1.2.

В операционной системе Windows Server 2008 R2 поддержка TLS 1.2 для системных служб отключена по умолчанию. Чтобы исправить это, нам необходимо выполнить следующие действия:

Шаг 1. Установим официальное обновление безопасности от Microsoft KB3140245 (или Easy Fix пакет), которое добавляет поддержку протоколов TLS 1.1 и TLS 1.2 в системную библиотеку WinHTTP.

Шаг 2. Активируем протокол TLS 1.2 в системном реестре Windows. Для этого создадим и запустим reg-файл со следующим содержимым:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

Шаг 3. Включим принудительное сильное шифрование для компонентов .NET Framework. Это критически важно, так как платформа 1С активно использует эти системные библиотеки при работе с криптографией. Выполним импорт следующих настроек в реестр:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

После внесения изменений в реестр обязательно выполним перезагрузку сервера, чтобы изменения вступили в силу.

Решение 2. Проверка контекста учетной записи службы 1С

Если обновление операционной системы не помогло, нам нужно проверить влияние учетной записи, под которой запускается сервер 1С.

Проанализируем гипотезу с правами доступа. Для этого откроем оснастку «Службы» (Services.msc) на рабочем сервере, найдем службу «Агент сервера 1С:Предприятия 8.3», перейдем в ее свойства на вкладку «Вход в систему» и временно переключим запуск службы с системного пользователя USR1CV8 на учетную запись локального Администратора.

Перезапустим службу сервера 1С и проверим отправку почты из базы в клиент-серверном режиме. Если после этого почта успешно ушла, мы локализовали проблему — дело в ограничениях прав пользователя USR1CV8.

Чтобы вернуть службу 1С на безопасного системного пользователя и при этом сохранить работоспособность почты, выполним следующие настройки:

Предоставим пользователю USR1CV8 права на чтение папки с ключами шифрования Microsoft CryptoAPI. По умолчанию эта папка находится по пути: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.
Импортируем необходимые SSL-сертификаты почтового провайдера непосредственно в хранилище сертификатов учетной записи службы 1С. Для этого можно использовать утилиту certmgr.msc, запустив ее из-под контекста пользователя USR1CV8 через командную строку.

Решение 3. Исключение сетевого сканирования и фильтрации трафика

Очень часто искажение зашифрованного SSL-трафика происходит из-за вмешательства систем защиты (антивирусов и файрволов). Такие программы, как Kaspersky Endpoint Security или Dr.Web, используют технологию «Инспекция сетевых пакетов» (SSL/TLS interception).

Антивирус перехватывает трафик процесса rphost.exe на лету, расшифровывает его с помощью собственного самоподписанного сертификата, проверяет на вирусы, заново шифрует и отправляет дальше. Но поскольку служба сервера 1С не доверяет временному сертификату антивируса, происходит сбой дешифрования данных, что и выливается в искаженную строку ￮￮@TX при ответе 334.

Чтобы решить эту проблему, добавим исполняемые файлы платформы 1С (в особенности rphost.exe) в список исключений вашего антивирусного ПО на сервере. Нам нужно полностью отключить проверку защищенного трафика (SSL/HTTPS) для процессов 1С.

Решение 4. Корректная настройка туннелирования через Stunnel

Если по каким-то причинам обновить операционную систему невозможно, администраторы часто прибегают к использованию сторонней утилиты Stunnel. Она запускается локально на сервере, принимает незашифрованный трафик от 1С на обычный порт (например, 25) и сама отправляет его в зашифрованном виде (SSL) на порт почтового сервера (например, 465).

В тексте темы упоминается ошибка POP3 connection broken in response при попытке использовать Stunnel. Разберем, почему это произошло.

Когда мы настраиваем проброс почты через локальный прокси-сервер Stunnel, в настройках почтового профиля 1С мы обязательно должны отключить использование защищенного соединения SSL/TLS. Посмотрим на логику процесса:

Если флаг SSL в 1С включен, то платформа 1С пытается сама зашифровать трафик перед отправкой на Stunnel.
Stunnel, в свою очередь, ожидает получить от 1С обычный открытый текст, чтобы зашифровать его своими силами.
Происходит двойное шифрование, которое приводит к краху сессии соединения на стороне Stunnel.

Настроим файл конфигурации stunnel.conf правильно:


[gmail-smtp]
client = yes
accept = 127.0.0.1:25
connect = smtp.gmail.com:465

В настройках системной учетной записи почты в самой 1С укажем адрес сервера 127.0.0.1, порт 25, снимем все галочки безопасного соединения SSL и укажем стандартные параметры авторизации. При такой конфигурации обмен данными гарантированно пойдет без ошибок.

Пошаговый чек-лист для исправления проблемы

Для быстрого устранения неполадок рекомендуем придерживаться следующего алгоритма:

Убедимся, что для отправки почты через Gmail или Zoho мы используем специальный Пароль для приложений, сгенерированный в веб-интерфейсе почтового ящика, а не основной пароль от учетной записи.
Проверим наличие обновлений Windows Server 2008 R2 и обязательно установим пакет KB3140245.
Внесем изменения в системный реестр для принудительной активации протокола TLS 1.2 и сильного шифрования .NET.
Добавим каталог установки платформы 1С (папку bin) и процесс rphost.exe в исключения сканирования антивирусного ПО на сервере приложений.
Перезапустим сервер для применения всех системных изменений.

Выполнив указанные шаги, мы полностью устраним несовместимость криптографических протоколов и обеспечим надежную и безопасную отправку писем из клиент-серверной базы 1С.