Ошибка при проверки сертификат no error

Разгребая свои очередные заметки по тому, каким образом была решена та или иная проблема я наткнулся на, казалось бы, простую, на первый взгляд, проблему – ошибку “Ошибка при получении свойства сертификата (0x00000000)”, которая генерировалась при попытке установки нового сертификата в 1С. Но я потратил почти день на поиски решения… Наверное, в силу небольшого опыта работы с 1С. Мне редко приходится заниматься 1С, но иногда какие-то задачи на меня прилетаю.

По итогу решение оказалось простое, но не совсем очевидное (да, это был кэш). Возможно, это позволит сэкономить вам какое-то время при решении подобное проблемы.

Описание проблемы

При проверки настроек сертификата электронной подписи в 1С геренируется ошибка “Ошибка при получении свойства сертификата (0x00000000)”:

Окружение

Версия платформы: 1С:Предприятие 8.3 (8.3.17.1851)/

Конфигурация 1С: Управление торговлей, редакция 11 (11.4.13.282) – серверная версия.

Версия Крипто Про: 5.0.12000 KC1

Операционная системы: Windows Server 2008 R2 Standard x64.

ЭЦП расположена на токене Rutoken Lite.

Какие шаги не помогли решить проблемы

Итак, какие шаги я выполнял для устранения проблемы, но они не помогли решить проблему:

1. В Крипто Про я протестировал контейнер закрытого ключа. Проблем не обнаружено. Закрытый ключ присутствует на токене.

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

3. Также я установил сертификат в личный контейнер пользователя.

4. Еще пробовал установить сертификат в личный контейнер пользователя вот таким способом.

5. Проверил наличие закрытого ключа в личном контейнере пользователя.

6. Пометил сертификат на удаление, удилил его и попробовал добавить сертификат заново.

7. Перезагружал сервер после выполнения шагов выше (несчетное количество раз).

8. Обновил версию Крипто Про до 5.0.12000 KC1.

Иногда менялась последовательность и комбинация действий. Это из того, что вспомнилось. Возможно делал что-то еще, но не столь важное.

Решение

Как видно из предыдущего раздела я выполнил довольно много действий, но тут я приведу то последнее действие, которое в итоге помогло мне решить проблему. Да, скорее всего, какие-то из действий предыдущего раздела были необходимо и без них решение ниже не помогло бы. Но я не могу сказать какие именно.

Как в итоге я смог устранить эту ошибку:

1. Пометил сертификат на удаление и удалил через удаление помеченных на удаление объектов (ток его удалил, другое ничего не удалял).

2. Очистил кэш 1С для пользователя.

3. Повторно импортировал сертификат.

Да, все таки думаю, что это было из-за кэша 1С. Где-то осела какая-то не актуальная информация о сертификате.

Это еще одна краткая шпаргалка по решению проблемы, с которой я столкнулся. Как оказалось по итогу это была ошибка проверки корневого сертификата.

Я приведу пример ошибки с сертификатом для системы хранения кода Gitea. Gitea может выступать в качестве репозитория контейнеров. Именно в сценарии использования Gitea в качестве репозитория контейнеров генерировалась ошибка. Точнее это даже не ошибка самой системы Gitea, а скорее ошибка клиента Docker и curl, которые вызваны отсутсвием необходимых корневого и промежуточного ЦС.

Симптомы

Есть wilcard сертификат от GlobalSign. Есть система для хранения и версионирования исходного кода Gitea. Для доступа к веб сервисам Gitea используется wildcard сертификат от GlobalSign. При использовании браузера проблем с сертификатом или доступами нет. Сертификат идентифицируется, как сертификат от доверенного ЦС.

Однако, если попробовать использовать клиент утилиту curl, то генерируется ошибка проверки корневого сертификата:

curl https://code.infoplex.ru

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Еще одна ошибка при попытке авторизоваться в репозитории Docker контейнеров:

docker login code.infoplex.ru

Error response from daemon: Get code.infoplex.ru/v2/: x509: certificate signed by unknown authority

Окружение

Ошибка воспроизводилась на следующих ОС – Linux Mint 21.1 Cinnamon и Ubuntu Server 22.04.

На RHEL дистрибутивах не проверял.

Ошибка проверки корневого сертификата – решение

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

Сохранение сертификата

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

Сначала сохраним сертификат корневого ЦС:

Укажем расположение, имя и формат файла:

Аналогичным образом сохраним сертификат промежуточного ЦС:

Импорт сертификата в доверенные (метод 1)

Скопируем сертификаты в директорию ca-certificates:

cd $HOME/Downloads/crts/
sudo cp GlobalSign_Root_CA.crt AlphaSSL_CA.crt /usr/share/ca-certificates

Запустим обновление списка корневых ЦС:

sudo dpkg-reconfigure ca-certificates

На первой странице мастера подтверждаем вносимые изменения:

Отмечаем новый добавленные сертификаты:

Вы должны увидеть примерно следующий вывод на консоль:

Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
rehash: warning: skipping duplicate certificate in A.pem
rehash: warning: skipping duplicate certificate in GlobalSign_Root_CA.pem
2 added, 0 removed; done.
Processing triggers for ca-certificates (20211016ubuntu0.22.04.1) ...
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
rehash: warning: skipping duplicate certificate in A.pem
rehash: warning: skipping duplicate certificate in GlobalSign_Root_CA.pem
2 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Replacing debian:GlobalSign_Root_CA.pem
Replacing debian:GlobalSign_Root_CA.pem
done.
done.

Правда, в моем случае сертификаты уже были добавлены и вывод немного отличается от первоначального. Но вы должны увидеть строчку вида:

2 added, 0 removed; done.

После этого запросы по curl сразу начали работать корректно. Для корректной работы docker пришлось перезапустить службу:

sudo systemctl restart docker

После этого проблем с доступом к Docker репозиторию контейнеров на Gitea не наблюдалось.

Импорт сертификата в доверенные (метод 2)

Есть еще альтернативный способ испорта сертификата в доверенные – полностью через командную строчку.

Скопируем сертификаты в директорию ca-certificates:

cd $HOME/Downloads/crts/
sudo cp GlobalSign_Root_CA.crt AlphaSSL_CA.crt /usr/local/share/ca-certificates

Запустим обновление списка корневых ЦС:

sudo update-ca-certificates

roman@mintwks:~/Downloads/crts$ sudo update-ca-certificates 
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
rehash: warning: skipping duplicate certificate in A.pem
rehash: warning: skipping duplicate certificate in GlobalSign_Root_CA.pem
4 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Replacing debian:GlobalSign_Root_CA.pem
Replacing debian:GlobalSign_Root_CA.pem
Adding debian:AlphaSSL_CA.pem
Replacing debian:GlobalSign_Root_CA.pem
done.
done.
roman@mintwks:~/Downloads/crts$ 

Как видно из скриншота выше – сертификаты были добавлены в список доверенных центров сертификации.

Решение при использовании Minikube

Если вы используете Minikube, то подход будет немного другой, но в целом поход.

Сначала нужно сохранить сертификат корневого ЦС и промежуточного ЦС аналогично пункту выше.

Затем нужно скопировать сертификаты на машину с Minikube в соответствующую директорию:

scp AlphaSSL_CA.crt GlobalSign_Root_CA.crt k8suser@10.10.10.19:/home/minikubeuser/.minikube/certs/

А затем на самой машине запустить Minikube с параметром, который “подтягивает” эти сертификаты:

minikube start --embed-certs