Установка сертификатов используя криптопро в linux

Как заставить браузер доверять самоподписанному сертификату

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

  1. Запустить браузер, например, с использованием графического интерфейса: Пуск — Сеть — Веб-браузер Chromium.
  2. В адресную строку ввести «» и нажать клавишу <Enter>.
  3. На открывшейся странице Настроить сертификаты в правом поле открыть вкладку Центры сертификации и нажать на кнопку .
  4. В открывшемся окне импорта выбрать файл и нажать на кнопку .
  5. В открывшемся окне настройки доверия установить флаг Доверять этому сертификату при идентификации сайтов и нажать на кнопку .

После успешного добавления корневого сертификата на странице Настроить сертификаты во вкладке Центры сертификации появятся следующие строки:

org-The Ministry of Digital Development and Communications
	Russian Trusted Root CA

Как ssl-сертификат помогает защитить данные?

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

  • Пара ключей (открытый и закрытый) — для шифрования/расшифровки трафика;
  • Подпись открытого ключа. Гарантирующая, что он подлинный и обслуживает именно тот домен, для которого и был создан.

Обе эти составляющие и представляют собой то, что принято обозначать понятием SSL-сертификат. Подпись является гарантией, поскольку выдаётся авторитетным центрами сертификации. Это доступные всем онлайн-сервисы (достаточно воспользоваться любой поисковой системой), которым можно отправить свой ключ, заполнив соответствующую анкету.

Далее сервис (центр сертификации) обрабатывает данные из анкеты и сам ключ и высылает уже подписанный ключ обратно его владельцу

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

Построение небольшого центра сертификации на основе OpenSSL

Разговор о центре сертификации логично начать с PKI — инфраструктуры открытых ключей. Находим определение в Википедии: «PKI — набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей». Так что к PKI стоит относиться именно как к инфраструктуре, в состав которой входят те или иные компоненты.

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

В качестве сущности может выступать пользователь, устройство или что угодно ещё, что можно ассоциировать с тем или иным ключом (процесс, программа, производитель и т. д.). Вот примеры задач, для которых обычно используется PKI:

  • создание сертификатов для привязки публичного ключа к сущности;
  • безопасное хранение сертификатов в репозитории (англ. repository — хранилище);
  • отзыв сертификата (отметка, что сертификату нельзя доверять).

В систему PKI обычно входят:

  • Центр сертификации (англ. Certificate Authority (CA)), которому будет посвящена основная часть этой статьи. Он непосредственно работает с сертификатом — выписывает, хранит, проверяет подлинность. Центр сертификации не следует путать с удостоверяющим центром. Также отдельно рассматривается «корневой центр сертификации» — сторона, чья честность неоспорима, а открытый ключ широко известен.
  • Регистрационный центр (англ. Registration Authority (RA)). Согласно Википедии, «удостоверяющий центр доверяет регистрационному проверку информации о субъекте». Поэтому часто регистрационный центр полностью или частично объединяют с CA.
  • Сертификат (англ. Certificate) — публичный ключ и идентификаторы сущности, имеющие подпись центра сертификации. В качестве идентификатора может выступать электронная почта пользователя. Если ЦС подписывает набор данных, который состоит из имени пользователя, его публичного ключа и электронной почты, то он как бы гарантирует, что эти данные подлинные. Далее под термином «сертификат» мы будем понимать сертификат стандарта X.509.
  • Certificate Signing Request (CSR). По сути это запрос на подпись сертификата. В запросе обычно указывается сущность, её параметры и публичный ключ.
  • Certificate Revocation List (CRL), он же список отзывов, или отозванных сертификатов. По этому списку ЦС ведёт учёт «плохих» сертификатов. И если такой сертификат используется, то ЦС не подтвердит к нему доверие. Чаще всего причина — утрата ключей сертификата.

Для базового понимания структуры PKI этого списка достаточно. Теперь рассмотрим, как всё это применяется.

Установка вручную

