СБИС.СписокСертификатовДляАутентификации | СБИС Помощь

Что происходит на практике

1. Client Hello – клиент начинает общение с сервером отсылая информацию о предпочитаемой версии протокола TLS, набора поддерживаемых шифров (Cipher Spec), и случайного простого числа (client random), необходимого в дальнейшем для генерации общего ключа симметричного шифрования.

   Что такое Cipher Spec? В процессе установки соединения, клиент и сервер должны договориться о: какой алгоритм использовать для обмена ключами (например, RSA – Риверт-Шамир-Адлеман, DH – Диффи-Хеллмана, ECDH – Диффи-Хеллмана на эллиптических кривых, и др.), какой алгоритм использовать для шифрования данных (AES – Advanced Encryption Standard, 3DES – Tripple Data Encryption Algorithm, и др.), какую криптографическую хэш-функцию использовать для генерации Message Authentication Code (SHA-256, SHA-384, SHA-512 – Secure Hash Algorithm с соответствующей длиной строки в битах с хэшем, и др.).

   Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.

2. Server Hello – сервер отвечает выбранной версией протокола и выбранным из предложенного набора шифром, которые будут непосредственно использоваться, своим случайным простым числом (server random) и идентификатором сессии.

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

3. Certificate – сервер отправляет свой сертификат, а клиент производит проверку подписи удостоверяющего центра, проверку доверия к удостоверяющему центру, проверку указанного домена сайта с фактическим, срока действия, проверяет не был ли сертификат отозван.

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

   Как работает ЭЦП? При создании ЭЦП хэш данных, которые подписываются, шифруется закрытым ключом, в отличие от обычного ассиметричного шифрования, где зашифровка выполняется открытым ключом. Таким образом, если вам удалось расшифровать открытым ключом хэш, и он оказался идентичен хэшу из данных, – вы можете быть уверены что: подпись была сделана именно владельцем приватного ключа, открытый ключ которого вы используете; данные, которые были подписаны, не изменились с момента подписания.

   Но как удостовериться, что открытый ключ принадлежит не злоумышленнику? Существуют корневые удостоверяющие центры (Root Certificate Authority или просто CA – Certificate Authority), которым доверяют все участники обмена информацией. Если в цепочке подписания сертификата сервера есть подпись корневого CA (мы можем проверить ее с помощью открытого ключа CA), то мы можем ему доверять. При этом сертификаты (открытые ключи) корневых CA распространяются посредством включения их в операционную систему или браузер поставщиками. Также стоит отметить, что сертификат может быть подписан сертификатом, который подписан в свою очередь другим сертификатом – это цепочка подписания.

   Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).

4. Server Key Exchange – этот этап происходит не всегда, только если необходимы дополнительные данные для создания симметричного ключа при выбранном алгоритме. Например, при обмене ключами RSA этот шаг пропускается и для обмена общим ключ передается от клиента серверу зашифрованным открытым ключом сервера из его сертификата. Однако в этой статье рассмотрим более надежный алгоритм Диффи-Хеллмана. Сервер отправляет числа p (большое простое число) и g (может быть маленьким), а также рассчитанное число Y_s=g^{случайно выбранное сервером число}mod p, где mod – это операция нахождения остатка от деления. В свою очередь клиент также рассчитывает Y_c=g^{случайно выбранное клиентом число}mod p. После этого сервер считает Y_c^{случайно выбранное сервером число}mod p, а клиент Y_s^{случайно выбранное клиентом число}mod p, в результате чего у клиента и сервера получается одинаковое число. Разберем на примере:

5. Server Hello Done – сервер сообщает, что начальный этап установки соединения завершен

6. Client Key Exchange – как было уже сказано выше, когда сервер передал числа p, g, Y_s в Server Key Echange, клиент передает свое число Y_c в Client Key Exchange. Вычисленное в конце общее одинаковое число используется для создания pre-master secret – предварительного разделяемого ключа. На основании client random, server random и pre-master secret псевдослучайная функция выдает симметричный ключ и ключ вычисления MAC. Таким образом клиент и сервер имеют все необходимое для начала обмена полезной информацией.

7. Change Cipher Spec – клиент говорит серверу, что он готов перейти на защищенное соединение.

8. Finished – клиент зашифровывает симметричным ключом первое сообщение с MAC.

9. Change Cipher Spec – сервер проверяет сообщение Finished от клиента и отправляет в ответ свою готовность к защищенному соединению.

10. Finished – аналогично клиенту, сервер отправляет тестовое зашифрованное сообщение

11. После этого соединение считается установленным, и происходит передача полезной информации

12. close_notify – служебное сообщение, которое одна сторона отправляет другой, как уведомление о том, что считаетсоединение разорванным и не будет принимать больше сообщения. Другая сторона в ответ обязана послать аналогичное сообщение close_notify.

