← На главную

При работе с платформой «1С:Предприятие 8.3» (начиная с релиза 8.3.7 и выше) пользователи и разработчики нередко сталкиваются с ситуацией, когда в абсолютно чистой, разработанной с нуля конфигурации периодически появляется предупреждение: «Регистрация конфигурации в центре лицензирования не выполнена», а в окне «О программе» отображается статус «Недоступен центр лицензирования».

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

Причины возникновения ошибки в нетиповых конфигурациях

Проанализируем логику работы платформенного механизма контроля легальности использования программных продуктов:

1. Платформенный уровень проверки: Начиная с версии 8.3.7, контроль лицензирования вынесен на уровень ядра платформы и выполняется автоматически по протоколу HTTPS через порт 443. Проверка срабатывает независимо от наличия библиотек стандартых подсистем (БСП) или кода на встроенном языке. Отключить её программно из конфигуратора невозможно.
2. Принцип верификации самописок: При запуске клиентское приложение передает сигнатуру и метаданные конфигурации на сервер проверки. Если удаленный сервис лицензирования отвечает, что конфигурация с такими параметрами в реестре тиражных решений вендора отсутствует, платформа делает логичный вывод: конфигурация является оригинальной авторской разработкой. В этом случае в окне сведений устанавливается статус «Проверка выполнена успешно», и повторные окна не всплывают.
3. Сетевые сбои и блокировки: Если рабочая станция не может корректно завершить защищенную сессию с сервером (пакеты блокируются файрволом, зависают по таймауту или отбрасываются прокси-сервером), платформа не может определить статус базы и переходит в аварийный режим, выводя пользователю предупреждение с периодичностью в 15–20 минут.
4. Перехват SSL-трафика (SSL Inspection): В корпоративных сетях шлюзы безопасности часто выполняют подмену SSL-сертификатов для инспекции пакетов. Платформа 1С использует собственное хранилище доверенных корневых сертификатов (файл cacert.pem в каталоге bin) и при обнаружении подмененного сертификата разрывает соединение с ошибкой.
5. Остаточные идентификаторы поставщика: Если конфигурация создавалась путем очистки типовой конфигурации (например, «Управление торговлей» или «Бухгалтерия предприятия»), в заголовках метаданных могут остаться внутренние идентификаторы продуктов 1С, из-за чего платформа пытается верифицировать базу как коммерческий продукт.

Способ 1. Открытие доступа к серверам лицензирования на сетевом шлюзе

Рассмотрим самый быстрый и штатный способ устранения проблемы, если компьютеры имеют выход в сеть Интернет.

1. Обратимся к системным администраторам сети с запросом на разблокировку сетевого адреса центра лицензирования.
2. Необходимо открыть исходящий доступ по протоколу HTTPS (порт 443) к домену 1cv8update.com для рабочих станций пользователей или сервера 1С.
3. В настройках корпоративного межсетевого экрана и прокси-сервера добавим данный узел в список исключений для SSL-инспекции (без дешифрации и подмены сертификатов шлюза).
4. После применения сетевых правил запустим базу 1С. Платформа один раз свяжется с сервисом, зарегистрирует факт уникальности метаданных конфигурации и перестанет выдавать предупреждения.

Способ 2. Настройка подключения через inetcfg.xml при наличии корпоративного прокси

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

1. Перейдем в каталог установки платформы, в папку conf (например, C:\Program Files\1cv8\conf или C:\Program Files (x86)\1cv8\8.3.X.XXXX\bin\conf).
2. Создадим текстовый файл с именем inetcfg.xml в кодировке UTF-8.
3. Заполним файл структурой конфигурации сетевых подключений с указанием адреса и учетных данных прокси:
   Скопировать код

   
   <config xmlns="http://v8.1c.ru/ssl/inetcfg">
       <proxy protocol="http"
              host="proxy.domain.local"
              port="8080"
              user="ProxyUser"
              password="ProxyPassword"/>
       <proxy protocol="https"
              host="proxy.domain.local"
              port="8080"
              user="ProxyUser"
              password="ProxyPassword"/>
   </config>
   

4. Перезапустим клиентское приложение 1С:Предприятие и проверим статус лицензирования в окне «О программе».

Способ 3. Обновление корневых сертификатов платформы (cacert.pem)

В старых сборках платформы 8.3 (в частности 8.3.7 и 8.3.8) встроенный список доверенных центров сертификации может содержать устаревшие данные, что приводит к ошибке SSL Handshake даже при открытом доступе в интернет. Выполним следующие действия:

1. Найдем файл cacert.pem, расположенный в подкаталоге bin текущей версии платформы.
2. Скопируем актуальный файл cacert.pem из дистрибутива более свежего релиза платформы 1С или экспортируем актуальное хранилище доверенных корневых сертификатов Mozilla/cURL.
3. Заменим файл в каталоге bin и перезапустим 1С.

Способ 4. Проверка метаданных и конфигурации поставщика

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

1. Откроем базу в режиме Конфигуратор.
2. В главном меню перейдем в раздел Конфигурация -> Поддержка -> Настройка поддержки.
3. Если кнопка активна и внутри отображается конфигурация поставщика, снимем конфигурацию с поддержки полностью.
4. В свойствах корневого объекта метаданных проверим реквизиты Имя, Синоним и Версия. Они не должны совпадать с названиями стандартных тиражных программ.
5. Выполним сохранение конфигурации базы данных.

Поведение платформы в изолированных контурах

Проанализируем особенности работы баз в полностью закрытых сегментах сети (без выхода в интернет):

1. Если на рабочей станции сетевой интерфейс полностью отключен от внешних маршрутов, а локальный DNS-сервер моментально возвращает ошибку разрешения внешних доменных имен (Name Resolution Failure), платформа не зависает на ожидании ответа и переходит в режим «Проверка не выполнялась». При этом назойливые всплывающие окна не беспокоят пользователей.
2. Если же сетевые пакеты уходят в шлюз и молча отбрасываются по правилу DROP (вызывая долгие сетевые таймауты TCP/IP), платформа считает это техническим сбоем проверки и регулярно выводит сообщение об ошибке. В таком случае администраторам рекомендуется настроить быстрое отклонение пакетов (REJECT) на сетевом экране для узлов 1С либо настроить локальный DNS так, чтобы запросы к внешним серверам отсекались мгновенно.