Linux просмотр установленных сертификатов

Работа с КриптоПро на linux сервере

Ссылки

Лицензия

Для установки другой лицензии (под root):

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

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

Добавление корневых сертификатов (под root) из файла cacer.p7b

Необходимо последовательно добавить все сертификаты

Сертификаты

Список установленных сертификатов

certmgr -list , например:

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

Добавить только сертификат (только проверка ЭЦП):

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

Закрытый ключ состоит из шести key-файлов:

Способ с дискетой или флешкой

Скопировать в корень дискеты или флэшки сертификат и приватный ключ (из каталога 999996.000 , 999996 — название (alias) контейнера):

Выполнить команду по копированию ключа с флэшки на диск, ключ попадет в пользовательское хранилище My .

gate@example.com — то, что прописано в поле E сертификата (можно посмотреть командой keytool —printcert -file /path/to/cert/client.cer ):

С жесткого диска

Скопировать приватный ключ в хранилище (контейнер), где — имя пользователя linux:

Поставить «минимальные» права:

Узнать реальное название контейнера:

Ассоциировать сертификат с контейнером, сертификат попадет в пользовательское хранилище My :

Если следующая ошибка, нужно узнать реальное название контейнера (см. выше):

Установить сертификат УЦ из-под пользователя root командой:

Проверка успешности установки закрытого ключа

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

Ввести пароль на контейнер test123 .

Ввести пароль на контейнер. По-умолчанию: 12345678

Удаление сертификата

Проверка сертификата

Просмотр всех атрибутов сертификата

В cryptcp нет необходимых инструментов для получения всех атрибутов сертификата. Поэтому следует использовать openssl , но настроив его.

Получаем SHA 1 хеши:

В цикле извлекаем сертификаты:

Настройка openssl для поддержки ГОСТ:

В файл /etc/ssl/openssl.cnf

Экспорт сертификатов на другую машину

Закрытые ключи к сертификатам находятся тут: /var/opt/cprocsp/keys . Поэтому эти ключи переносятся просто: создаем архив и переносим на нужную машину в тот же каталог.

Экспорт самих сертификатов (если их 14):

Переносим эти файлы на машину и смотрим, какие контейнеры есть:

И как обычно, связываем сертификат и закрытый ключ:

Если закрытый ключ и сертификат не подходят друг к другу, будет выведена ошибка:

Если все успешно:

Если нет закрытого ключа, то просто ставим сертификат:

Подписание документа ЭЦП

Пример создания ЭЦП (по SHA1 Hash):

[ReturnCode: x]	Описание	Возвращаемый код завершения в баше $?
0	успешно	0
0x8010006b	Введен неправильный PIN	107
0x2000012d	Сертификат не найден	45
0x20000065	Не удалось открыть файл	101

Проверка подписи ЭЦП

Для верифицирования сертификатов нужен сертификат удостоверяющего центра и актуальный список отзыва сертификатов, либо настроенный для этого revocation provider.

Корневой сертификат УЦ, список отзыва сертификата является одним из реквизитов самого сертификата.

Контрагенты когда открывают подписи в КриптоАРМ используют revocation provider, он делает проверки отзыва сертификата онлайн. Как реализована проверка в Шарепоинте не знаю. Знаю только что используется библиотека Крипто.Net

Проверка конкретной подписи из локального хранилища по его хешу:

Проверить, взяв сертификат из file1.sig , подпись файла file2.sig . Практически, надо использовать один и тот же файл:

[ReturnCode: x]	Текст	Описание	Возвращаемый код завершения в баше $?
0	Успешно	0
0x80091004	Invalid cryptographic message type	Неправильный формат файла	4
0x80091010	The streamed cryptographic message is not ready to return data	Пустой файл	16

Получение исходного файла

Получение исходного файла (сообщения):

Будет ругаться на сертификат (так как не будет проверки), но подпись удалит. Вариант с проверкой:

Источник

Операционные системы Astra Linux

Оперативные обновления и методические указания

Операционные системы Astra Linux предназначены для применения в составе информационных (автоматизированных) систем в целях обработки и защиты 1) информации любой категории доступа 2) : общедоступной информации, а также информации, доступ к которой ограничен федеральными законами (информации ограниченного доступа).

1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).

Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».

На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.

Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!

Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.

В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.

Очередные обновления (версии) предназначены для:

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

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

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

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

Источник

Openssl, проверка SSL-сертификатов через терминал

При установке SSL-сертификатов возникают различные вопросы. Эта статья поможет найти ответы на большинство из них.

OpenSSL — криптографический пакет с открытым исходным кодом для работы с SSL/TLS. Позволяет создавать ключи RSA, DH, DSA и сертификаты X.509, подписывать их, формировать CSR и CRT. Также имеется возможность шифрования данных и тестирования SSL/TLS соединений.

Рассмотрим на примерах следующие случаи:
1. Генерация CSR и ключа.
2. Создание нового CSR для уже имеющегося ключа.
3. Проверка корректности CSR.
4. Проверка корректности ключа.
5. Проверка данных SSL-сертификата.
6. Декодирование CSR.
7. Декодирование SSL-сертификата.
8. Сравнение соответствия SSL-сертификата и CSR.
9. Сравнение соответствия SSL-сертификата и ключа.
10. Проверка правильности порядка установки CA сертификатов.