30 ответов

Лучший ответ

C:Program FilesJavajdk1.7.0_71bin>

keytool -list -v -keystore c:usersyour_user_name.androiddebug.keystore -alias androiddebugkey -storepass android -keypass android

keytool -list -v -keystore c:usersJames.androiddebug.keystore -alias androiddebugkey -storepass android -keypass android

keytool -list -v -keystore "%USERPROFILE%.androiddebug.keystore" -alias androiddebugkey -storepass android -keypass android

HOME/.android/debug.keystore

apply plugin: 'com.android.application'

    android {
        ................
        signingConfigs {
            debug {
                storeFile file("../app/debug.keystore")
                storePassword "android"
                keyAlias "androiddebugkey"
                keyPassword "android"
            }
            release {
                storeFile file("../app/debug.keystore")
                storePassword "android"
                keyAlias "androiddebugkey"
                keyPassword "android"
            }
        }
        ........
    }

keytool -exportcert -alias androiddebugkey -keystore %USER_PROFILE%"/.android/debug.keystore -list -v

private void hash() {


            PackageInfo info;
            try {

                info = getPackageManager().getPackageInfo(
                        this.getPackageName(), PackageManager.GET_SIGNATURES);

                for (android.content.pm.Signature signature : info.signatures) {
                    MessageDigest md;
                    md = MessageDigest.getInstance("SHA");
                    md.update(signature.toByteArray());
                    Log.e("sagar sha key", md.toString());
                    String something = new String(Base64.encode(md.digest(), 0));
                    Log.e("sagar Hash key", something);
                    System.out.println("Hash key"   something);
                }

            } catch (PackageManager.NameNotFoundException e1) {
                Log.e("name not found", e1.toString());
            } catch (NoSuchAlgorithmException e) {
                Log.e("no such an algorithm", e.toString());
            } catch (Exception e) {
                Log.e("exception", e.toString());
            }
        }

        private void getCertificateSHA1Fingerprint() {
            PackageManager pm = this.getPackageManager();
            String packageName = this.getPackageName();
            int flags = PackageManager.GET_SIGNATURES;
            PackageInfo packageInfo = null;
            try {
                packageInfo = pm.getPackageInfo(packageName, flags);
            } catch (PackageManager.NameNotFoundException e) {
                e.printStackTrace();
            }
            Signature[] signatures = packageInfo.signatures;
            byte[] cert = signatures[0].toByteArray();
            InputStream input = new ByteArrayInputStream(cert);
            CertificateFactory cf = null;
            try {
                cf = CertificateFactory.getInstance("X509");
            } catch (CertificateException e) {
                e.printStackTrace();
            }
            X509Certificate c = null;
            try {
                c = (X509Certificate) cf.generateCertificate(input);
            } catch (CertificateException e) {
                e.printStackTrace();
            }
            String hexString = "";
            try {
                MessageDigest md = MessageDigest.getInstance("SHA1");
                byte[] publicKey = md.digest(c.getEncoded());
                Log.e("sagar SHA",byte2HexFormatted(publicKey));
            } catch (NoSuchAlgorithmException e1) {
                e1.printStackTrace();
            } catch (CertificateEncodingException e) {
                e.printStackTrace();
            }
        }

        public static String byte2HexFormatted(byte[] arr) {
            StringBuilder str = new StringBuilder(arr.length * 2);
            for (int i = 0; i < arr.length; i  ) {
                String h = Integer.toHexString(arr[i]);
                int l = h.length();
                if (l == 1) h = "0"   h;
                if (l > 2) h = h.substring(l - 2, l);
                str.append(h.toUpperCase());
                if (i < (arr.length - 1)) str.append(':');
            }
            return str.toString();
        }

Аутентификация клиента (двусторонний TLS)

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

client-auth

, сообщив серверу о том, что ему нужно проверять клиентов.

Приведём файл сервера application.yml к такому виду:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:identity.jks
    key-password: secret
    key-store-password: secret
    client-auth: need

Если после этого запустить клиент, то он выдаст следующее сообщение об ошибке:

javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

Это указывает на то, что клиент не обладает подходящим сертификатом. Точнее — у клиента пока вообще нет сертификата. Поэтому создадим сертификат следующей командой:

keytool -v -genkeypair -dname "CN=Suleyman,OU=Altindag,O=Altindag,C=NL" -keystore client/src/test/resources/identity.jks -storepass secret -keypass secret -keyalg RSA -keysize 2048 -alias client -validity 3650 -deststoretype pkcs12 -ext KeyUsage=digitalSignature,dataEncipherment,keyEncipherment,keyAgreement -ext ExtendedKeyUsage=serverAuth,clientAuth