Выше рассмотрены самые удобные способы обновления корневых сертификатов. Но мы можем столкнуться с ситуацией, когда в предоставляемых официальных пакетах не окажется обновленного сертификата. Например, на момент написания данной инструкции у систем на базе Deb не оказалось нового сертификата для Let’s Encrypt, а старый закончил свое действие 30 сентября 2021 года.

vi /usr/share/ca-certificates/letsencryptauthorityx3.pem

——BEGIN CERTIFICATE——MIIFjTCCA3WgAwIBAgIRANOxciY0IzLc9AUoUSrsnGowDQYJKoZIhvcNAQELBQAwTzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2VhcmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTYxMDA2MTU0MzU1WhcNMjExMDA2MTU0MzU1WjBKMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3MgRW5jcnlwdDEjMCEGA1UEAxMaTGV0J3MgRW5jcnlwdCBBdXRob3JpdHkgWDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCc0wzwWuUuR7dyXTeDs2hjMOrXNSYZJeG9vjXxcJIvt7hLQQWrqZ41CFjssSrEaIcLo+N15Obzp2JxunmBYB/XkZqf89B4Z3HIaQ6Vkc/+5pnpYDxIzH7KTXcSJJ1HG1rrueweNwAcnKx7pwXqzkrrvUHlNpi5y/1tPJZo3yMqQpAMhnRnyH+lmrhSYRQTP2XpgofL2/oOVvaGifOFP5eGr7DcGu9rDZUWfcQroGWymQQ2dYBrrErzG5BJeC+ilk8qICUpBMZ0wNAxzY8xOJUWuqgzuEPxsR/DMH+ieTETPS02+OP88jNquTkxxa/EjQ0dZBYzqvqEKbbUC8DYfcOTAgMBAAGjggFnMIIBYzAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEBATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQub3JnMB0GA1UdDgQWBBSoSmpjBH3duubRObemRWXv86jsoTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnJvb3QteDEubGV0c2VuY3J5cHQub3JnMHIGCCsGAQUFBwEBBGYwZDAwBggrBgEFBQcwAYYkaHR0cDovL29jc3Aucm9vdC14MS5sZXRzZW5jcnlwdC5vcmcvMDAGCCsGAQUFBzAChiRodHRwOi8vY2VydC5yb290LXgxLmxldHNlbmNyeXB0Lm9yZy8wHwYDVR0jBBgwFoAUebRZ5nu25eQBc4AIiMgaWPbpm24wDQYJKoZIhvcNAQELBQADggIBABnPdSA0LTqmRf/Q1eaM2jLonG4bQdEnqOJQ8nCqxOeTRrToEKtwT++36gTSlBGxA/5dut82jJQ2jxN8RI8L9QFXrWi4xXnA2EqA10yjHiR6H9cj6MFiOnb5In1eWsRMUM2v3e9tNsCAgBukPHAg1lQh07rvFKm/Bz9BCjaxorALINUfZ9DD64j2igLIxle2DPxW8dI/F2loHMjXZjqG8RkqZUdoxtID5+90FgsGIfkMpqgRS05f4zPbCEHqCXl1eO5HyELTgcVlLXXQDgAWnRzut1hFJeczY1tjQQno6f6s+nMydLN26WuU4s3UYvOuOsUxRlJu7TSRHqDC3lSE5XggVkzdaPkuKGQbGpny+01/47hfXXNB7HntWNZ6N2Vwp7G6OfY+YQrZwIaQmhrIqJZuigsrbe3W+gdn5ykE9+Ky0VgVUsfxo52mwFYs1JKY2PGDuWx8M6DlS6qQkvHaRUo0FMd8TsSlbF0/v965qGFKhSDeQoMpYnwcmQilRh/0ayLThlHLN81gSkJjVrPI0Y8xCVPB4twb1PFUd2fPM3sA1tJ83sZ5v8vgFv2yofKRPB0t6JzUA81mSqM3kxl5e+IZwhYAyO0OTg3/fs8HqGTNKd9BqoUwSRBzp06JMg5brUCGwbCUDI0mxadJ3Bz4WxR6fyNpBK2yAinWEsikxqEt——END CERTIFICATE——

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

vi /etc/ca-certificates.conf

