Работа с электронной цифровой подписью (ЭЦП) в веб-клиенте 1С через веб-браузер — задача, требующая ювелирной настройки всей цепочки взаимодействия: от физического токена на рабочем месте пользователя до пула приложений на веб-сервере. Ситуация значительно усложняется, когда в эту схему вмешивается VPN-соединение и веб-сервер IIS. Распространенной проблемой является то, что при подключении по VPN к базе 1С:Документооборот, опубликованной на IIS, система отказывается видеть аппаратный ключ eToken, а расширения для работы с файлами и криптографией просто не устанавливаются. При этом на веб-сервере Apache аналогичная схема может работать без сбоев.
В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем различия в поведении IIS и Apache, а также предоставим пошаговую инструкцию по локализации и решению этой сложной системной задачи.
Для того чтобы локализовать проблему, нам необходимо понять архитектурные различия между обработкой запросов веб-серверами Apache и IIS. Когда веб-клиент 1С инициализирует работу с криптографией, он пытается загрузить на компьютер пользователя внешние компоненты и расширения. Разберем три основные причины, по которым IIS может блокировать этот процесс в среде VPN.
1. Строгая политика MIME-типов в IIS
Для установки расширений работы с файлами и криптографией веб-клиент 1С запрашивает с сервера специальные файлы (компоненты с расширениями .cab, .jar или другие бинарные файлы). Веб-сервер Apache по умолчанию отдает неизвестные ему типы файлов как бинарный поток данных, что позволяет браузеру беспрепятственно скачать их. IIS, напротив, из соображений безопасности блокирует отдачу любых файлов, чьи расширения явно не зарегистрированы в его таблице MIME-типов. В результате браузер получает ошибку 404 или 403 при попытке загрузить компоненту 1С.
2. Проблема зон безопасности Internet Explorer и DNS-имен в VPN
При подключении через VPN пользователи часто обращаются к веб-серверу IIS по IP-адресу (например, http://192.168.1.50/DO). Для браузера Internet Explorer (и режима IE в современных браузерах) обращение по IP-адресу автоматически переводит узел в небезопасную зону «Интернет». В этой зоне запуск элементов ActiveX, скачивание неподписанных расширений и доступ к локальным криптопровайдерам компьютера жестко заблокированы политиками безопасности Windows.
3. Контекст безопасности пула приложений IIS (AppPool)
Если веб-сервер IIS настроен на проверку подлинности Windows (Windows Authentication), то при работе через VPN, когда клиентский компьютер авторизован под кэшированной доменной учетной записью, сквозная аутентификация (Single Sign-On) может не отрабатывать. Без полноценного подключения к контроллеру домена через VPN-туннель IIS не может проверить права пользователя, что приводит к сбоям при передаче защищенных запросов на установку компонент.
---
Рассмотрим пошагово, как правильно настроить клиентское рабочее место для работы с криптографией через VPN. Нам необходимо убедить операционную систему и браузер в том, что веб-сервер IIS является доверенным.
http://10.x.x.x/base настройте обращение по полному доменному имени (FQDN), например, http://iis-server.company.local/base.hosts по пути: C:\Windows\System32\drivers\etc\hosts. Добавьте туда строку вида:
10.x.x.x iis-server.company.localhttp://iis-server.company.local.---
Теперь перейдем к настройке сервера IIS. Нам нужно разрешить серверу отдавать статические файлы расширений 1С и настроить контекст безопасности пула приложений.
1. Регистрация MIME-типов в IIS:
Откройте Диспетчер служб IIS. Выберите ваш опубликованный сайт 1С и перейдите в раздел «Типы MIME» (MIME Types). Убедитесь, что для расширений файлов, которые использует 1С для установки плагинов, заданы соответствующие типы. Если какого-то расширения нет, добавьте его вручную:
.cab — Тип MIME: application/octet-stream.ext — Тип MIME: application/octet-stream2. Настройка пула приложений (Application Pool):
Перейдите в раздел «Пулы приложений» в IIS. Найдите пул, который обслуживает вашу базу 1С:Документооборот, нажмите на него правой кнопкой мыши и выберите «Дополнительные параметры». Найдите свойство «Загрузить профиль пользователя» (Load User Profile) и установите его в значение True. Это критически важно, так как криптопровайдерам Windows для работы с сертификатами часто требуется доступ к системным веткам реестра и локальным хранилищам, которые недоступны при значении False.
---
Проанализируем важную деталь, упомянутую в обсуждении: использование Microsoft Enhanced Cryptographic Provider v1.0 совместно с eToken. Здесь кроется серьезное техническое противоречие, которое часто мешает видимости ключей.
Провайдер Microsoft Enhanced Cryptographic Provider является исключительно программным криптопровайдером (Software CSP). Он физически не умеет работать со смарт-картами или USB-токенами напрямую. Если при генерации сертификата был выбран этот провайдер, закрытый ключ был сохранен в программный контейнер в профиле пользователя Windows, а не на защищенный чип eToken.
Для того чтобы система корректно видела закрытый ключ непосредственно на eToken, выполните следующие действия:
eToken Base Cryptographic Provider).Если сертификат скопирован в хранилище Windows, но 1С все равно не видит закрытый ключ (в свойствах сертификата отсутствует значок ключа), выполните принудительную перепривязку закрытого ключа. Откройте командную строку от имени пользователя и выполните команду:
certutil -user -repairstore my "Серийный_номер_сертификата"
После этого операционная система заново сопоставит публичный сертификат в хранилище с аппаратным контейнером закрытого ключа на eToken.
---
После того как настроены IIS, VPN и локальные драйверы токена, необходимо убедиться, что платформа 1С:Предприятие правильно взаимодействует с криптопровайдером. Рассмотрим, как программно проверить доступность менеджера криптографии на клиенте.
Для диагностики доступности криптопровайдеров на клиенте можно использовать следующий код на встроенном языке 1С:
&НаКлиенте
Процедура ПроверитьДоступностьКриптографии()
// Инициализируем менеджер криптографии для работы с алгоритмами RSA (если используем MS CSP)
ИмяПровайдера = "Microsoft Base Smart Card Crypto Provider";
ТипПровайдера = 1; // PROV_RSA_FULL
Попытка
МенеджерКриптографии = Новый МенеджерКриптографии(ИмяПровайдера, "", ТипПровайдера);
Сообщить("Менеджер криптографии успешно инициализирован на клиенте!");
// Получаем список доступных сертификатов в личном хранилище
Сертификаты = МенеджерКриптографии.ПолучитьСертификаты();
Если Сертификаты.Количество() = 0 Тогда
Сообщить("В личном хранилище пользователя не обнаружено сертификатов.", СтатусСообщения.Внимание);
Иначе
Для Каждого Сертификат Из Сертификаты Цикл
Сообщить("Найден сертификат: " + Сертификат.Субъект + " (Действителен до: " + Сертификат.ДатаОкончания + ")");
КонецЦикла;
КонецЕсли;
Исключение
Сообщить("Не удалось запустить менеджер криптографии. Ошибка: " + ОписаниеОшибки(), СтатусСообщения.Важное);
КонецПопытки;
КонецПроцедуры
Внедрение этой процедуры в отладочную обработку позволит вам быстро понять, на каком этапе происходит сбой — на уровне операционной системы (когда МенеджерКриптографии вообще не инициализируется) или на уровне видимости конкретного токена (когда менеджер доступен, но список сертификатов пуст).
Не забудьте зайти в базу 1С:Документооборот под правами администратора в раздел «Администрирование» -> «Настройки электронной подписи и шифрования» и на вкладке «Программы» явно добавить используемый криптопровайдер с указанием его точного системного имени и типа.
Следуя этим шагам, мы сможем обойти ограничения безопасности IIS и VPN-туннелей, обеспечив стабильную работу пользователей с электронной подписью на eToken в веб-клиенте 1С.