Created attachment 7089 [details] Сертификат, полученный от 1С, требуется для сервера предприятия 1С для доступа к сервису 1С-ЭДО. Нужен для сервера предприятия 1С. Пока не добавим в список доверенных, сервер 1С не получит доступа к сервису 1C-ЭДО.
Created attachment 7090 [details] Оригинальная инструкция от 1С
Для Альт ручная инструкция будет такая (от рута, естественно): openssl x509 -inform DER -in ss.crt -out ss.der # преобразуем формат cat ss.der >> /usr/share/ca-certificates/ca-bundle.crt # дописываем в бандл Перезагрузки сервера предприятия не требуется, но он должен быть актуальный (сейчас 8.3.10.2252).
(In reply to comment #2) > Для Альт ручная инструкция будет такая (от рута, естественно): > openssl x509 -inform DER -in ss.crt -out ss.der # преобразуем формат > cat ss.der >> /usr/share/ca-certificates/ca-bundle.crt # дописываем в бандл > > Перезагрузки сервера предприятия не требуется, но он должен быть актуальный > (сейчас 8.3.10.2252). Зачем вам нужно добавлять промежуточный сертификат в список корневых сертификатов? Объясните, пожалуйста, чего вы хотите добиться этой операцией.
Created attachment 7092 [details] Архив корневых сертификатов и инструкция от 1С
Сегодня прислали архив сертификатов, необходимых для взаимодействия с сервисом 1С-ЭДО. С сервисом взаимодействует сервер (не клиент), и сделано так для того, чтобы обмен мог происходить в фоновом режиме по расписанию вне зависимости от присутствия пользователя. Не представляю какая беда может случиться если добавить дополнительные сертификаты в бандл, но что без этого сервис 1С-ЭДО не будет доступен при установке на платформе Альт, это совершенно точно. Почему сертификаты не пакуются вместе с платформой 1С, почему 1С предпочитает обращаться за ними к системе - пока не ясно.
(В ответ на комментарий №3) > Объясните, пожалуйста, чего вы хотите добиться этой операцией. Да, конечно. Цель - устранение ошибки установки соединения с серверами сервиса 1С-ЭДО. Почему потребовалось в список корневых? А не знаю, возможно правильно добавить куда-то в другое место. Факт тот что так сработало, и это есть зацепка к решению проблемы. Сегодня из 1С прислали всю цепочку сертификатов в архиве, посмотрите пожалуйста.
И ещё один момент. В CentOS, Fedora, RHEL (как минимум) в составе ca-certificates поставляется update-ca-trust. У нас нет, хотя тоже решение.
(In reply to comment #5) ... > Почему сертификаты не пакуются вместе с платформой 1С, почему 1С предпочитает > обращаться за ними к системе - пока не ясно. Почему вы не прояснили это изначально? У вас есть проблема взаимодействия клиент-сервер, причем из вашего описания вообще не следует что она есть. Вместо этого предлагается изменить список корневых сертификатов для всех пользователей ALTLinux . Напомню еще раз, это _корневые_ сертификаты, т.е. самый высокий уровень доверия, которые прошли проверку и независимый аудит. Я не поленился и посмотрел что предлагается добавить, это обычные промежуточные сертификаты от Symantec, которые описаны тут https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&actp=crosslink&id=info2045 Добавьте свои сертификаты в цепочку доверия на клиенте и ходите куда хотите.
(В ответ на комментарий №8) > Добавьте свои сертификаты в цепочку доверия на клиенте и ходите куда хотите. Идея хорошая, но - нет, в данном случае не поможет. Обращение к удалённому сервису (как уже упоминалось в комментарии #5) происходит в контексте сервера. Соответственно, что бы мы ни делали на клиенте, проблему это не устраняет. В дополнение, сообщаю про аналогичную ошибку при попытке отправки подписанной (действующим ключом) заявки на обновление сертификата для сдачи отчётов в контролирующие органы (все и ежегодно). В результате пользователи, чьи информационные базы данных обслуживаются серверами 1С:Предприятие 8 под управлением платформы ALT, принуждаются к распечатке заявления на бумаге, его подписанию вручную и отправке ногами. Или администратор сервера должен опять-таки вручную дописывать сертификат сервиса в ca-bundle.crt на каждой платформе. Признаю что проблема может не относиться к ca-certificates напрямую и прошу совета, на какой компонент её следует правильно адресовать. Предлагаемый вариант решения - оговорить механизм добавления сертификатов, получаемых из доверенного источника, администратором конкретной системы, не затрагивая ca-certificates. Может быть, alterator?