Глубокое погружение в SSL-сертификаты

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

Выпейте кофе и начнем.

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

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

Типы шифрования

Сегодня используются два типа механизмов шифрования.

Симметричный

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

Это простой метод, и шифрование можно выполнить быстро.

Мы не будем обсуждать этот тип шифрования в этой статье.

Асимметричный

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

Эти два ключа математически связаны. Шифрование занимает больше времени по сравнению с предыдущим процессом.

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

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

Жизненный цикл сертификатов SSL

Мы рассмотрим пример и обсудим каждый шаг использования SSL и почему этот шаг важен.

Шаг 1. Создайте открытый и закрытый ключ

Допустим, у Тома есть веб-сайт, и он хочет внедрить SSL для защиты своего веб-сайта. Для этого он сначала сгенерирует 2 ключа.

* Закрытый ключ: этот ключ остается на веб-сайте и никогда не раскрывается. Сервер будет использовать этот ключ для шифрования данных и отправки их клиентам.

openssl genrsa -out private.pem 2048

* Открытый ключ: этот ключ открыт для внешнего мира и используется клиентами веб-сайта Тома.

openssl rsa -in private.pem -outform PEM -pubout -out public.pem

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

Теперь вот еще одна проблема. Как пользователи сайта Тома узнают, что это сайт Тома? Что мешает злоумышленникам создать еще один веб-сайт, такой же, как у Тома, и разместить его на хостинге? Пользователи могут по ошибке перейти на другой веб-сайт и указать свои учетные данные и т. д.

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

Шаг 2. Создайте CSR

Чтобы сертифицировать сертификат Тома, нам нужно обратиться к уполномоченному органу (их так много, как Godaddy, Verisign, Norton и т. д.), создав запрос CSR (запрос на подпись сертификата). Файл CSR должен быть сгенерирован пользователем, поэтому здесь Том использует свой закрытый ключ для создания CSR.

Вот как можно создать CSR.

openssl req -new -key private.pem -out certificate.csr

Здесь будет несколько вопросов, на которые нам нужно ответить, например:

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) [AU]:US
State or Province Name (full name) [Some-State]:New Jersey
Locality Name (eg, city) []:Maple Shade
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Stayingfoolish.org
Organizational Unit Name (eg, section) []:Tech
Common Name (e.g. server FQDN or YOUR name) []:stayingfoolish.org
Email Address []:...

После ответов на все эти вопросы мы получим файл .csr (здесь certificate.csr).

Файл certificate.csr не является сертификатом, который Том может использовать на своем веб-сайте. Это цифровая форма (стандартный способ) отправки запроса на подпись сертификата.

Наиболее распространенным форматом для CSR является спецификация PKCS #10; другой формат — Signed Public Key and Challenge SPKAC, генерируемый некоторыми веб-браузерами.

Этот файл CSR необходимо отправить в выбранный Центр сертификации, который после проверки множества материалов предоставит сертификат, который Том может использовать на своем веб-сайте.

Шаг 3. Подать заявку на CSR (запрос на подпись сертификата)

После получения CSR от Тома центр сертификации выполняет несколько задач. Вот ссылка для просмотра ролей центра сертификации. Вот некоторые из них:

1. Получать, аутентифицировать и обрабатывать запросы на отзыв сертификатов.
2. Идентифицируйте и аутентифицируйте подписчиков, вот сертификат Тома и его подлинность.
3. Получите открытый ключ от подписчика, вот открытый ключ из сертификата Тома.
4. Убедитесь, что у подписчика есть асимметричный закрытый ключ, соответствующий открытому ключу.

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

Несколько концепций

Так что же такое сертификат?

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

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

susamn@vulcan ~ openssl s_client -showcerts -connect medium.com:443
CONNECTED(00000003)
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify return:1
depth=1 C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = medium.com
verify return:1
---
Certificate chain
 0 s:C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = medium.com
   i:C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3
-----BEGIN CERTIFICATE-----
MIIFETCCBLigAwIBAgIQDcdN2TIZa+h9cFHogUeAEDAKBggqhkjOPQQDAjBKMQsw
CQYDVQQGEwJVUzEZMBcGA1UEChMQQ2xvdWRmbGFyZSwgSW5jLjEgMB4GA1UEAxMX
Q2xvdWRmbGFyZSBJbmMgRUNDIENBLTMwHhcNMjEwNTA2MDAwMDAwWhcNMjEwODAz
MjM1OTU5WjBqMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQG
A1UEBxMNU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQQ2xvdWRmbGFyZSwgSW5jLjET
MBEGA1UEAxMKbWVkaXVtLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABG8a
guZXgCdiy54ryMtywI8sybQNP40rrwEXqa25bVfxHhREIB8yAORIqRobEShes0rc
RTLvopxKY/NYCCCIdemjggNeMIIDWjAfBgNVHSMEGDAWgBSlzjfq67B1DpRniLRF
+tkkEIeWHzAdBgNVHQ4EFgQUGQyl1nRsBEHtV/ePtxr/UHtdCv8wIwYDVR0RBBww
GoIMKi5tZWRpdW0uY29tggptZWRpdW0uY29tMA4GA1UdDwEB/wQEAwIHgDAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwewYDVR0fBHQwcjA3oDWgM4YxaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL0Nsb3VkZmxhcmVJbmNFQ0NDQS0zLmNybDA3
oDWgM4YxaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0Nsb3VkZmxhcmVJbmNFQ0ND
QS0zLmNybDA+BgNVHSAENzA1MDMGBmeBDAECAjApMCcGCCsGAQUFBwIBFhtodHRw
Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwdgYIKwYBBQUHAQEEajBoMCQGCCsGAQUF
BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQAYIKwYBBQUHMAKGNGh0dHA6
Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9DbG91ZGZsYXJlSW5jRUNDQ0EtMy5jcnQw
DAYDVR0TAQH/BAIwADCCAX8GCisGAQQB1nkCBAIEggFvBIIBawFpAHYA9lyUL9F3
MCIUVBgIMJRWjuNNExkzv98MLyALzE7xZOMAAAF5QFDoKAAABAMARzBFAiABzzxD
hWcvpGJFkO/vNr3f3lfQnL6emfIp2a703DAD9AIhAJACvhIkMj2pBwQZHz0bB1YD
kgasVxZdiRdgzPxE65YbAHcAXNxDkv7mq0VEsV6a1FbmEDf71fpH3KFzlLJe5vbH
DsoAAAF5QFDi5QAABAMASDBGAiEAgSW1T6TMhHGPcol5TjqPmaRoPSNcG3cA94/h
3/8Sv6oCIQDuwGUai6NRrq1s2CJFjoGAUFDDohAyUF/KWKKhZ4q+1gB2AESUZS6w
7s6vxEAH2Kj+KMDa5oK+2MsxtT/TM5a1toGoAAABeUBQ6HMAAAQDAEcwRQIgaTSM
OXNx4k52vjHqLZ5FYZQI8dNlcBG6etBeHpK2EFsCIQCMFalEWlozhhFqJ2IRlpZq
YioXeZMI+fD8WG7bCUCIbTAKBggqhkjOPQQDAgNHADBEAiBFoNUxOU6eQpbGOOz9
P2zqcDfCzlNV+4cUS0MjRn96nAIgfAy10yYeu+uwSQJw7ZrfGaNpEQUyTg+mTXyg
7v1MekU=
-----END CERTIFICATE-----
... more contents

Сертификат находится между — — -BEGIN CERTIFICATE — — — и — — -END CERTIFICATE — . Это закодированные данные.

Кодировки сертификатов

По своей сути это сертификат x.509 (стандарт для определения сертификатов открытых ключей), который закодирован и/или снабжен цифровой подписью в соответствии с RFC 5280.

Существует много путаницы в отношении того, что такое DER, PEM, CRT и CER, и многие неверно говорят, что все они взаимозаменяемы. Хотя в некоторых случаях некоторые из них могут быть заменены, лучше всего определить, как закодирован сертификат, а затем правильно пометить его.

Кодировки (также используемые как расширения)

• .DER = Расширение DER используется для сертификатов в двоичной кодировке DER. Эти файлы также могут иметь расширение CER или CRT. Правильным использованием английского языка будет «У меня есть сертификат в кодировке DER», а не «У меня есть сертификат DER».
• .***PEM ***= Расширение PEM используется для различных типов файлов X.509v3, содержащих защищенные данные ASCII (Base64) с префиксом строки «— — BEGIN…».

Операции с сертификатами

Просмотреть закодированный сертификат PEM

openssl x509 -in cert.pem -text -noout
openssl x509 -in cert.cer -text -noout
openssl x509 -in cert.crt -text -noout

Просмотреть сертификат в кодировке DER

openssl x509 -in certificate.der -inform der -text -noout

Преобразование

#PEM to DER
openssl x509 -in cert.crt -outform der -out cert.der#DER to PEM
openssl x509 -in cert.crt -inform der -outform pem -out cert.pem

Что такое подпись?

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

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

Теперь есть еще одна проблема.

Когда Том отправляет CSR (открытый ключ внутри него) в центр сертификации, как центр сертификации может подтвердить, что это Том? Любой может отправить CSR. Подумайте немного.

Первая проверка, которую должен выполнить CSR, прежде чем выполнять все остальные проверки, заключается в том, что именно Том отправил этот CSR, верно? и единственный способ сделать это — узнать пользователя (здесь это Том), который отправляет CSR, владеет закрытым ключом открытого ключа в CSR.

Чтобы помочь в вышеупомянутом процессе проверки, используется подпись. В любом месте:

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

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

Каждый CSR или сертификат будет иметь раздел подписи. Вот подпись CSR, которую мы создали на шаге 2.

Центр сертификации при получении CSR сделает то же самое, чтобы подтвердить, что именно Том отправляет CSR.

Проверка сертификата выполняется одинаково везде с использованием подписи и не зависит от сертификата. После проверки всего проверяемого, затем центр сертификации готов подписать сертификат Тома.

Что такое самозаверяющий сертификат?

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

openssl x509 -req -sha256 -days 365 -in certificate.csr -signkey private.pem -out server.crt

Самоподписанные сертификаты используются только в тестах и ​​разработках, так как нет необходимости обращаться в центр сертификации и платить им деньги. Он никогда не используется в производственной среде, поскольку они являются очень легкой мишенью для атак MITM (Man-In-The-Middle).

Шаг 3. Центр сертификации подписывает сертификат

Теперь вопрос, что значит подписать сертификат?

Подписание просто означает, что центр сертификации проверил сертификат (в данном случае сертификат Тома) и теперь может поручиться за подлинность сертификата Тома. После подписания ЦС предоставляет сертификат пользователю, в данном случае Тому.

Чтобы подписать, центр сертификации

1. Рассчитывает контрольную сумму сертификата Тома (на рис. 1) с использованием некоторого алгоритма.
2. Шифрует контрольную сумму с помощью закрытого ключа (центра сертификации).
3. Добавляет зашифрованную контрольную сумму в сертификат Тома в качестве подписи.
4. Добавляет собственную информацию/метаданные (от центра сертификации) в сертификат

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

Если мы развернем CloudFlare Inc ECC CA-3, мы увидим его информацию. У него есть открытый ключ, срок действия (от и до) и многое другое.

Центр сертификации (CloudFlare Inc ECC CA-3) также имеет свой закрытый ключ, который держится в секрете и использует его для создания подписи для сертификата Тома.

Обратите внимание, поскольку этот центр сертификации (CloudFlare Inc ECC CA-3) сертифицирует сертификат medium.com, поэтому имя субъекта на рис. 5 совпадает с имя издателя Pic 2.**

Но подождите секунду. Почему центр сертификации (CloudFlare Inc ECC CA-3) также имеет подпись (выделена синим цветом на рис. 5)? Кто-то также сертифицирует Cloudflare CA?

Еще несколько концепций…

Корневой сертификат и промежуточный сертификат

Как оказалось, я солгал. Настоящая картинка 4 такова:

Помимо CloudFlare, есть еще один центр сертификации (который сертифицирует medium.com). Это корневой центр сертификации. В этом случае корневым центром сертификации является Baltimore Cybertrust Root (корневые центры сертификации обычно имеют Root в конце своего имени, чтобы сделать их очевидными).

Корневой сертификат также работает таким же образом. Точно так же, как центр сертификации CloudFlare подписал сертификат medium.com, используя свой закрытый ключ, корневой центр сертификации (здесь Baltimore Cybertrust Root) использует свой закрытый ключ для подписи CloudFlare<. /strong> сертификат, рис. 5.

Если мы откроем корневой сертификат (Baltimore Cybertrust Root), то увидим следующее:

requests.get(url, verify="/path/to/cert")

"/etc/ssl/certs/ca-certificates.crt" // Debian/Ubuntu/Gentoo etc.
"/etc/pki/tls/certs/ca-bundle.crt"   // Fedora/RHEL 6
"/etc/ssl/ca-bundle.pem"             // OpenSUSE
"/etc/pki/tls/cacert.pem"            // OpenELEC
"/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem" // CentOS/RHEL 7
"/etc/ssl/cert.pem"                 // Alpine Linux