И добавляем в него строку с указанием на созданный файл:

letsencryptauthorityx3.pem…

Но в моем случае был прописан также файл с устаревшим сертификатом — указание на него нужно закомментировать:

#mozilla/DST_Root_CA_X3.crt

После чего обновить сертификаты:

update-ca-certificates —fresh

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

Мы должны увидеть что-то на подобие:

Updating certificates in /etc/ssl/certs…1 added, 0 removed; done.Running hooks in /etc/ca-certificates/update.d…done.

Готово.

Создаю центр сертификации

Теория

Протокол HTTPS это объединение протоколов HTTP + SSL/TLS. А протокол TLS это асинхронное шифрование. То есть создаётся пара ключей. И то, что один ключ может зашифровать, другой может расшифровать и наоборот. В протоколе HTTPS эти ключи не равнозначные:

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

А ещё протокол TLS позволяет создавать цепочки сертификатов. То-есть, если браузер доверяет родительскому сертификату, то он автоматически будет доверять и всем дочерним сертификатам. А чтобы создать дочернюю пару ключей, нужно иметь доступ к родительской паре ключей.

Корневая пара ключей обычно не подтверждает никакой домен. А используется для создания промежуточных сертификатов или сертификатов для доменов (для web-серверов).

Обычно, когда создают ssl-сертификат для домена, то для безопасности отнимают у него право создания дочерних сертификатов.

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

Сервер на котором создают корневые сертификаты, а затем с их помощью выпускают сертификаты для доменов называют – центр сертификации.

Создаю корневой закрытый ключ

Для создания ssl/tls сертификатов можно использовать утилиту openssl, она не требует админских прав.

Создаю корневой закрытый ключ:

$ openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc
   ....................................+++++
   ......................+++++
   Enter PEM pass phrase:
   Verifying - Enter PEM pass phrase:

Разберу эту команду:

  • genpkey – команда для создания закрытого ключа;
  • -algorithm RSA – алгоритм асинхронного шифрования, именно он используется для выделения открытого ключа из этого закрытого;
  • -out rootCA.key – получаемый файл закрытого ключа;
  • -aes-128-cbc – алгоритм симметричного шифрования, которым мы зашифруем файл закрытого ключа с помощью пароля. Пароль нужно будет ввести.

Создаю корневой сертификат

Теперь создаю корневой сертификат (открытый ключ):

$ openssl req -x509 -new -key rootCA.key -sha256 -days 3650 -out rootCA.crt
   Enter pass phrase for rootCA.key:
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) :RU
   State or Province Name (full name) :Moscow
   Locality Name (eg, city) []:Moscow
   Organization Name (eg, company) :Sysadminium
   Organizational Unit Name (eg, section) []:.
   Common Name (e.g. server FQDN or YOUR name) []:Sysadminium

Разберу команду:

req – создаёт сертификаты или запросы на сертификаты;

-x509 – будем создавать сертификат а не запрос;

-new – создаём новый сертификат (нужно будет ввести значения некоторых полей в сертификате);
-key rootCA.key – используемый закрытый ключ, из которого нужно создать открытый;

-sha256 – алгоритм хеширования, чтобы создать подпись ключа;

-days 3650 – выпускаем сертификат на 10 лет (обратите внимание что закрытые ключи не имеют срока жизни а сертификаты имеют);

-out rootCA.crt – получаемый сертификат.

Итак, я создал пару ключей:

$ ls -l root*
-rw-r--r-- 1 alex alex 1306 сен  9 11:26 rootCA.crt
-rw------- 1 alex alex 1874 сен  9 11:19 rootCA.key

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

Создаю файл порядковых номеров для выпуска сертификатов, в нём следует указать два нуля:

$ nano rootCA.srl
00

Дальше нужно передать корневой сертификат на клиентские компьютеры и установить его в доверенные корневые центры сертификации. Я забираю корневой сертификат по протоколу sftp, показывать этот процесс думаю не нужно.

Как в linux использовать сертификат сгенерированный в windows?