Нам ещё нужно создать TrustStore для сервера. Но, прежде чем создавать это хранилище, нужно иметь сертификат клиента. Экспортировать его можно так:

keytool -v -exportcert -file client/src/test/resources/client.cer -alias client -keystore client/src/test/resources/identity.jks -storepass secret -rfc

Теперь создадим TrustStore сервера, в котором будет сертификат клиента:

keytool -v -importcert -file client/src/test/resources/client.cer -alias client -keystore shared-server-resources/src/main/resources/truststore.jks -storepass secret -noprompt

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

Приведём файл application.yml клиента к такому виду:

client:
  ssl:
    one-way-authentication-enabled: false
    two-way-authentication-enabled: true
    key-store: identity.jks
    key-password: secret
    key-store-password: secret
    trust-store: truststore.jks
    trust-store-password: secret

Сервер тоже не знает о только что созданном для него TrustStore. Приведём его файл

application.yml

к такому виду:

server:
  port: 8443
  ssl:
    enabled: true
    key-store: classpath:identity.jks
    key-password: secret
    key-store-password: secret
    trust-store: classpath:truststore.jks
    trust-store-password: secret
    client-auth: need

Если снова запустить клиент — можно будет убедиться в том, что тест завершается успешно, и что клиент получает данные от сервера в защищённом виде.

Примите поздравления! Только что вы настроили двусторонний TLS!

Во-вторых, подпишите свою отладочную сборку. подпишите свою отладочную сборку.

When running or debugging your project from the IDE, Android Studio 
automatically signs your app with a debug certificate generated by the 
Android SDK tools. The first time you run or debug your project in 
Android Studio, the IDE automatically creates the debug keystore and 
certificate in $HOME/.android/debug.keystore, and sets the keystore and key passwords.

При запуске из IDE илиПри отладке проекта, Android Studio будет использоватьСертификат отладки, созданный инструментом Android SDKавтоматический Для примененияподпись. При первом запуске или отладке проекта в Android Studio среда IDE будетавтоматический Создайте хранилище ключей отладки и сертификат в $ HOME / .Android / debug.keystore и установите хранилище ключей и пароль ключа.

Because the debug certificate is created by the build tools and is 
insecure by design, most app stores (including the Google Play Store)do 
not accept apps signed with a debug certificate for publishing.

из-заАкт ввода в эксплуатациюСоздается инструментом сборки, иНе безопасно по дизайну,следовательноБольшинство магазинов приложений(Включая Google Play Store)Приложения, подписанные сертификатом отладки, к публикации не принимаются.。

Android Studio automatically stores your debug signing information in a 
signing configuration so you do not have to enter it every time you 
debug. A signing configuration is an object consisting of all of the 
necessary information to sign your app, including the keystore location, 
keystore password, key name, and key password. You cannot directly edit 
the debug signing configuration, but you can configure how you sign your 
release build.

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

В-пятых, настройте процесс сборки для автоматической подписи приложения. настройте процесс сборки для автоматической подписи приложения.

Configure the build process to automatically sign your app
In Android Studio, you can configure your project to sign the release 
version of your app automatically during the build process by creating a 
signing configuration and assigning it to your release build type. A 
signing configuration consists of a keystore location, keystore 
password, key alias, and key password. To create a signing configuration 
and assign it to your release build type using Android Studio, complete 
the following steps:

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

1. In the Project window, right click on your app and click Open Module
   Settings.
   В окне «Проект» щелкните приложение правой кнопкой мыши и выберите «Открыть настройки модуля».

2. On the Project Structure window, under Modules in the left panel,
   click the module you would like to sign.
   В окне структуры проекта на левой панели модуля щелкните модуль, который нужно подписать.

3. Click the Signing tab, then click Add .
   Откройте вкладку «Подписание» и нажмите «Добавить ».

4. Select your keystore file, enter a name for this signing configuration (as you may create more than one), and enter the required information.
   Выберите файл хранилища ключей, введите имя этой конфигурации подписи (вы можете создать несколько), а затем введите необходимую информацию.
   
   Figure 7. The window for creating a new signing configuration.
   На рисунке выше показано окно для создания новой конфигурации подписи.

5. Щелкните вкладку “Типы сборки”. Откройте вкладку “Типы сборки”.

6. Щелкните сборку выпуска. Щелкните “выпуск”.

7. Under Signing Config, select the signing configuration you just created.
   В разделе «Конфигурация подписи» выберите только что созданную конфигурацию подписи.
   
   Figure 8. Select a signing configuration in Android Studio.
   На рисунке выше показано, как выбрать конфигурацию подписи в Android Studio.

8. Click OK.
   Нажмите “ОК”.

Now every time you build your release build type by selecting an option 
under Build > Build Bundle(s)/APK(s) in Android Studio, the IDE will 
sign your app automatically, using the signing configuration you 
specified. You can find your signed APK or app bundle in the 
build/outputs/ directory inside the project directory for the module you 
are building.

Теперь каждый раз, когда вы выбираете вариант создания версии выпуска в разделе «Сборка»> «Сборка пакетов / APK» в Android Studio, среда IDE автоматически выполняет проверку вашего приложения с использованием указанной вами конфигурации подписи. подпись. Вы можетеbuild/outputs/Найдите подписанный APK или пакет приложения в каталоге в каталоге проекта модуля, который нужно построить.



Отладочная версия apk построена таким образом. Вы также можете выполнить упаковку через задачу gradle, вы можете выполнить команду gradle самостоятельно, например, Gradle Assembly, или вы можете найти задачу под модулем и щелкнуть, чтобы выполнить, как показано ниже:

When you create a signing configuration, your signing information is 
included in plain text in your Gradle build files. If you are working in 
a team or sharing your code publicly, you should keep your signing 
information secure by removing it from the build files and storing it 
separately.

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

Выпускаем собственные сертификаты

Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем “password” длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:

openssl genrsa -aes256 -passout pass:password -out CA-private-key.key 4096

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

Далее создадим новый запрос на подпись сертификата CA-certificate-signing-request.csr, передавая информацию о субъекте “CN=Certificate authority” (если не указывать ключ -subj вас попросят указать: Сountry (C), Locality (L), Organisation (O), Organisation Unit (OU), Common Name (CN), Email, Challenge password – все поля, кроме CN опциональны), приватный ключ и пароль от него:

openssl req -new -key CA-private-key.key -passin pass:password -subj "/CN=Certificate authority/" -out CA-certificate-signing-request.csr t $3

Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.

openssl x509 -req -in CA-certificate-signing-request.csr -signkey CA-private-key.key -passin pass:password -days 1 -out CA-self-signed-certificate.pempemE

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

openssl genrsa -aes256 -passout pass:password -out Server-private-key.key 4096
openssl req -new -key Server-private-key.key -passin pass:password -subj "/CN=localhost/" -out Server-certificate-signing-request.csrt $3

openssl genrsa -aes256 -passout pass:password -out Client-private-key.key 4096
openssl req -new -key Client-private-key.key -passin pass:password -subj "/CN=Client/" -out Client-certificate-signing-request.csr

Подпишем запросы нашим сертификатом CA. Ключ CAcreateserial отвечает за создание файла (в данном случае CA-self-signed-certificate.srl) , в котором будет храниться серийный номер для следующего подписываемого этим сертификатом запроса. Серийный номер для текущего же сертификата сгенерируется случайно.

openssl x509 -req -in Server-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -CAcreateserial -days 1 -out Server-certificate.pemt $4
openssl x509 -req -in Client-certificate-signing-request.csr -CA CA-self-signed-certificate.pem -CAkey CA-private-key.key -passin pass:password -days 1 -out Client-certificate.pem

После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем “password”:

openssl pkcs12 -export -in Server-certificate.pem -inkey Server-private-key.key -passin pass:password -passout pass:password -out Server-keystore.p12      

Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:

keytool -import -file CA-self-signed-certificate.pem -keystore Server-truststore.p12 -storetype PKCS12 -storepass password -noprompt    

Для удобства, все описанные выше действия упакованы в bash script.

Как добавить корневой сертификат в доверенные в linux на уровне системы

Сертификат с расширением .crt можно открыть двойным кликом и просмотреть его содержимое:

Если вы работаете в системе от обычного пользователя (не root), то кнопка «Импортировать» будет недоступна.

Чтобы разблокировать кнопку «Импортировать», выполните следующую команду:

sudo gcr-viewer /ПУТЬ/ДО/СЕРТИФИКАТА.crt

Например:

sudo gcr-viewer ./HackWareCA.crt

Данный способ может не сработать, поэтому рассмотрим, как добавить доверенные корневые центры сертификации в командной строке.

Суть метода очень проста:

1. Добавить свой корневой CA сертификат в папку, предназначенную для таких сертификатов.
2. Запустить программу для обновления общесистемного списка сертификатов.

Пути и команды в разных дистрибутивах Linux чуть различаются.

Просмотреть Subject всех корневых CA сертификатов можно уже знакомой командой:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt

Для демонстрации я добавлю сертификат с Common Name, включающим «HackWare», тогда для проверки, имеется ли сертификат с таким именем среди корневых CA, я могу использовать команду:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare

Для добавления своего корневого CA в доверенные в Debian, Kali Linux, Linux Mint, Ubuntu и их производных:

1. Проверьте, существует ли директория /usr/local/share/ca-certificates:

ls -l /usr/local/share/ca-certificates

Если её ещё нет, то создайте:

sudo mkdir /usr/local/share/ca-certificates

Сертификат должен быть в формате PEM (обычно так и есть) и иметь расширение .crt — если расширение вашего сертификата .pem, то достаточно просто поменять на .crt.

2. Скопируйте ваш сертификат командой вида:

sudo cp СЕРТИФИКАТ.crt /usr/local/share/ca-certificates/

Например:

sudo cp ./HackWareCA.crt /usr/local/share/ca-certificates/

3. Запустите следующую команду для обновления общесистемного списка:

sudo update-ca-certificates

Пример вывода:

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

Adding debian:HackWareCA.pem
done.
done.

Проверим наличие нашего CA сертификата среди доверенных:

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare

Сертификат успешно найден:

Чтобы его удалить:

sudo rm /usr/local/share/ca-certificates/СЕРТИФИКАТ.crt
sudo update-ca-certificates

Для добавления своего корневого CA в доверенные в Arch Linux, BlackArch и их производных:

1. Выполните команду вида:

sudo cp ./СЕРТИФИКАТ.crt /etc/ca-certificates/trust-source/anchors/

Например:

sudo cp ./HackWareCA.crt /etc/ca-certificates/trust-source/anchors/

2. Обновите общесистемный список доверенных CA:

sudo update-ca-trust

Чтобы удалить этот сертификат:

sudo rm /etc/ca-certificates/trust-source/anchors/СЕРТИФИКАТ.crt
sudo update-ca-trust

Добавление сертификатов в базу данных 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"

Как пользоваться openssl (команды openssl)

Команды OpenSSL не столько сложные, сколько запутанные.

Во-первых, их много (48 основных команд, 28 digest команд, 84 cipher команды, а также алгоритмы и методы), некоторые из них выполняют более чем одну функцию, некоторые имеют пересекающиеся функции и не всегда непонятно, какую команду выбрать.

Синтаксис использования команд OpenSSL:

openssl КОМАНДА ОПЦИИ

Ещё один пример как команды OpenSSL могут сбить с толку: у команды x509 есть опция -req, а у команды req есть опция -x509.

Если вы хотите получить справку по командам OpenSSL, то вам нужно знать, что это делается так:

man openssl-КОМАНДА
# ИЛИ
man КОМАНДА

Например:

man openssl-req
man openssl-x509
man openssl-genpkey
man openssl-enc
man openssl-rsa
# ИЛИ
man req
man x509
man genpkey
man enc
man rsa

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

Команды openssl могут быть громоздкими за счёт того, что через одну из опций команды передаются опции сертификата.

На самом деле, для типичных задач используется всего несколько команд и несколько опций. Поэтому если понимать суть, то всё довольно просто.

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

• genpkey (заменяет genrsa, gendh и gendsa) — генерирует приватные ключи
• req — утилита для создания запросов на подпись сертификата и для создания самоподписанных сертификатов PKCS#10
• x509 — утилита для подписи сертификатов и для показа свойств сертификатов
• rsa — утилита для работы с ключами RSA, например, для конвертации ключей в различные форматы
• enc — различные действий с симметричными шифрами
• pkcs12 — создаёт и парсит файлы PKCS#12
• crl2pkcs7 — программа для конвертирования CRL в PKCS#7
• pkcs7 — выполняет операции с файлами PKCS#7 в DER или PEM формате
• verify — программа для проверки цепей сертификатов
• s_client — команда реализует клиент SSL/TLS, который подключается к удалённому хосту с использованием SSL/TLS. Это очень полезный инструмент диагностики для серверов SSL
• ca — является минимальным CA-приложением. Она может использоваться для подписи запросов на сертификаты в различных формах и генерировать списки отзыва сертификатов. Она также поддерживает текстовую базу данных выданных сертификатов и их статус
• rand — эта команда генерирует указанное число случайных байтов, используя криптографически безопасный генератор псевдослучайных чисел (CSPRNG)
• rsautl — команда может быть использована для подписи, проверки, шифрования и дешифрования данных с использованием алгоритма RSA
• smime — команда обрабатывает S/MIME почту. Она может шифровать, расшифровывать, подписывать и проверять сообщения S/MIME

Чтобы увидеть полный список команд выполните:

openssl list -commands

Пример вывода:

asn1parse         ca                ciphers           cms               
crl               crl2pkcs7         dgst              dhparam           
dsa               dsaparam          ec                ecparam           
enc               engine            errstr            gendsa            
genpkey           genrsa            help              list              
nseq              ocsp              passwd            pkcs12            
pkcs7             pkcs8             pkey              pkeyparam         
pkeyutl           prime             rand              rehash            
req               rsa               rsautl            s_client          
s_server          s_time            sess_id           smime             
speed             spkac             srp               storeutl          
ts                verify            version           x509

Пример использования сертификата и отпечатка

{"jsonrpc":"2.0","method":"СБИС.СписокСертификатовДляАутентификации","params":{"Параметр":{"Сертификат":[{"ДвоичныеДанные":"MIIGpTCCBlSgAwIBAgIKHOiy3AAAAABNKjAIBgYqhQMCAgMwGTEXMBUGA1UEAxMOVEVTVC1URU5TT1ItQ0EwHhcNMTYwNzEzMDg1NjAwWhcNMTcxMDEzMDkwNjAwWjCCAcoxGDAWBgUqhQNkARINMTAyNzgwMTUzMDQyNjEWMBQGBSqFA2QDEgsxNzg4NTYyNTAzMjEaMBgGCCqFAwOBAwEBEgwwMDc4MDIwNzg3MDIxIzAhBgkqhkiG9w0BCQEWFHN2LnRyeWFraW5AdGVuc29yLnJ1MR0wGwYDVQQKHhQEHgQeBB4AIAAiBBoEEgQQBCAAIjEKMAgGA1UECxMBMDEZMBcGA1UEDB4QBBQEGAQgBBUEGgQiBB4EIDEdMBsGA1UEAx4UBB4EHgQeACAAIgQaBBIEEAQgACIxGTAXBgNVBAQeEAQbBEsERwQ1BD0EOgQ BDIxMzAxBgNVBCoeKgQQBDsENQQ6BEEEMAQ9BDQEQAAgBBAEPQQwBEIEPgQ7BEwENQQyBDgERzELMAkGA1UEBhMCUlUxJzAlBgNVBAceHgQhBDAEPQQ6BEIALQQfBDUEQgQ1BEAEMQRDBEAEMzEzMDEGA1UECB4qADcAOAAgBDMALgAgBCEEMAQ9BDoEQgAtBB8ENQRCBDUEQAQxBEMEQAQzMTUwMwYDVQQJHiwEPwRAAC0EOgRCAC4EJQRDBDQEPgQ2BD0EOAQ6BD4EMgAsACAAOQAsACAAMTBjMBwGBiqFAwICEzASBgcqhQMCAiQABgcqhQMCAh4BA0MABEBx732/f74w8/LMylQDi6s0v/giDUqv Etk/s2ho1qlxgO6ynDXX1G9Tw6THiY4J8VvoqvOLJiujDQEC 2XOuSMo4IDxzCCA8MwGQYJKoZIhvcNAQkPBAwwCjAIBgYqhQMCAhUwDgYDVR0PAQH/BAQDAgTwMDYGBSqFA2RvBC0MKyLQmtGA0LjQv9GC0L7Qn9GA0L4gQ1NQIiAo0LLQtdGA0YHQuNGPIDMuNikwgZcGA1UdJQSBjzCBjAYHKoUDAgIiGQYHKoUDAgIiGgYHKoUDAgIiBgYGKoUDAhcDBggqhQMCQAEBAQYIKoUDAykBAwQGCCqFAwM6AgECBgkqhQMDPwEBAgQGBiqFAwNZGAYGKoUDA10PBgcqhQMFAygBBgcqhQMFAzABBggqhQMHAhUBAgYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdIAQWMBQwCAYGKoUDZHEBMAgGBiqFA2RxAjAdBgNVHQ4EFgQUCGZyN6aBd98RsS4IWlAzXSbpcBQwUAYDVR0jBEkwR4AUQQgjnJMgIIbzRRp5jSSIEfWtUvmhHaQbMBkxFzAVBgNVBAMTDlRFU1QtVEVOU09SLUNBghA1WUILNjyUn0SRDJQu uVoMFMGA1UdHwRMMEowSKBGoESGQmh0dHA6Ly90ZXN0LXRlbnNvci1jYS5jb3JwLnRlbnNvci5ydS9jZXJ0ZW5yb2xsL1RFU1QtVEVOU09SLUNBLmNybDB8BggrBgEFBQcBAQRwMG4wbAYIKwYBBQUHMAKGYGh0dHA6Ly90ZXN0LXRlbnNvci1jYS5jb3JwLnRlbnNvci5ydS9jZXJ0ZW5yb2xsL3Rlc3QtdGVuc29yLWNhLmNvcnAudGVuc29yLnJ1X1RFU1QtVEVOU09SLUNBLmNydDArBgNVHRAEJDAigA8yMDE2MDcxMzA4NTYwMFqBDzIwMTcxMDEzMDg1NjAwWjCCATIGBSqFA2RwBIIBJzCCASMMKyLQmtGA0LjQv9GC0L7Qn9GA0L4gQ1NQIiAo0LLQtdGA0YHQuNGPIDMuNikMUyLQo9C00L7RgdGC0L7QstC10YDRj9GO0YnQuNC5INGG0LXQvdGC0YAgItCa0YDQuNC/0YLQvtCf0YDQviDQo9CmIiDQstC10YDRgdC40LggMS41DE5D0LXRgNGC0LjRhNC40LrQsNGCINGB0L7QvtGC0LLQtdGC0YHRgtCy0LjRjyDihJYg0KHQpC8xMjEtMjI3MiDQvtGCIDEyLjEyLjIwMTMMT9Ch0LXRgNGC0LjRhNC40LrQsNGCINGB0L7QvtGC0LLQtdGC0YHRgtCy0LjRjyDihJYg0KHQpC8xMjgtMjM1MiDQvtGCIDE1LjA0LjIwMTQwCAYGKoUDAgIDA0EAinwcJLnXWuBR/oA8ylkRUkY2N9tsRlAlUVI4wHS6QnD98X/y0LHmxdW6Wic2mfxGOei5YTJgbguRB0mRzm 7EA==","ДействителенПо":"13.10.2021 09.06.00","ДействителенС":"13.07.2021 08.56.00","Должность":"","ИНН":"","Квалифицированный":"","Ключ":{"Тип":"Клиентский"},"Название":"ООО "КВАР"","Отпечаток":"1E20CF7679EA535EBD4DCF2FB20F56FC5B89F291","ФИО":"Лыченков Александр Анатольевич"}]}},"id":0}

Пример ответа (успех)

{"jsonrpc":"2.0","result":{"Сертификат":[{"Аутентификация":{"Зарегистрирован":"Да","Комментарий":""},"ДействителенПо":"13.07.2021 08.07.00","ДействителенС":"13.04.2021 07.57.00","Должность":"для тестовых запросов","ИНН":"1111654353","Издатель":"CA-SBIS-TEST","Квалифицированный":"Да","Ключ":{"Тип":"Клиентский"},"Название":"Тестовый Отправитель","Отпечаток":"6E3D6E662D33BF520312CAC4935912B039A5F5E2","СерийныйНомер":"7F6A5203000100000596","ФИО":"Иванов Иван Иванович"},{"Аутентификация":{"Зарегистрирован":"Да","Комментарий":""},"ДействителенПо":"13.07.2021 08.04.00","ДействителенС":"13.04.2021 07.54.00","Должность":"Директор","ИНН":"1111681325","Издатель":"CA-SBIS-TEST","Квалифицированный":"Да","Ключ":{"Тип":"Клиентский"},"Название":"Тестовый Получатель","Отпечаток":"877C347FA9C7986B0CCB518CD006B944B835AF1F","СерийныйНомер":"7F67A235000100000595","ФИО":"Петров Петр Петрович"}]},"id":0}

Симметричное шифрование файлов в openssl

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

Для шифрования используется команда следующего вида:

openssl enc -ШИФР -in ДЛЯ-ШИФРОВАНИЯ -out ЗАШИФРОВАНЫЕ-ДАННЫЕ

Для расшифровки похожая команда, но с опцией -d, также ЗАШИФРОВАНЫЕ-ДАННЫЕ теперь являются входными, а на выходе РАСШИФРОВАННЫЕ-ДАННЫЕ:

openssl enc -ШИФР -d -in ЗАШИФРОВАНЫЕ-ДАННЫЕ -out РАСШИФРОВАННЫЕ-ДАННЫЕ

В качестве ШИФРА рекомендуют aes-256-cbc, а полный список шифров вы можете посмотреть командой:

openssl enc -list

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

Эта опция включает использование алгоритма PBKDF2 для получения ключа. Указывать можно высокие значения — десятки и сотни тысяч. В разделе «Как создать базу данных KeePass» при создании базы данных используется такой же алгоритм (первая версия), там для 1 секундной задержки я выставлял значение в 25 миллионов инераций.

Пример шифрования файла art.txt шифром aes-256-cbc, зашифрованные данные будут помещены в файл с именем art.txt.enc, при получении ключа шифрования используется десять миллионов итераций (на моём железе выполнение команды заняло несколько секунд):

openssl enc -aes-256-cbc -in art.txt -out art.txt.enc -iter 10000000

Введите, а затем подтвердите пароль для шифрования:

В результате будет создан зашифрованный файл art.txt.enc.

Для расшифровки файла art.txt.enc и сохранения данных в файл art-new.txt:

openssl enc -aes-256-cbc -d -in art.txt.enc -out art-new.txt -iter 10000000

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

В случае неудачной расшифровки будет показано примерно следующее:

bad decrypt
140381536523584:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:583:

Возможные причины ошибки:

• неверный пароль
• неверный алгоритм для расшифровки
• неправильно указано количество итераций с опцией -iter
• неверно указан файл для расшифровки

