Расположение и настройка хранилища сертификатов в 1С

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

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

Начнем с того, что 1С не всегда использует собственное изолированное хранилище. Часто платформа опирается на системные механизмы операционной среды. Это означает, что администратору необходимо знать не только настройки конфигуратора, но и стандартные пути Windows или Linux. Корневой сертификат УЦ должен быть установлен в хранилище «Доверенные корневые центры сертификации» на уровне системы, чтобы 1С могла его увидеть.

Системное хранилище Windows и интеграция с 1С

В среде Microsoft Windows платформа 1С:Предприятие по умолчанию обращается к системному реестру и файловой структуре ОС для поиска доверенных корневых центров. Это наиболее распространенный сценарий для клиентских рабочих мест. Если вы установили сертификат только в личное хранилище пользователя, серверная часть 1С может его просто не увидеть.

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

• 🔐 Локальный компьютер: сюда устанавливаются сертификаты, необходимые для работы сервера 1С и всех пользователей на этой машине.
• 👤 Текущий пользователь: подходит только для толстого клиента, запущенного под конкретной учетной записью, но не для сервисов.
• 🌐 Доверенные корневые центры: критически важная папка, без сертификата в которой любая цепочка доверия будет разорвана.

Процесс установки требует прав администратора. После импорта файла .cer или .crt необходимо перезапустить службу Агент сервера 1С, чтобы изменения вступили в силу. Игнорирование этого шага — частая причина ошибок типа «Сертификат не найден» даже после успешного импорта.

⚠️ Внимание: При установке сертификата самоподписанного УЦ убедитесь, что вы не перепутали его с личным сертификатом пользователя. Личный сертификат содержит закрытый ключ и устанавливается в раздел «Личные», а корневой — всегда в «Доверенные».

Настройка хранилища внутри платформы 1С:Предприятие

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

Чтобы попасть в этот раздел, необходимо перейти в меню Администрирование → Настройки пользователей и прав → Настройки пользователей → Криптография. Здесь отображается список доступных сертификатов, которые видит текущий сеанс 1С. Если нужного сертификата здесь нет, значит, платформа не имеет к нему доступа на уровне ОС или прав доступа.

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

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

Особенности хранения в Linux-среде

Перенос серверов 1С на Linux стал стандартом отрасли, но это вносит свои коррективы в работу с SSL. В отличие от Windows, здесь нет единого реестра. Хранилище сертификатов 1С в Linux зависит от используемой криптобиблиотеки, чаще всего это OpenSSL или GnuTLS, которые поставляются с дистрибутивом.

По умолчанию 1С на Linux ищет корневые сертификаты в стандартных директориях системы, таких как /etc/ssl/certs или /etc/pki/tls/certs. Если ваш корневой сертификат УЦ отсутствует в этих папках или в объединенном файле ca-certificates.crt, соединение по HTTPS будет разорвано с ошибкой проверки подписи.

Для добавления нового доверенного центра необходимо скопировать файл сертификата в директорию /usr/local/share/ca-certificates/ (для Debian/Ubuntu) или /etc/pki/ca-trust/source/anchors/ (для CentOS/RedHat) и выполнить команду обновления кэша. Например, в Ubuntu это команда update-ca-certificates.

Дистрибутив Linux	Путь к хранилищу	Команда обновления
Ubuntu / Debian	/usr/local/share/ca-certificates/	update-ca-certificates
CentOS / RHEL	/etc/pki/ca-trust/source/anchors/	update-ca-trust extract
Alpine Linux	/usr/local/share/ca-certificates/	update-ca-certificates

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

Что делать, если 1С на Linux не видит системные сертификаты?

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

Работа с консолью управления кластером серверов

Для администраторов, управляющих серверным кластером, основным инструментом является консоль управления (MMC). Именно здесь настраиваются параметры безопасности для всего кластера в целом. Ошибки на этом уровне влияют на все базы данных, размещенные на данном сервере.

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

Также в консоли можно просмотреть активные сеансы и их параметры безопасности. Это помогает диагностировать, с какого именно клиента приходит запрос с неверным или отсутствующим сертификатом. Логи кластера часто содержат коды ошибок SSL, которые помогают сузить круг поиска проблемы.

• 🖥️ Свойства кластера: глобальные настройки шифрования трафика между клиентами и сервером.
• 🔑 Настройки рабочего процесса: параметры, определяющие, как конкретный процесс rphost обрабатывает криптографию.
• 📜 Журнал регистрации: место, где фиксируются события отклонения сертификатов с указанием причины ошибки.

⚠️ Внимание: Изменение настроек безопасности в консоли управления кластером требует перезапуска служб 1С. планируйте эти работы в нерабочее время, чтобы не прерывать сеансы пользователей.

Диагностика ошибок и логирование

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

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

Частой ошибкой является несоответствие имени сервера в сертификате и имени, по которому клиент обращается к базе. Если в сертификате указано server.local, а подключение идет по 192.168.1.5, платформа расценит это как нарушение безопасности. В таких случаях помогает добавление записи в файл hosts или перевыпуск сертификата с правильным Subject Alternative Name (SAN).

Также стоит проверить актуальность времени на сервере и клиенте. Рассинхронизация часов более чем на несколько минут приводит к тому, что даже валидный сертификат считается недействительным (либо еще не действующим, либо уже просроченным с точки зрения времени системы).

Автоматизация обновления сертификатов

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

Для Windows можно использовать PowerShell скрипты, которые проверяют дату истечения сертификата в хранилище и автоматически импортируют новый файл из сетевой папки. Для Linux аналогичную задачу решают скрипты на Bash в связке с планировщиком cron. Важно предусмотреть механизм уведомления администратора в случае неудачи обновления.

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

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

⚠️ Внимание: Интерфейсы и пути к файлам могут незначительно отличаться в зависимости от версии платформы 1С:Предприятие (8.3.10, 8.3.20 и новее) и конкретного дистрибутива Linux. Всегда сверяйтесь с официальным руководством администратора для вашей версии.

Можно ли использовать один сертификат для нескольких серверов 1С?

Да, если это wildcard-сертификат (например, *.mycompany.com) или сертификат с несколькими именами SAN. Такой подход упрощает администрирование, так как один файл подходит для всех серверов кластера.

Часто задаваемые вопросы (FAQ)

Где именно лежит файл хранилища сертификатов в Windows для 1С?

Физически системное хранилище Windows расположено в реестре. Для локального компьютера ключи находятся в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates. Однако работать с ними напрямую через реестр не рекомендуется, используйте оснастку certmgr.msc.

Почему 1С пишет «Сертификат не найден», хотя он установлен?

Наиболее вероятная причина — сертификат установлен в хранилище «Текущий пользователь», а служба 1С запускается от имени системы. Переместите сертификат в хранилище «Локальный компьютер» или установите его заново с правами администратора, выбрав соответствующую опцию.

Как проверить цепочку сертификатов в 1С?

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

Нужно ли перезагружать сервер после установки сертификата?

Полная перезагрузка сервера не обязательна, но необходимо перезапустить службу «Агент сервера 1С:Предприятия» (ragent). Это заставит процесс перечитать системное хранилище сертификатов.

Можно ли отключить проверку сертификатов в 1С?

Технически это возможно через параметры запуска с ключами игнорирования ошибок SSL, но категорически не рекомендуется в продуктивной среде. Это делает канал связи уязвимым для атак типа Man-in-the-Middle.