День добрый. Пытаюсь установить с помощью PHP в Ubuntu 14.10 подключение к одному SOAP-сервису. Что было сделано:

Фрагмент документации:

Создание и настройка сертификатовДля самостоятельного создания сертификата выполните следующие действия:1. Выполните следующую команду для создания сертификата:makecert.exe -n «CN=name» -ss My -r -m 120 -pe -sky exchange -a sha12. С помощью оснастки «Сертификаты» экспортируйте созданный сертификат в .cer файл и отправьте его на адрес, предоставленной службы технической поддержки.3. С помощью оснастки «Сертификаты» импортируйте файл сертификата в «Доверенные лица» (Trusted people).

Теперь у меня имеется эта пара сертификатов *.cer. Моё затруднение в том, чтобы понять, как этими сертификатами воспользоваться. Пытался создавать стандартный SoapClient указывая в настройках присланный мне сертификат конвертированный в pem-формат, соединение молчком отваливается по таймауту. Попытался отправить запрос с помощью curl без soap-клиента, тогда уже вернулась ошибка о подписи и безопасности. Насколько помню (давно воюю) я взял сертификат сгенерированный на нашей стороне в Windows, извлёк из него открытый и закрытый ключ в pem-формате, указал их в настройках curl с помощью CURLOPT_SSH_PUBLIC_KEYFILE и CURLOPT_SSH_PRIVATE_KEYFILE, указал сертификат присланный техподдержкой сервиса в pem-формате с помощью CURLOPT_SSLCERT, но всё равно ошибка та же.Ранее приходилось работать только с сертификатами от crypto, но там помимо сертификаты присылали ещё шесть файлов ключей и приходилось делать подмену библиотеки, чтобы использовать курл от криптопро, но как я понимаю, здесь не тот случай.Вообще, как я понимаю, для подключения нужно использовать открытый и закрытый ключ той машины, на который генерировался сертификат, он же ведь подтверждает только пару этой машины?Ещё пытался запускать скрипт получив доступ к той машине в windows в которой генерировался сертификат, предварительно добавив его с помощью оснастки в доверенные, но получил те же самые ошибки о подписи и безопасности. «An error occurred when verifying security for the message.»

Направьте меня пожалуйста на путь истинный.

Добавление сертификатов в базу данных NSS

Некоторые приложения используют базу данных NSS, и у вас может быть необходимость добавить доверенные CA в неё.

Последующие изменения повлияют только на приложения, использующие базу данных NSS и учитывающие файл /etc/pki/nssdb.

1. Сначала создайте структуру каталогов для системных файлов базы данных NSS:

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

2. Убедитесь, что файлы базы данных доступны для чтения всем:

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

Если он уже существует, то важно знать пароль для этого набора баз данных (конечно, если он защищён паролем)

3. Теперь, когда доступны файлы базы данных NSS, добавьте сертификат в хранилище следующим образом:

Биты доверия, используемые в приведённом выше примере, помечают сертификат как надёжный для подписи сертификатов, используемых для связи SSL/TLS. Имя (указывается после опции -n), используемое в команде, можно выбрать любое, но убедитесь, что его легко отличить от других сертификатов в магазине.

Аналогичные инструкции можно использовать для включения сертификата только в базу данных NSS конкретного пользователя:

Удаление из файлов базы данных NSS

Чтобы удалить сертификат из любой базы данных NSS, используйте команду certutil следующим образом. В этом примере используется общесистемное расположение базы данных NSS, но его можно легко изменить на пользовательское

Этот сертификат содержит недействительную цифровую подпись : цепочка доверия от Минкомсвязи до пользователя

Прежде чем разбираться в причинах ошибки, следует понять алгоритм построения цепочки доверия сертификатов (ЦДС) — она обязательна для корректной работы ЭЦП на любых информационных ресурсах.

Как строится путь доверия

Первое звено в иерархической цепочке — корневой сертификат ключа проверки ЭЦП ПАК «Минкомсвязь России». Именно этот госорган, согласно ст. 16 ФЗ № 63 «Об электронной подписи», осуществляет аккредитацию удостоверяющих центров, то есть дает им официальное право заниматься выпуском ЭЦП. Полный перечень таких организаций можно уточнить на официальном портале Минкомсвязи.