Обратите внимание, что для расшифровки также нужно указать опцию -iter с тем же самым значением, которое было указано при шифровании. Конечно, можно не использовать опцию -iter при шифровании (а, следовательно, и при расшифровке), но в этом случае шифрование считается ненадёжным!

Не рекомендуется пропускать опцию. Если у вас слабое железо ИЛИ если файл будет расшифровываться на слабом железе, то вам необязательно использовать такие большие значения -iter — укажите хотя бы десятки или сотни тысяч (например, полмиллиона).

Предыдущие команды для шифрования и расшифровки могут запускаться чуть иначе:

openssl ШИФР

Например:

openssl aes-256-cbc -in art.txt -out art.txt.enc -iter 10000000

То есть пропускается слово enc, и перед шифром убирается дефис. Обе команды равнозначны.

Зашифрованный файл представляет собой бинарные данные, которые не получится передать, например, в текстовом сообщении (в чате). Используя опцию -a (или её псевдоним -base64), можно закодировать зашифрованные данные в кодировку Base64:

openssl enc -aes-256-cbc -in art.txt -out art.txt.b64 -iter 10000000 -a

Содержимое полученного файла art.txt.b64 можно открыть любым текстовым редактором и переслать в мессенджере или в чате.

Для расшифровки также нужно указать опцию -a:

openssl enc -aes-256-cbc -d -in art.txt.b64 -out art-new.txt -iter 10000000 -a

Чтобы просто закодировать бинарный файл в кодировку base64:

openssl enc -base64 -in file.bin -out file.b64

Чтобы раскодировать этот файл:

openssl enc -base64 -d -in file.b64 -out file.bin

Чтобы зашифровать файл используя указанный ПАРОЛЬ в команде (не интерактивный режим):

openssl enc -aes128 -pbkdf2 -d -in file.aes128 -out file.txt -pass pass:ПАРОЛЬ

Зашифровать файл, затем закодировать его с помощью base64 (например, его можно отправить по почте), используя AES-256 в режиме CTR и с получением производной ключа PBKDF2:

openssl enc -aes-256-ctr -pbkdf2 -a -in file.txt -out file.aes256

Декодировать файл из Base64 , затем расшифровывать его, используя пароль, указанный в файле:

openssl enc -aes-256-ctr -pbkdf2 -d -a -in file.aes256 -out file.txt -pass file:<ФАЙЛ-С-ПАРОЛЕМ>

Шифрование файлов и данных с gpg

Про шифрование в gpg нужно знать, что оно может быть:

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

Второе, что нужно знать: шифрование можно совмещать с подписыванием файла. Подписывание файла и проверку подписи мы рассмотрим далее. Также далее мы рассмотрим одновременное шифрование и подпись файла.

Третье: зашифровать можно одним или более публичными ключами.

Для шифрования файла используя симметричный метод с паролем используйте опцию -c (либо её длинный аналог –symmetric):

Следующая команда для шифрования файла test.php паролем в gpg:

gpg -c test.php

В результате шифрования будет создан файл с расширением .gpg (в данном случае это будет файл test.php.gpg).

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

• -e — означает шифрование данных
• -c — означает симметричное шифрование
• -r ‘id’ — означает зашифровать данные для пользователя с определённым id

Пример команды симметричного шифрования файла test.php для пользователя Alexey Miloserdov с возможностью его расшифровки приватным ключом ЛИБО для расшифровки паролем:

gpg -e -c -r 'Alexey Miloserdov' test.php

Точнее говоря, комбинирование двух опций -e и -c шифрует ключ сессии публичным ключом и симметричным шифром, поэтому для расшифровки может использоваться И приватный ключ, И пароль (на выбор). Если на другом компьютере, где вы расшифровываете файл, имеется ваш приватный ключ, то при расшифровке будет запрошен пароль приватного ключа. Если приватный ключ отсутствует, то будет запрошен пароль, который использовался при шифровании файла.

Для шифрования публичным ключом (-e), чтобы файл (test.php) мог расшифровать только владелец соответствующего парного приватного ключа (-r ‘Alexey Miloserdov’):

gpg -e -r 'Alexey Miloserdov' test.php

Вместо опции -r ‘Имя Адресата’ можно использовать опцию -R ‘Имя Адресата’ или её длинный аналог –hidden-recipient ‘Имя Адресата’. Она также шифрует файл для указанного адресата, но имя этого адресата шифруется.

Пример шифрования файла test.php публичным ключом пользователя Alexey Miloserdov, но с зашифрованным именем адресата.

gpg -e -R 'Alexey Miloserdov' test.php

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

Чтобы каждый раз не вводить имя получателя, можно установить значение по умолчанию опцией –default-recipient. Также с ней в комплекте идут опции –default-recipient-self и –no-default-recipient.