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

SSL сертификаты необходимы в Интернете для установления защищенного HTTPS соединения для сайта. Чаще всего HTTPS соединение используется в различных online-банках и интернет-магазинах; то есть на сайтах, где есть функция ввода персональных или конфиденциальных данных. Для того, чтобы эти данные в момент передачи из браузера на сервер невозможно было перехватить используется специальный HTTPS протокол, который шифрует все передаваемые данные. Для организации передачи данных по HTTPS протоколу необходимы цифровые SSL сертификаты.

Пример создания самоподписанного SSL сертификата и настройки конфигурации сервера Tomcat для создания защищенного SSL соединения представлен здесь.

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

официальный, подписанный центром авторизации;
самоподписанный, self-signed.

Официальный сертификат включает цифровую подпись организации, выдавшей сертификат CA (certificate authority). Цифровая подпись CA гарантирует, что сертификат не подделан. Цифровой сертификат является способом распространения публичного ключа шифрования.

Cамоподписанные сертификаты можно использовать для тестирования программного обеспечения. Отличие self-signed сертификата связано тем, что его подлинность невозможно проверить, если, конечно, Вы не создали его лично или не получили из надежного источника. В остальном self-signed сертификаты точно такие же, как и официальные. Программно self-signed сертификат могут использоваться точно также, как и официальные. Процесс создания самоподписанного сертификата представлен здесь.

Доверие, Trust

Концепция доверия (trust) цифровому сертификату является ключевым понятием установления SSL соединения. Здесь важным является способ получения сертификата. Сертификат может быть получен из надежного источника, например, лично от владельца сайта. В этом случае Вы будете уверены, что сертификат подлинный, и Вы действительно соединяетесь с настоящим сайтом. Однако часто сертификат получают с самого сервера при установлении соединения с сайтом из браузера; может возникнуть вопрос подлинности сертификата, поскольку связь между браузером и сайтом не прямая, а включает множество различных switch'ей ... , куда мог вклиниться нежеланный «на этом празднике жизни» гость типа хакера.

Модель доверия связана с тем, что каждый клиент или сервер принимает решение доверять определенным организациям CA, выдающим сертификаты. Доверять сертификатам CA — это значит считать их сертификаты легальными и идентифицирующая информация в сертификате корректна и заслуживает доверия. Так, например центр сертификации Verisign подписывает множество сертификатов для различных Internet компаний. Браузеры верят сертификатам Verisign по умолчанию. Идентификационная информация такого сертификата содержит цифровую подпись, сгенерированную CA, а клиент или сервер добавляют такой сертификат в хранилище сертификатов, называемый «truststore». Сохранение CA сертификата в truststore позволяет приложению java проверять цифровую подпись сертификата, сгенерированную CA, и решить вопрос доверия сертификату.

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

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

Для просмотра сертификата в хранилище можно использовать утилиту keytool с командой -list. Опции {-v | -rfc} позволяют вывести информацию сертификата в двух видах. На странице описания хранилища сертификатов и ключей приводятся примеры создания самоподписанного сертификата и нескольких ключей. Ниже представлены команды чтения информации хранилища и отображения данных сертификата (данные ключей не представлены).

Если при просмотре хранилища использовать опцию "-v", то информация о сертификате выводится с дополнительной информацией, включающей владельца, порядковый номер и т.д.


C:\Program Files\Java\jdk1.8.0_121\bin> \
  keytool -v -list -keystore keystore.jks
  Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 4 entries