Следующее звено — КС удостоверяющего центра (промежуточный). Файл выдается в комплекте с ключами и содержит в себе:

  • сведения об УЦ с указанием даты его действия;
  • сервисный интернет-адрес (через который можно связаться с реестром компании).

Эти данные предоставляются в зашифрованном виде и используются криптопровайдером (на ПК пользователя) для проверки подлинности открытого ключа КЭЦП. Теоретически цифровую подпись можно украсть, но применить ее без установленного сертификата УЦ не получится. То есть вся ЦДС построена таким образом, чтобы предотвратить риски использования чужой подписи мошенниками.

СКПЭП — конечное звено в этой цепи. Его выдает удостоверяющий центр вместе с открытым и закрытым ключами. Сертификат предоставляется на бумажном или цифровом носителе и содержит основную информацию о держателе. Он связывает последовательность символов открытого ключа с конкретным лицом. Другими словами, СКПЭП подтверждает тот факт, что открытый ключ ЭП принадлежит определенному человеку.

Головной КС Минкомсвязи действует до 2036 года, а ПС удостоверяющих центров ликвидны в течение 12 месяцев, после чего необходимо скачать (или получить в УЦ) новый и переустановить его на свой ПК. Сертификат КЭЦП тоже действует не более 1 года, по истечении этого срока клиенту требуется получить новый.

Если возникает ошибка «Этот сертификат содержит недействительную цифровую подпись» , причина может быть в повреждении ЦДС от Минкомсвязи России до пользователя. То есть один из элементов в этой цепи искажен или изменен.

Как решить проблему

В первую очередь стоит удостовериться, что КС корректно установлен и действителен. Для этого используется стандартный путь: «Пуск» → «Все программы» → «КриптоПро» → «Сертификаты» → «Доверенные центры сертификации» → «Реестр». В открывшемся списке должен быть документ от ПАК «Минкомсвязь России». Если сертификат отсутствует или он недействителен, его нужно установить, следуя алгоритму:

  1. Открыть загруженный файл на ПК.
  2. Во вкладке «Общие» кликнуть «Установить».
  3. Поставить флажок напротив строчки «Поместить в следующее хранилище».

Выбрать хранилище «Доверенные корневые центры сертификации».

  1. Продолжить установку кнопкой «ОК» и подтвердить согласие в окне «Предупреждение о безопасности».

Файл выдается удостоверяющим центром вместе с другими средствами для формирования ЭЦП. Если он утерян или удален, следует обратиться в УЦ, в котором был получен СКПЭП.

Если КС Минкомсвязи на месте, но в статусе по-прежнему сказано, что он недействителен, удалите его (выбрать файл и нажать «Удалить») и установите заново.

На форуме CryptoPro CSP предлагается еще один вариант решения проблемы. Но работает он не всегда. Если установка документа не помогла, откройте меню «Пуск» и выполните поиск редактора реестра по его названию regedit. В редакторе найдите и вручную удалите следующие ветки:

Не все ветки могут быть в наличии. Удалите те, что есть, предварительно сохранив их резервные копии в отдельный файл. Перезагрузите ПК и проверьте статус СКЭП — он должен стать действительным.

Добавление сертификатов в базу данных nss

Некоторые приложения используют базу данных NSS, и у вас может быть необходимость добавить доверенные CA в неё.

Последующие изменения повлияют только на приложения, использующие базу данных NSS и учитывающие файл /etc/pki/nssdb.

1. Сначала создайте структуру каталогов для системных файлов базы данных NSS:

sudo mkdir -p /etc/pki/nssdb

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

sudo certutil -d sql:/etc/pki/nssdb -N

2. Убедитесь, что файлы базы данных доступны для чтения всем:

sudo chmod go r /etc/pki/nssdb/*

3. Теперь, когда доступны файлы базы данных NSS, добавьте сертификат в хранилище следующим образом:

sudo certutil -d sql:/etc/pki/nssdb -A -i ФАЙЛ-СЕРТИФИКАТА.crt -n "ИМЯ-СЕРТИФИКАТА" -t "C,,"

Например:

sudo certutil -d sql:/etc/pki/nssdb -A -i ./HackWareCA.crt -n "HackWare CA" -t "C,,"

Биты доверия, используемые в приведённом выше примере, помечают сертификат как надёжный для подписи сертификатов, используемых для связи SSL/TLS. Имя (указывается после опции -n), используемое в команде, можно выбрать любое, но убедитесь, что его легко отличить от других сертификатов в магазине.

Для проверки:

certutil -L -d /etc/pki/nssdb

Аналогичные инструкции можно использовать для включения сертификата только в базу данных NSS конкретного пользователя:

certutil -d sql:$HOME/.pki/nssdb -A -i ФАЙЛ-СЕРТИФИКАТА.crt -n "ИМЯ-СЕРТИФИКАТА" -t "C,,"

Удаление из файлов базы данных NSS

Чтобы удалить сертификат из любой базы данных NSS, используйте команду certutil следующим образом. В этом примере используется общесистемное расположение базы данных NSS, но его можно легко изменить на пользовательское ~/.pki/nssdb местоположение.

sudo certutil -d sql:/etc/pki/nssdb -D -n "certificateName"

macOS — Chrome и Safari

1. Дважды кликните на корневом сертификате ().

2. Выберите нужную связку ключей (, если вы хотите, чтобы сертификат считался доверенным только в вашем аккаунте, или , если сертификат должен считаться доверенным во всей системе).

3. Добавьте сертификат.

4. Откройте «Keychain Access» (если еще не открыт).

5. Выделите keychain, который выбрали раньше.

6. Вы должны увидеть сертификат MY-CA (это будет имя, которое вы, как CN, дали вашему источнику сертификата).

7. Дважды кликните по сертификату.

8. Разверните «Доверять» и выберите опцию «Доверять всегда» в пункте «При использовании этого сертификата».

9. Закройте окно сертификата и введите свой пользовательский пароль (если требуется).

Можно ли без корневого сертификата установить ЭП

Если у субъекта нет корневого сертификата, установить ЭЦП в систему он сможет. Однако полноценно использовать её не получится, так как для подписания этой подписью документа обязательно потребуется КС.

Во-первых, подпись будет считаться недействительной, а во-вторых, программа криптошифрования при подписании будет постоянно выводить ошибку и подписать документ не получится.

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

Установка сертификатов используя криптопро в linux

Сен042020

Описание процесса установки приведено на примере дистрибутива семейства Debian (x64).Названия файлов и директорий могут варьироваться от системы к системе.

При установке личных сертификатов не нужны права суперпользователя, и наоборот, при установке сертификатов УЦ (корневых и промежуточных) могут потребоваться такие права.

Подключите USB носитель с ключевыми контейнерами и проверьте результат команды:

/opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -fqcn -verifyc

Можно сразу установить личные сертификатов из всех доступных контейнеров одной командой: /opt/cprocsp/bin/amd64/csptestf -absorb -certsПроизойдет установка сертификатов, находящихся во всех доступных в момент запуска команды контейнерах (съемных флэш-носителях, жесткого диска и т. д.) в хранилище uMy.

криптопро эцп browser plug-in астра, альт, роса линукс

/Downloads tar -xf linux-amd64_deb.tgz cd linux-amd64_deb sudo ./install.sh # GUI элементы для работы с сертификатами sudo dpkg -i cprocsp-rdr-gui-gtk-64_4.0.0-4_amd64.deb # Поддержка алгоритмов класса 2 sudo dpkg -i lsb-cprocsp-kc2-64_4.0.0-4_amd64.deb

4. готово p.s. удалить можно выполнив код в этой же директории: Код:

sudo ./uninstall.sh sudo rm -rf /opt/cprocsp sudo rm -rf /etc/opt/cprocsp sudo rm -rf /var/opt/cprocsp sudo rm /opt/google/chrome/extensions/iifchhfnnmpdbibifmljnfjhpififfog.json sudo rm /etc/chromium/native-messaging-hosts/ru.cryptopro.nmcades.json sudo rm /etc/opt/chrome/native-messaging-hosts/ru.cryptopro.nmcades.json sudo rm /usr/lib/firefox-addons/plugins/libnpcades.so sudo rm /usr/share/chromium-browser/extensions/iifchhfnnmpdbibifmljnfjhpififfog.json sudo rm /usr/share/chromium/extensions/iifchhfnnmpdbibifmljnfjhpififfog.json

Установка тестовых сертификатов

1. Качаем корневой сертификат

2. Устанавливаем его Код: /opt/cprocsp/bin/amd64/certmgr -inst -store uroot -file certnew.cer

Смотрим доступные контейнеры Код: /opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -verifycontext -fqcn

Устанавливаем сертификат: Код: /opt/cprocsp/bin/amd64/certmgr -inst -store umy -file

/Downloads/test\ 8.12.2016\ KC1\ CSP.pem -cont ‘\\.\HDIMAGE\70275af7-e10b-bed3-b1b3-88641f09f3a5’

1. Качаем плагин версии 2.0

2. Распаковывем и устанавливаем Код: cd

/Downloads mkdir cades_linux_amd64 tar -xf cades_linux_amd64.tar.gz -C cades_linux_amd64 cd cades_linux_amd64 sudo alien -kci cprocsp-pki-2.0.0-amd64-cades.rpm sudo alien -kci cprocsp-pki-2.0.0-amd64-plugin.rpm # С первого раза не все файлы копируются, например не копируется /opt/cprocsp/lib/amd64/libnpcades.so sudo alien -kci cprocsp-pki-2.0.0-amd64-plugin.rpm

3. Копируем файл libnpcades.so в папку с плагинами Код: sudo cp /opt/cprocsp/lib/amd64/libnpcades.so /usr/lib/firefox-addons/plugins/libnpcades.so

4. Перезапускаем/запускаем firefox

5. Открываем about:addons

6. Выбираем вкладку Plugins.

7. У плагина CryptoPro CAdES plugin ставим значение Always Activate

8. Проверяем работоспособность на demo странице, либо на странице генерации тестового сертификата

Инструкция по установке КриптоПро Browser Plug-In 2.0 в Google Chrome 54.0.2840.100 (64-bit)

Выполняем, если не выполнены пункты 1 и 2 из предыдущего раздела.

Устанавливаем плагин из магазина: CryptoPro Extension for CAdES Browser.

Если на демо странице пишет что-то вроде: Код: Ошибка при открытии хранилища: The system cannot find the file specified. (0x80070002)

Значит у вас не установлено ни одного сертификата.

Список установленных компонентов: Код: dpkg -l | grep csp

Вывод установленных сертификатов: Код: /opt/cprocsp/bin/amd64/certmgr -list

Установка корневого сертификата УЦ: Код: sudo /opt/cprocsp/bin/amd64/certmgr -inst -store uroot -file путь_к_файлу_с_сертификатом

Перечисление доступных контейнеров: Код: /opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -verifycontext -fqcn

Установка личного сертификата: Код: /opt/cprocsp/bin/amd64/certmgr -inst -store umy -file путь_к_файлу_с_сертификатом -cont ‘имя_контейнера’

Если в контейнере присутствует сертификат, то для его установки личного сертификата можно использовать команды: Код: /opt/cprocsp/bin/amd64/certmgr -inst -cont ‘имя_контейнера’

Установить все сертификаты в хранилище Личное uMy из доступных контейнеров: Код: /opt/cprocsp/bin/amd64/csptestf -absorb -certs

Добавление хранилища на жёстком диске: Код: sudo /opt/cprocsp/sbin/amd64/cpconfig -hardware reader -add HDIMAGE store

Генерация пары закрытого/открытого ключа в хранилище: Код: /opt/cprocsp/bin/amd64/csptest -keyset -newkeyset -cont ‘\\.\HDIMAGE\main’ -provtype 75 -provider «Crypto-Pro GOST R 34.10-2001 KC1 CSP»

Загрузка подписанного сертификата к паре закрытого/открытого ключа: Код: /opt/cprocsp/bin/amd64/certmgr -inst -file main.cer -store umy -cont ‘\\.\HDIMAGE\main’

Если при попытке сгенерировать сертификат по алгоритму *KC2*, например с Crypto-Pro GOST R 34.10-2001 KC2 CSP возникает ошибка:

Произошла ошибка при создании запроса на сертификат. Проверьте, что выбранный поставщик служб шифрования поддерживает заданные вами параметры и введены правильные данные. Предполагаемая причина: (нет вариантов) Ошибка: 0x00000000 — (нет данных)

то у вас нет аппаратного датчика случайных чисел, а работает только биологический датчик случайных чисел (который может быть использован в КриптоПро КС1).

Источник

Шаг 5 — Тестирование шифрования

Теперь мы готовы протестировать наш сервер SSL.

Откройте браузер и введите и доменное имя или IP-адрес вашего сервера в адресную панель:

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

Такое предупреждение нормально, и его следует ожидать. Сертификат нам нужен только для шифрования, а не для подтверждения подлинности нашего хоста третьей стороной. Нажмите «Дополнительно», а затем нажмите на указанную ссылку, чтобы перейти к своему хосту:

Теперь должен открыться ваш сайт. Если вы посмотрите в адресную строку браузера, вы увидите символ замка со знаком «x». В данном случае это означает, что сертификат не удается проверить. Ваше соединение все равно шифруется.

Если вы настроили Apache для перенаправления HTTP на HTTPS, вы можете проверить правильность перенаправления функций:

Если при этом появляется такой же значок, перенаправление работает правильно.

Возможные проблемы и как их решить

Windows не может проверить подлинность сертификата

Чаще всего такая ошибка возникает в старых версиях ОС Windows. К примеру, если используется Windows 7, необходимо обновить ее до пакета исправления SP1 и импортировать сертификата еще раз.

Также сами разработчики криптографического комплекса «Крипто Про» рекомендуют применять 64-битные системы.

Такое требование актуально для системы Windows 7 и последующих. При этом Windows XP версии SP3 выходила только в 32-битной версии, но в ней подобной проблемы никогда не возникает.

Поскольку Windows XP и Windows Vista уже серьезно устарели и поддержка этих операционных систем уже не производится, крайне рекомендуется обновить их хотя бы до Windows 7.

Ошибка с правами

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

Тогда требуется войти на компьютер под учетной записью администратора. Либо осуществить импорт используя опцию «Запуск от имени администратора» при щелчке мышью.

Ошибка импорта

Система Windows может сообщить об ошибке при попытке добавить сертификат в хранилище.

Она чаще всего происходит по одной из следующих причин:

  • Установлена старая версия криптопровайдера — в настоящее время сертификаты выпускаются согласно ГОСТ 2012 года, для которого требуется минимально версия Крипто Про 4.0
  • Копия открытого ключа данного сертификата уже была установлена в систему (проверить это можно просмотреть перечень установленных ЭЦП через панель управления Крипто Про;
  • Windows не может получить доступ к реестру, либо работа с ним заканчивается ошибкой — желательно произвести проверку и восстановление реестра средствами Windows, либо использовать сторонние программы как, например, C&CLeaner.
  • Время действия КС удостоверяющего центра, импорт которого пытается выполнить пользователь, истекло. Необходимо получить новый сертификат с действующим периодом.
  • Поврежден сам файл сертификата УЦ. Необходимо получить новую копию и осуществить импорт снова.

Не найден локальный сертификат удостоверяющего центра

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

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

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

Не установлен корневой сертификат

Если возникает проблема с установкой, в первую очередь необходимо убедиться, что на компьютере установлена лицензионная ОС Windows.

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

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

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

Если необходимо использовать оба (например, клиентское ПО использует разный набор криптопровайдеров), то тогда необходимо их обновить до самой актуальной версии, поскольку разработчики оперативно исправляют появляющиеся ошибки.

Понравилась статья? Поделиться с друзьями:
Быть в курсе нового
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: