1 этап: Заказ SSL-сертификата | REG.RU

1 этап: Заказ SSL-сертификата | REG.RU Сертификаты

Что такое цепочка ssl сертификата? – freehost

FAQ->Виртуальный хостинг->SSL сертификаты

SSL сертификат подключаемый на сайт должен состоять из нескольких частей:

  1. Сертификат для домена;
  2. Корневой сертификат (Root);
  3. Сертификат посредника. Ссертификатов посредника может быть несколько. (Intermediate)

Все это, кроме сертификата для домена называется цепочкой SSL сертификата (CA Bundle). Она информирует приложение, которое запрашивает сертификат, о том кто выдал и подтвердил его.

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

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

  • корневой сертификат – CARoot.crt
  • сертификат посредника 1 – Intermediate1.crt
  • сертификат посредника 2 – Intermediate2.crt
  • сертификат для домена — domain.crt

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

Самый распространенный центр сертификации это GeoTrust. Этот центр сертификации обычно присылает сертификаты архивом, в теле письма.

Скачать полную цепочку сертификата можно на следующих страницах официального сайта GeoTrust:
RapidSSL – на этой странице.
QuickSSL, QuickSSL Premium – на этой странице.
True BusinessID / True BusinessID Wildcard – на этой странице.

Статьи по теме:

  1. Что такое SSL сертификат и зачем он нужен?
  2. Формирование «Самоподписанного» SSL сертификата для сайта.
  3. Формирование платного сертификата.
  4. Подключение SSL сертификата на сайт.
  5. Что такое цепочка SSL сертификата?

Что в tls 1.3?

Все упомянутые трудности решаются использованием TLS 1.3. Половины проблем вообще нет, всё проще, красивее, всё прям отличненько. Но TLS 1.3 еще распространен маловато. Самые важные отличия TLS 1.3 (их очень много, они везде, поэтому только самые важные):

  • Плохие шифры удалены, остались только хорошие. Инициализировать сессию TLS 1.3 на плохих шифрах не получится. Всё дело в новых cipher suites: тут и другие алгоритмы обмена сеансовых ключей, и так называемый HMAC – не будем углубляться в подробности, потому что Патрик устал. Вкратце: раньше подпись каждого TLS-пакета шла отдельно. На это были атаки, потому что было известно, какой там контент находится. Сейчас ее запихали вовнутрь (режим AEAD), и в TLS 1.3 по-другому быть не может, соответственно, мы избавились от таких атак.
  • Handshake стал короче – нет старых сообщений, нет старых расширений, нет возможности по каким-то странным штукам обменяться ключиками. То есть, он тупо короче количественно – даже самый полный TLS 1.3 handshake короче, чем в TLS 1.2.
  • Переход на шифрованный канал происходит почти что сразу. Для этого используются разные ключики: да, пока не договорились о хороших ключиках, оптимальных, мы используем какие попало, но канал уже шифрованный. То есть hello – hello и пошло всё зашифрованное. Из-за этого сложнее всё это ломать.
  • Всё регламентировано, больше не надо пытаться менять размеры пакетов, забивая их ноликами, чтобы сложнее было расшифровывать.
  • Своя пара ключей на каждую сеансовую фазу. Сеансовые ключи меняются: пока мы ни о чем не договорились – они такие, договорились о более крутых – они более крутые, сертификаты проверили и всё хорошо – еще другие ключи. В итоге их много, они усложняются и очень трудно это всё поломать. Еще одна важная вещь, почему это быстрее: Early Data (она же 0-RTT, Zero Round Trip Time) – это когда у тебя в TLS-handshake посылается полезная инфа – ну например GET-запрос. То есть нет такого, что поговорили-поговорили и только потом посылаем что-то отдельным потоком. Сразу же в handshake идет запрос. Как только сервер его получил, он начинает его обрабатывать, отдает клиенту свои данные, сертификат и пока клиент проверяет, сервер уже готов отдать. И может даже в TLS-handshake и отдать иногда.
  • Есть pre-shared key, то есть клиент с сервером могут договориться и сохранить сеансовые ключи для последующих соединений. И, соответственно, когда происходит handshake таких вот договорившихся клиентов, на этап выбора ключей время не тратится. Долго объяснять, как это сделано криптографически, но тех атак, которые были на Session ID, вот в этом месте сейчас нет (что хорошо). Всё стало безопаснее и быстрее.

Основная проблема, что поддержка TLS 1.3 – она во всех браузерах, которые актуальны, есть, но не во всех по дефолту включена. Например, в Safari нет (но там очень легко включить), Google Chrome и Mozilla Firefox уже по дефолту поддерживают TLS 1.3. Ngnix с TLS 1.3 – без проблем, в Apache есть нюансы, а вот с почтовыми клиентами хуже — там только Exim молодец, а остальные не очень.

В общем, это наше будущее, там всё получше и попроще, самое главное. Но пока оно еще не везде наступило.

Что такое чейн ssl сертификата

технически x.509-сертификат — это файл, содержащий публичный ключ (и ещё некоторую служебную информацию) и подпись издателя (ею подписывается и ключ и служебная информация).

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

и так рекурсивно до «самого главного» издателя, иначе говоря — корневого центра сертификации.

такая цепочка связанных подписями сертификатов называется «цепочкой доверия». («чейн» — это, вероятно, транслитерация английского слова «цепочка» — «chain»)

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

----- BEGIN CERTIFICATE -----

и

----- END CERTIFICATE -----

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

----- BEGIN CERTIFICATE -----
base64 одного сертификата
----- END CERTIFICATE -----
----- BEGIN CERTIFICATE -----
base64 другого сертификата
----- END CERTIFICATE -----
...

возможно, под фразой «очистить чейн» подразумевается «оставить только один сертификат» (вероятно, самый последний из выпущенных, так сказать, «конечный»). уточните у того, от кого услышали эту фразу.

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

Essl — embedded secure socket layer

Дальше я представлю на Ваш суд результаты моих исследований данного вопроса проверенные опытным путем. Термин

eSSL

пришел мне в голову в процессе написания этой статьи, так что любые упоминания прошу употреблять вместе со ссылкой на


Итак, освещу немного

важные аспекты строения сертификатов

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

private key

). Сертификат также содержит в себе открытый ключ для проверки подлинности данных содержащихся в этих строковых полях. Перечень полей определен в формате Х.509 v3 и описан в документе

RFC 5280

(это последняя на данный момент редакция документа, до этого действовал

RFC 3280

). Сертификат содержит поле

commomName

которое описывает имя субъекта сертификации, обычно оно совпадает с доменом веб-сайта для которого выпущен сертификат, но в стандарте нет никаких запретов на то что будет вписано в эту строку, например, строка “Вася Пупкин” будет так же валидна для этого поля с точки зрения стандарта — это

Про сертификаты:  Единая система идентификации и аутентификации. Методические рекомендации по использованию Единой системы идентификации и аутентификации Версия 2.20

первый аспект

. Но веб-браузеры проверяют именно это поле на соответствие с именем сайта который предъявляет сертификат. К счастью для нас в формате X509 v3 определены дополнительные расширения, одно из которых

subjectAltName

, которое позволяет добавить идентификаторы, связанные с основным именем субъекта сертификации (

commomName

). Такими идентификаторами могут быть:

и это

второй

и, пожалуй, наиболее важный

аспект

строения сертификатов 3й версии стандарта. Дело в том что таких идентификаторов можно добавить несколько, т.е. можно вписать несколько IP адресов для которых будет валиден выпущенный сертификат. А это и есть то что нам нужно в случае если некое устройство имеет два Ethernet интерфейса для работы в разных под-сетях, да еще и возможность выхода в сеть через различные типы модемов, если соединение будет по PPP, то это будет третий интерфейс со своим IP адресом. Опытным путем мною был установлен

один важный момент

в назначении альтернативных IP адресов. Браузеры Internet Explorer и FireFox по разному производят проверку альтернативных имен. FireFox сверяет адрес который указан в идентификаторе

IP

, а IE — сверяет адрес с идентификатором

DNS

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

должен быть указан и как IP и как DNS

. О том как это сделать будет рассказано дальше.

Ocsp stapling

Это примерно в ту же степь, но тут мы уже начинаем уходить от структуры Certificate Authority. То есть возлагаем эту проверку на сервер. Как это работает: сервер периодически ходит по этому OSCP URL-у и говорит: «OCSP-resolver, посмотри-ка, вот этот мой сертификат – в отозванных или нет?».

OCSP-resolver отвечает подписанным ответом, наш сервер его запоминает, и когда клиент приходит, ему отдаётся этот ответ. То есть у клиента есть подписанный ответ и в нём написано, что всё хорошо. Из-за того, что серверов меньше, чем клиентов и сервер может на какое-то время это кэшировать, нагрузка на всех становится меньше.

Тут есть тоже некоторые проблемы: текущий механизм — это только на один сертификат, а у нас цепочка (и это важно). А еще, из-за того, что мой сервер отвечать на это не обязан, клиент не может рассчитывать на то, что OSCP-stapling точно будет. И поэтому отказаться ни от CRL, ни от OCSP не получается – просто потому, что серверы не обязаны опрашивать и отвечать. Ну и еще один аспект: если в вебе с этим нормально, то в почте всё плохо, а в FTP даже слов таких не знают.

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

Вот это всё вместе теоретически может начать работать, но пока еще мало распространено.

Google и Mozilla, так как им всё это не нравится, сделали свой CRL. И зашили его в браузер. Огонь вообще! Это работает быстро, ну и на этом все плюсы заканчиваются. Для того чтобы не помереть, они не запихивают в него DV-сертификаты. То есть если DV-сертификат отозван, они считают – ну и ладно.

Так что если DV-сертификат отозван и при этом нет OSCP-степлинга, Chrome об этом не скажет – он посчитает этот сертификат нормальным. На самом деле, правильно пользоваться OSCP-степлингом иOCSP Must Staple флагом в сертификате.

Алгоритмы шифрования


Для симметричного шифрования использовались разные алгоритмы. Первым был блочный

DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит

с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.

Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.

Еще был блочный шифр RC2 с переменной длиной ключа, который работал быстрее DES, а его 128-битный ключ был сопоставим с 3DES по надежности. Потоковый шифр RC4 был намного быстрее блочных и строился на основе генератора псевдослучайных битов. Но сегодня все эти алгоритмы считаются небезопасными или устаревшими.

Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.

Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.

DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.

ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.

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

Дёргаем цепочку сертификатов

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

На 4-м сертификате дёргать их вручную стало лень (а я ленив по натуре), поэтому набросал «самокат» выцепляющий издателя и формирующий chain-файл для скармливания nginx’у.
Наверняка он не идеален и проверен лишь на полуторадесятках сертификатов, но чем богаты.

Об устройстве x.509 много сказано (в том числе на хабре), поэтому повторяться не буду.

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

Всё нижесказанное актуально для:

Скрытый текст
$ uname -or
FreeBSD 10.3-STABLE
$ openssl version
OpenSSL 1.0.2h  3 May 2021
$ `echo $SHELL` --version
tcsh 6.18.01 (Astron) 2021-02-14 (x86_64-amd-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec
$ /usr/local/bin/bash --version
GNU bash, version 4.3.25(1)-release (amd64-portbld-freebsd10.0)

Итак, предположим, что у нас есть PEM-сертификат сайта. Для примера мы возьмём сертфикат ya.ru (не только ж пинговать его).

$ echo | openssl s_client -connect ya.ru:443 | openssl x509 -certopt ca_default -out ya.pem -outform PEM

Помимо самого кодированного запроса, версии, подписи и т.п. в нём имеется ряд расширений. Одно из которых

Authority Information Access

нас и интересует:

$ openssl x509 -in ./ya.pem -noout -text | grep 'Authority Information Access' -A 2
            Authority Information Access:
                OCSP - URI:http://yandex.ocsp-responder.com
                CA Issuers - URI:http://repository.certum.pl/ycasha2.cer

Параметр

CA Issuers

как раз и содержит следующий в цепочке сертификат. Как правило, данный сертификат либо в

PEM

, либо в

DER

(как в нашем случае) форматах.

$ fetch http://repository.certum.pl/ycasha2.cer

На деле

PEM

формат не более чем

base64

представление

DER

и получить

PEM

из

DER

можно сделав

base64 ./ycasha2.cer ./ycasha2.pem

и обрамив кодированный текст

“—–BEGIN CERTIFICATE—–“,”—–END CERTIFICATE—–“

. Однако, логичнее и проще сделать это преобразование средствами

Про сертификаты:  Прогулку на теплоходе River Palace по Москве реке купить на ФурПур

openssl

:

$ openssl x509 -inform der -in ./ycasha2.cer -out ./ycasha2.pem

Едем дальше и смотрим следующий сертификат в цепочке:

$ openssl x509 -in ./ycasha2.pem -noout -text | grep 'Authority Information Access' -A 2
            Authority Information Access:
                OCSP - URI:http://subca.ocsp-certum.com
                CA Issuers - URI:http://repository.certum.pl/ctnca.cer
$ fetch http://repository.certum.pl/ctnca.cer

Преобразовываем и его:

$ openssl x509 -inform der -in ./ctnca.cer -out ./ctnca.pem

В данном сертификате (т.к. он корневой) отсутствует расширение

Authority Information Access

:

$ openssl x509 -in ./ctnca.pem -noout -text | grep 'X509v3 extensions' -A 6
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                08:76:CD:CB:07:FF:24:F6:C5:CD:ED:BB:90:BC:E2:84:37:46:75:F7
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign

То есть на нём и закончим вытягивание цепочки. Осталось собрать это всё в chain-файл:

$ cat ya.pem ycasha2.pem ctnca.pem > chain0.pem

Вроде бы теперь можно ставить (если есть Private Key), но остановлюсь ещё на паре нюансов.

Установив свой сертификат на свой Яндекс проверяем его:

$ echo | openssl s_client -connect ya.ru:443 | grep Verify
    Verify return code: 0 (ok)

Всё хорошо, но это лишь потому, что в дефолтных путях

-CApath, -CAfile

моего

openssl

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

openssl

с багом, в которой не «цеплялись» default CApath (если не ошибаюсь с 1.0.1с по 1.0.1e), то получим неприятность в виде:

$ echo | openssl s_client -connect ya.ru:443 -CApath . | grep Verify
    Verify return code: 20 (unable to get local issuer certificate)

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

openssl

пытается отыскать его по хешу сертификата.

$ openssl x509 -noout -hash -in ./ctnca.pem
48bec511
$ ln -s `pwd`/ctnca.pem `pwd`/48bec511.0

И теперь наша система доверяет ya.ru:

$ echo | openssl s_client -connect ya.ru:443 -CApath . | grep Verify
DONE
    Verify return code: 0 (ok)

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

Выполняем:

$ ./issuers.sh ./ya.pem
0
http://repository.certum.pl/ycasha2.cer
tmp.der                                       100% of 1196  B   16 MBps 00m00s
IS PEM: [0]
DER(tmp.der) -> PEM(./ya.pem0.pem)
/usr/bin/openssl  x509 -inform der -in tmp.der -out ./ya.pem0.pem
1
http://repository.certum.pl/ctnca.cer
tmp.der                                       100% of  959  B   13 MBps 00m00s
IS PEM: [0]
DER(tmp.der) -> PEM(./ya.pem1.pem)
/usr/bin/openssl  x509 -inform der -in tmp.der -out ./ya.pem1.pem
cat ././ya.pem* > chain.pem
Certificate chain:
-rw-r--r--  1 root  wheel  5842 Jun 30 15:46 chain.pem

Сверяем показания:

$ md5 chain0.pem ; md5 chain.pem
MD5 (chain0.pem) = 6d32b0798d48d14764cd26cc4f730444
MD5 (chain.pem) = 6d32b0798d48d14764cd26cc4f730444

Как-то так… Разумеется скрипт не универсален, всё на скорую руку в предверии грандиозного шухера. Комментарии/пожелания приветствуются, но отвечать вряд ли смогу — у нас тут (в Беларуси)

дурдом

деноминация.

Закрытый ключ

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

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQCVqGpH2S7F0CbEmQBgmbiDiOOGxhVwlG yY/6OBQoPKcx4Jv2h
vLz7r54ngjaIqnqRNP7ljKjFLp5zhnAu9GsdwXbgLPtrmMSB MVFHTJvKjQ eY9p
dWA3NbQusM9uf8dArm 3VrZxNHQbVGXOIAPNHTO08cZHMSqIDQ6OvLma7wIDAQAB
AoGAbxKPzsNh826JV2A253svdnAibeSWBPgl7kBIrR8QWDCtkH9fvqpVmHa 6pO5
5bShQyQSCkxa9f2jnBorKK4 0K412TBM/SG6Zjw DsZd6VuoZ7P027msTWQrMBxg
Hjgs7FSFtj76HQ0OZxFeZ8BkIYq0w 7VQYAPBWEPSqCRQAECQQDv09M4PyRVWSQM
S8Rmf/jBWmRnY1gPPEOZDOiSWJqIBZUBznvOPOOQSH6B vee/q5edQA2OIaDgNmn
AurEtUaRAkEAn7/65w Tewr89mOM0RKMVpFpwNfGYAj3kT1mFEYDq iNWdcSE6xE
2H0w3YEbDsSayxc36efFnmr//4ljt4iJfwJAa1pOeicJhIracAaaa6dtGl/0AbOe
f3NibugwUxIGWkzlXmGnWbI3yyYoOta0cR9fvjhxV9QFomfTBcdwf40FgQJAH3MG
DBMO77w8DK2QfWBvbGN4NFTGYwWg52D1Bay68E759OPYVTMm4o/S3Oib0Q53gt/x
TAUq7IMYHtCHZwxkNQJBAORwE 6qVIv/ZSP2tHLYf8DGOhEBJtQcVjE7PfUjAbH5
lr  9qUfv0S13gXj5weio5dzgEXwWdX2YSL/asz5DhU=
-----END RSA PRIVATE KEY-----

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

Импорт корневого сертификата в ie8 (windows 7 64bit)

В меню Пуск в строке поиска наберите certmgr и нажмите комбинацию клавиш Ctrl Shift Enter, ответьте утвердительно на запрос прав администратора. У Вас запустится менеджер сертификатов.

Дважды кликните на разделе Trusted Root Certification Authorities

Кликните правой кнопкой мыши на Certificates -> All Tasks -> Import…

1 этап: Заказ SSL-сертификата | REG.RU


Запустится мастер импорта сертификатов, следуйте его инструкциям и в качестве сертификата укажите ca.crt. Если в результате получите ошибку

1 этап: Заказ SSL-сертификата | REG.RU

То поправьте ключ в реестре

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftSystemCertificatesRootProtectedRootsFlags

установите его в

и перезапустите менеджер сертификатов.

Мы рассмотрели некоторые возможности SSL сертификатов позволяющие идентифицировать систему имеющую несколько IP адресов и/или Доменных имен, а так же рассмотрели простейший сценарий применения сертификатов во встраиваемых системах. Можно ли улучшить этот сценарий?

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

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

Немого общей имформации об ssl

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

Certification Authority

) и подписываются электронными подписями. Сертификаты подтверждаются в браузерах путем проверки цепочки сертификатов (

Certification Path

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

1 этап: Заказ SSL-сертификата | REG.RU


Проблема

встраиваемых систем

в том, что,

  • во-первых, это не web-сайт в общем понимании этого слова (вспомните, например, веб-интерфейс Wi-Fi роутера), в момент выпуска изделия он не имеет окончательного IP адреса, и еще менее вероятно чтобы он имел какой то домен.
  • во-вторых, конечный пользователь может сменить и IP, и домен, если таковой был, хотя бы в целях все той же безопастности.
  • в-третьих, покупать сертификат довольно дорого, а вопрос снижения себестоимости стоит всегда.

Как же решать эти проблемы?

Откуда берутся сертификаты?

Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.

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

    not trusted

  2. Приобрести сертификат в УЦ. Это будет стоить денег в зависимости от различных его характеристик и возможностей, указанных выше.
  3. Получить бесплатный сертификат LetsEncrypt, доступны только самые простые DV сертификаты.

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

openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pem

Далее, создает CSR — запрос на подписание сертификата.

openssl req -new -sha256 -key private.key -out server.csr -days 730

И подписываем.

openssl x509 -req -sha256 -days 365 -in server.csr -signkey private.key -out public.crt

Результат можно посмотреть командой:

openssl x509 -text -noout -in public.crt

Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:

openssl -help
openssl x509 -help
openssl s_client -help

Ровно то же самое можно сделать с помощью java утилиты keytool.

keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048

Следует серия вопросов, чтобы было чем запомнить поля owner и issuer

What is your first and last name?
What is the name of your organizational unit?
What is the name of your organization?
What is the name of your City or Locality?
What is the name of your State or Province?
What is the two-letter country code for this unit?
Is CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU correct?

Конвертируем связку ключей из проприетарного формата в PKCS12.

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12

Смотрим на результат:

keytool -list -v -alias selfsigned -storepass password -keystore keystore.jks
Alias name: selfsigned
Creation date: 20.01.2021
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Issuer: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Serial number: 1f170cb9
Valid from: Sat Jan 20 18:33:42 MSK 2021 until: Tue Jan 15 18:33:42 MSK 2021
Certificate fingerprints:
     MD5:  B3:E9:92:87:13:71:2D:36:60:AD:B5:1F:24:16:51:05
     SHA1: 26:08:39:19:31:53:C5:43:1E:ED:2E:78:36:43:54:9B:EA:D4:EF:9A
     SHA256: FD:42:C9:6D:F6:2A:F1:A3:BC:24:EA:34:DC:12:02:69:86:39:F1:FC:1B:64:07:FD:E1:02:57:64:D1:55:02:3D

Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 30 95 58 E3 9E 76 1D FB   92 44 9D 95 47 94 E4 97  0.X..v...D..G...
0010: C8 1E F1 92                                        ....
]
]

Значению ObjectId: 2.5.29.14 соответствует определение ASN.1, согласно RFC 3280 оно всегда non-critical. Точно так же можно узнать смысл и возможные значения других ObjectId, которые присутствуют в сертификате X.509.

subjectKeyIdentifier EXTENSION ::= {
    SYNTAX SubjectKeyIdentifier
    IDENTIFIED BY id-ce-subjectKeyIdentifier
}

SubjectKeyIdentifier ::= KeyIdentifier

По какому принципу работает ssl сертификат?

Итак для того, чтобы получить SSL сертификат самое первое, что нужно сделать, это сформировать специальный запрос на выпуск сертификата, так называемый (Certificate Signing Request). При формировании этого запроса вам будет задан ряд вопросов, для уточнения деталей о вашем домене и вашей компании. После завершения ваш веб сервер создаст 2 типа криптографических ключей — приватный ключ и публичный ключ.

Про сертификаты:  Сертификат на сою -

Публичный ключ не является секретным и он помещается в запрос CSR.Вот пример такого запроса:—–BEGIN CERTIFICATE REQUEST—–MIIC3zCCAccCAQAwgZkxCzAJBgNVBAYTAlVBMQ0wCwYDVQQIEwRLaWV2MQ0wCwYDVQQHEwRLaWV2MRQwEgYDVQQKEwtIb3N0QXV0b21hdDEQMA4GA1UECxMHaG9zdGluZzEmMCQGCSqGSIb3DQEJARYXc3VwcG9ydEBob3N0YXV0b21hdC5jb20xHDAaBgNVBAMTE3d3dy5ob3N0YXV0b21hdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTg7iUv/iX SyZl74GcUVFHjFC5IqlTNEzWgLWrsSmxGxlGzXkUKidNyXWa0O3ayJHOiv1BSX1l672tTqeHxhGuM6F7l5FTRWUyFHUxSU2Kmci6vR6fw5ccgWOMMNdMg7V5bMOD8tfI74oBkVE7hV95Ds3c594u7kMLvHR xui2S3z2JJQEwChmflIojGnSCO/iv64RL9vjZ5B4jAWJwrruIXO5ILTdis41Z1nNIx3bBqkif0H/G4eO5WF6fFb7etm8M d8ebkqEztRAVdhXvTGBZ4Mt2DOV/bV4e/ffmQJxffTYEqWg8wb465GdAJcLhhiSaHgqRzrprKns7QSGjdAgMBAAGgADANBgkqhkiG9w0BAQUFAAOCAQEAuCfJKehyjt7N1IDv44dd V61MIqlDhna0LCXH1uT7R9H8mdlnuk8yevEcCRIkrnWAlA9GT3VkOY3Il4WTGg3wmtq6WAgLkVXQnhIpGDdYAflpAVeMKil8Z46BGIhKQGngL2PjWdhMVLlRTB/01nVSKSEk2jhO8 7yLOY1MoGIvwAEF4CL1lAjov8U4XGNfQldSWT1o8z9sDeGsGSf5DAXpcccx0gCyk90HFJxhbm/vTxjJgchUFro/0goVpBcredpKxtkwBMuCzeSyDnkQft0eLtZ9b9Q4 ZNDWsPPKxo/zWHm6Pa/4F4o2QKvPCPx9x4fm /xHqkhkR79LxJ EHzQ==—–END CERTIFICATE REQUEST—–

Данные которые содержатся в этом ключе можно легко проверить с помощью сервисов CSR Decoder. Как пример: CSR Decoder 1 или CSR Decoder 2. Второй сервис выдает больше информации о CSR и проверяет ее на валидность, поле Signature в результатах проверки.

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

Разновидности ssl-сертификатов

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

Сертификаты начального уровня с проверкой домена Domain Validation (DV)

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

Сертификаты бизнес-класса с проверкой организации Organization Validation (OV) или Company Validation (CV)

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

Сертификаты с расширенной проверкой Extended Validation (EV)

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

Подробнее о видах читайте в статье Типы SSL-сертификатов.

Сertificate transparency

Итак, всё хорошо, но Google не был бы Google, если бы не придумал еще одну технологию конкретно для себя. Она называется Сertificate Transparency. Откуда что идет: Google очень беспокоится о том, чтобы кто-нибудь не выписал плохой сертификат на него самого – чтобы именно Google не пострадал от того, что кто-то там выписывает какие-то нехорошие сертификаты.

И вот с помощью Сertificate Transparency каждый владелец домена (и вообще кто угодно) может посмотреть, какие сертификаты на этот домен были выписаны. Дальше он может этот сертификат взять и с ним что-нибудь сделать. Например, проверить, хороший он или нет. Ну и возбудиться (или не возбудиться).

Это не только технология, но и набор процессов. То есть Google говорит: ребята, вот у нас есть Сertificate Transparency, мы в него записываем только нормальные сертификаты – такие, где цепочка есть, цепочка правильная и всё нормально. Мы можем время записи Сertificate Transparency Log запихать в сертификат, чтобы клиент мог четче посмотреть, что вот этот сертификат в Transparency Log должен быть тогда-то.

Мы гарантируем, что это вот эта штука не редактируема обратно (из-за того, что блокчейн) – ну то есть нельзя взять и подменить старые записи, можно только добавлять новые. И давайте, ребята, кто-нибудь из вас будет периодически ходить по этому логу, и проверять, что там всё нормально, а если что-то не так, говорить нам и мы будем это править. А другие ребята пусть держат у себя всё это, потому что надо, чтобы было много мощностей на вот эту вот штуку.

Словарный запас

Определение X.509 сертификатов есть в архиве ITU-T

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  EXPLICIT Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3

Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.

Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.

Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.

Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией.

Хеш и mac


Цель хеш-алгоритма —

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

Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных — MAC (message authentication code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение.

В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.

Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего именно SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита (вместо 32), количество раундов в цикле равно 80 (вместо 64), а сообщение разбивается на блоки по 1024 бита (вместо 512 бит). Раньше для тех же целей применялся алгоритм SHA1 и MD5, но сегодня они считаются уязвимыми.

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

Особенности сертификата extendedssl:

  • автоматическая ежедневная проверка на Malware и фишинг,
  • выпускается только для выбранного домена (для поддоменов требуется покупка дополнительных сертификатов),
  • доступен только компаниям,
  • адресная строка браузера подсвечивается зелёным цветом,
  • требуется предоставление документов о работе компании, существование компании проверяется,
  • шифрование до 256 бит в современных браузерах и в браузерах, не имеющих ограничения на шифрование,
  • высокая совместимость с интернет-браузерами,
  • обеспечивает проверку доменного имени,
  • подтверждает существование компании и её бизнес-уровень,
  • неограниченное бесплатное переиздание сертификата в течение срока действия,
  • выдаётся код для установки логотипа Thawte Trusted Site в качестве дополнительного подтверждения.
Оцените статью
Мой сертификат
Добавить комментарий