Первое что нужно сделать — это зайти по SSH на сервер и установить OpenSSL.

1. Генерация CSR и ключа

Перейдем в директорию, в которой будут хранится файлы CSR и ключа:

Далее выполняем команду генерации CSR и ключа:

server.csr – имя файла CSR;

server.key – имя файла ключа;

имена можно менять по своему усмотрению.

После ввода команды, так же как и через онлайн генератор CSR нужно ввести данные в поля:

Проверяем создались ли файлы:

Файлы создались, все в порядке. Можно заказывать SSL-сертификат.

Подробно о заказе и установке SSL-сертификата можно ознакомиться в статье “Заказ и установка SSL сертификата на хостинг Ukrnames”

Мы получили файлы сертификата (ukrnames_idua_org, ca_1, ca_2, ca_3) и переместим их так же в папку /etc/ssl/certs/

Можем переходить теперь к следующим пунктам статьи.

2. Создание нового CSR для уже имеющегося ключа.

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

Данная команда позволит заново сгенерировать CSR-запрос на основании имеющегося у нас ключа (в данном примере ключ у нас находится в папке /etc/ssl/certs/server.key):

И вновь нужно вводить данные CSR.

Потом можем копировать данные файла server.csr и продлевать SSL-сертификат, копировать ключ уже не нужно, он заново сгенерирован в старый файл ключа /etc/ssl/certs/server.key.

3. Проверка корректности CSR

Выполним команду для проверки корректности содержимого CSR:

Получаем вывод, в котором стоит обратить внимание на поле verify , если стоит статус “OK” , значит с CSR все в порядке.

4. Проверка корректности ключа

Выполним команду для проверки корректности содержимого ключа:

Получаем вывод, в котором стоит обратить внимание на поле RSA key, если стоит статус “ok”, значит с ключом все в порядке.

5. Проверка данных SSL-сертификата

Переименуем для удобства файл сертификата ukrnames_idua_org в server.crt с помощью команды:

Выполним команду для проверки данных SSL-сертификата:

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

6. Декодирование CSR

Иногда после генерации CSR хочется проверить правильность ввода данных. Для этого достаточно выполнить команду:

Получим вывод, в котором стоит обратить внимание на поле “Subject:”, в нем указаны все вводимые нами данные.

7. Декодирование SSL-сертификата

Вывести данные SSL-сертификата можно командой:

Вывод будет эдентичен выводу в пункте 5.

8. Сравнение соответствия SSL-сертификата и ключа

Для того чтобы сравнить SSL-сертификат и ключ, нужно будет вывести хеши данных их файлов и сравнить.

Получим вывод на экран хешей:

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

9. Сравнение соответствия SSL-сертификата и CSR

Для данного примера заменим данные CSR файла /etc/ssl/certs/server.csr на другие:

Выполним команды для вывода хешей файлов /etc/ssl/certs/server.crt и /etc/ssl/certs/server.csr:

Получим вывод на экран:

Как видим, хеши отличаются – это означает, что сертификат не совпадает с CSR.

10. Проверка правильности порядка установки CA сертификатов.

На данном сервере, где выполнялись работы с openssl, установим веб-сервер, подключим домен ukrnames.idua.org и установим для него SSL-сертификат.

Т.к. веб-сервер не имеет доступа к папке /etc/ssl/certs/ , то копируем ключ, сертификат и промежуточные сертификаты в новосозданную папку /var/www/ssl/

В файле конфигурации веб-сервера подключаем файлы SSL-сертификата. Но чтобы все корректно работало, нужно создать файл для промежуточных сертификатов (к примеру ca.pem) и внести в него с определенной последовательностью данные файлов промежуточных сертификатов (ca_1, ca_2, ca_3).

Чтобы понять в какой последовательности нужно добавлять файлы, выполним ряд действий.

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

Теперь получим данные о промежуточных сертификатах ca_1, ca_2, ca_3 (нужно обращать внимание только на поля “Issuer:” и “Subject:”):

Получим вывод на экран:

Сопоставив данные сертификата и промежуточных сертификатов, можно сделать вывод, что после основного сертификата первым промежуточным должен идти сертификат ca_3, т.к. в поле “Subject:” раздел CN файла ca_3 совпадает с полем “Issuer:” разделом CN (CN=COMODO RSA Domain Validation Secure Server CA).

Далее смотрим на поле “Issure:” раздел CN файла ca_3 (CN=COMODO RSA Certification Authority). Ищем в выводах файлов ca_2 и ca_1 совпадение в полях “Subject:” . Совпадение найдено в файле ca_2, данный файл мы будем подключать вторым.

И методом исключения, файл ca_1 будет подключаться самым последним.

Выполняем команды для объединения всех файлов промежуточных сертификатов(ca_1, ca_2, ca_3) в один (ca.pem):

Теперь можем увидеть полную цепочку установленных сертификатов с помощью команды:

Получим вывод на экран правильной цепочки подключения сертификатов:

Источник