Alias name: parent
Creation date: 13.02.2018
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF
Issuer: CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF
Serial number: 51a26f68
Valid from: Tue Feb 13 12:25:19 MSK 2018 until: Wed Feb 13 12:25:19 MSK 2019
Certificate fingerprints:
         MD5:  6C:6A:B7:3A:D2:67:23:23:7B:98:A8:E9:7C:E8:93:15
         SHA1: DB:8B:9D:9D:DF:5B:B3:82:0E:19:C6:A4:A4:3E:08:C0:AB:20:F9:85
         SHA256: EC:C9:09:49:F3:21:67:A9:B8:93:2B:0B:3B:29:C0:E2:47:20:2C:AB:0A:56:25:66:65:5A:81:34:EB:B2:CC:42
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 4D 34 BA 81 D5 A6 EA EA   25 60 BD E6 26 D3 46 2B  M4......%`..&.F+
0010: 11 CB 75 ED                                        ..u.
]
]

При просмотре хранилища с опцией "-rfc" информация о сертификатах, а публичный ключ также «обернут» сертификатом, выводится в печатаемом формате кодирования RFC-1421 (интернет-стандарт).


C:\Program Files\Java\jdk1.8.0_121\bin> \
  keytool -rfc -list -keystore keystore.jks
  Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 4 entries


Alias name: parent
Creation date: 13.02.2018
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
-----BEGIN CERTIFICATE-----
MIIDazCCAlOgAwIBAgIEUaJvaDANBgkqhkiG9w0BAQsFADBmMQswCQYDVQQGEwJS
RjEPMA0GA1UEBxMGTW9zY293MRgwFgYDVQQKEw9JVCBTeXN0ZW1zIEluYy4xEzAR
BgNVBAsTCkRldmVsb3BlcnMxFzAVBgNVBAMTDmphdmEtb25saW5lLnJ1MB4XDTE4
MDIxMzA5MjUxOVoXDTE5MDIxMzA5MjUxOVowZjELMAkGA1UEBhMCUkYxDzANBgNV
BAcTBk1vc2NvdzEYMBYGA1UEChMPSVQgU3lzdGVtcyBJbmMuMRMwEQYDVQQLEwpE
ZXZlbG9wZXJzMRcwFQYDVQQDEw5qYXZhLW9ubGluZS5ydTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAIHWRfxOrXXpo2Z5bvkW8fZQh6Ii+MG2e7OCxhyj
7gYaeXXBeJuBAdpopHaX2o8n9r6REio7UtdnME6AclN7U7RODPP5Ulj+I849/9HZ
ULTo+4NUOPoUbNmhtDujMhTJHC3lg49Ahvc8S/mkfx/QlVLtCTPGNiZPWbv78gKL
lO08b2yqboMTqDe3/bBjkq7tanyHkAbjq+NilA8kxToyVHM3rBLd9biybyj5Z+Wn
+It+ru3fc1/f8QGch9wyTpUXHrTK3Xq9JmkEbP565qeAwvnD3VINUCiYqBPWu+dw
5qQa6paz1gF1RTZOx7Tko2P3OM9E8YoeGDWOleTvL6gabvsCAwEAAaMhMB8wHQYD
VR0OBBYEFE00uoHVpurqJWC95ibTRisRy3XtMA0GCSqGSIb3DQEBCwUAA4IBAQA4
NYuP0MRwhZbdP8EbFRQbybh5Wnkwgma7k4tnMyy/lIcOVsUlBCFbA9YeHKxLGBXt
urAPjewFTTo/p04XuxdnIpMzaFwb1E6583XIpCDucRtVr9wI0K0HHyoWHAhdYrNU
W8IX7hezgJuDo2OjxMoGR1dCS1J5HaKCrY30p8+G5j/dk6iONtaFHW7ascJKvyjW
WBKoIxPd1sEB5dmtZp5sg2I7rMBOyxo2lwWAXbV4NP4h/HKhSv9QW9vBChRae/Rj
Q3iWnSIqvUFEr0gv2eci1X4/1O321GqQZL9FEzjMKoyxEueEuhyxhDmzQ7GhMhSn
nk379OpIrq/L65boDygU
-----END CERTIFICATE-----

В ОС Window сертификат можно просматривать в отдельном окне, которое позволяет также разместить его в определенном хранилище (кнопка Install Certificate) :

Запрос на сертификат

Чтобы получить доверенный SSL сертификат в центре сертификации CA необходимо сформировать специальный запрос Certificate Signing Request (CSR). Выполним данную операцию и создадим запрос на получение подписанного сертификата. В качестве самодписного сертификата используем сертификат, созданный в примере на странице описания хранилища ключей и сертификатов (описание здесь).

Для создания CSR необходимо выполнить команду -certreq утилиты keytool. Следующая команда создаст запрос на сертификат в виде файла certreq.csr :


C:\Program Files\Java\jdk1.8.0_121\bin> \
  keytool -certreq -alias parent -file certreq.csr \
          -keystore keystore.jks
		  
Enter keystore password:
Enter key password for <parent>

При выполнении команды утилита попросит ввести пароль для хранилища и ключа/сертификата. В примере создания самоподписанного сертификата были использованы пароли 'mystorepass' и 'mykeypass'. Запрос на сертификат представлен в файле certreq.csr, данные которого можно проверить в сервисах, представленных на страницах CSR Decoder и Cert Logik. Первый сервис выдает немного информации, как это представлено на следующем скриншоте :

Скриншот страницы csr-decoder.html с элементом CSR

Сервис Cert Logik выдает более подробную информацию (на скриншоте малый элемент) :

Скриншот страницы certlogik с элементом CSR

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

Цепочка сертификатов, Certificate Chain

Как правило сертификат включает несколько подписей, т.е. в сертификате хранится не одна подпись, а цепочка «Certificate Chain».

При генерировании пары ключей (приватный и публичный), как было отмечено выше, для публичного ключа автоматически генерируется self-signed сертификат. Т.е. изначально получаем пару из private ключа и сертификата, содержащего подписанный public ключ. В self-signed сертификате создатель ключа и подписывающий является одним лицом.

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

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