Ssl tls что это

«Как это работает»: знакомство с SSL/TLS

Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.

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

/ Flickr / David Goehring / CC-BY

SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.

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

Рукопожатие

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

Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.

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

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

Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр 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-сертификатах можно использовать сразу несколько методов шифрования для большей защиты.

Хеш и 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 велись достаточно давно, но в конце февраля алгоритм был официально взломан. Исследователям удалось добиться коллизии хешей, то есть одинакового хеша для двух разных файлов, что доказало небезопасность использования алгоритма для цифровых подписей. Первая попытка была сделана еще в 2015, хотя тогда удалось подобрать только те сообщения, хеш которых совпадал. Сегодня же речь идет о целых документах.

Сертификаты бывают разные

Теперь, когда мы разобрались, что представляет собой протокол SSL/TLS и как происходит соединений на его основе, можно поговорить и о видах сертификатов.

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

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

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

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

Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.

Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.

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

SSL/TLS Certificate: What is it and Why You Need One

Ever since the mid-90s, protocols have been used to provide better security and privacy for internet communications. One of the most critical security features for domains is the SSL certificate. In this resource, you’ll learn all about SSL and TLS protocols and how certificates work.

What is SSL?

Secure Sockets Layer (SSL) is a protocol that digitally authenticates ownership of public keys. First developed by Netscape in 1995, SSL provides secure connections between client- and server-side internet communications. The SSL protocol was deprecated with the release of TLS 1.0 (see below).

What is TLS?

TLS stands for Transport Layer Security and is the successor to the SSL protocol. Like SSL, the purpose of TLS is encrypting and authenticating data between servers and web applications. This protocol was developed by the Internet Engineering Task Force (IETF) in 1999. The most current version of TLS is version 1.3, which was released in 2018.

Did you know?: TLS first started development by IETF as SSL 3.1 but was renamed so as not to be associated with Netscape.

SSL vs TLS: What’s the Difference?

According to IETF, there are no major differences between SSL and TLS as they both carry out the same function. That said, TLS is more secure than its predecessor. Servers using the TLS protocol not only require support for a higher level of encryption but must also support the most recent TLS protocols. Old habits die hard, though. While TLS is the preferred protocol, SSL is still used in some cases and TLS is even referred to as SSL — but the term “TLS” is catching on slowly but surely.

In regards to SSL or TLS certificates, there’s really no difference. The terms are used interchangeably regardless of which protocol is being utilized. This is because both SSL and TLS certificates follow the X.509 standard format for public keys.

Fun Fact: Despite previous attacks against the SSL protocol (BEAST and BREACH), version 3.0 was still extensively used until 2014 when the POODLE vulnerability was discovered by Google.

How SSL/TLS Certificates Work

One of the safest and widely used methods of encryption is asymmetrical cryptography, which involves two cryptographic keys: public and private. The public key is used to encrypt data while the private key decrypts it. Picture the public key as a safe with a drop slot. Anyone can add something to the safe, but only the person with the combination can see what’s inside. In this case, the private key is what holds the combination to the safe. SSL/TLS certificates utilize this type of cryptography to complete what is called a digital handshake.

HTTP vs HTTPS

HTTP and HTTP are protocols that every website uses. The only difference between them is security. Any site that uses HTTPS is also utilizing TLS/SSL to encrypt communication and is therefore much more secure than sites running over HTTP. It’s easy for anyone to determine whether a site is using encryption or not. For example, any URL that has HTTPS:// is using TLS/SSL. If it only has HTTP://, the site is not secured by encryption. Another way to spot HTTPS in a website address is the padlock to the left of the URL. If you click on the lock icon, it will confirm that the site is secure.

If you click on “Certificate,” you’ll also see the certificate authority when it was issued, and for how long it is valid.

SSL or TLS Handshake

The digital handshake for SSL/TLS represents the events that take place between clients and servers. It entails sending encrypted messages between a client and a server to guarantee the integrity of the data being sent or accessed. Most handshakes follow the below pattern but may deviate if a server is using a different handshake protocol, such as Diffie-Hellman Key Exchange.

1. Client greeting (hello)
   Client initiates handshake by sending a hello message to an SSL-certified website.
2. Server greeting (hello)
   Server responds with the site’s SSL certificate.
3. Authentication
   Client verifies the certificate
4. Pre-master secret
   The client obtains a public key from the server’s SSL/TLS certificate, and then sends it back as an encrypted string of bytes.
5. Decryption
   Server decrypts the public key (pre-master secret)
6. Session Keys
   The client and server generate random session keys alongside the pre-master secret, which should receive the same results on both sides.
7. Client and server ready
   Client and server both send encrypted “final” messages with session keys.
8. Secure symmetric encryption achieved
   Handshake concludes and communication is continued via session keys.

Types of SSL Certificates

There are three types of SSL certificates available: Single Domain, Wildcard, and Multi-domain.

As the name implies, single domain certificates protect one domain and subdomain within its hierarchy. Wildcard SSL certificates function the same as a Single Domain certificate, except it also certifies all first-level subdomains. Multi-domain SSL certificates protect an unlimited amount of domains and subdomains.

SSL Certificate Costs

Prices for certificates range considerably and will also vary depending on the needs of your organization. The type of certificate number of domains and subdomains you have plays a large part in the cost, but other factors such as level of assurance needed, warranty, reissues, key length, and encryption strength should also be taken into consideration.

Free SSL Certificate

Free Certificate Authorities are also an option. While this can save on costs, there may be several limitations to free certificates, so you want to make sure it will meet all your requirements. For instance, many free SSL certificates are trial-based or are only for a limited time before you need to renew. Even if renewal is free, you’ll need to make sure your certificate doesn’t expire. Another caveat is that many free issuers don’t offer business or extended validation. The important thing is that you research all your options before choosing a Certificate Authority for your domain.

Common SSL Certificate Errors

Almost all modern browsers can recognize SSL certificates. But every so often, end users can encounter errors with a domain’s certificate. Knowing what the common errors are can help maintain trust in your website.

• Your connection isn’t private: This happens when a browser can’t verify your domain’s SSL certificate. Because the browser can’t confirm the domain’s identity, it blocks the user from accessing the site.
• Expired certificate: If you don’t renew your domain’s certificate before it expires, users will get an error message alerting them to the fact that your certificate is no longer valid.
• Untrusted Certificate Authority: When this error is encountered, it means that the browser was unable to locate the root certificate from a trusted source. This can also happen if a certificate is self-signed and not added to a browser’s trusted store.

Of course, this isn’t an exhaustive list of SSL certificate errors. It is highly advisable that someone on your team is familiar with how certificates work and how to troubleshoot them in case of any unforeseen issues.

SSL Certificate Checker

Luckily, there are online tools available to help troubleshoot installation problems and other issues with SSL certificates. Here’s a quick list of a few popular options:

SSL/TLS Certificates Recap

SSL certificates are an important security measure for websites. With an SSL certificate, domains can encrypt web traffic with SSL/TLS protocols for enhanced protection. While SSL is still used by some websites, the preferred and most secure protocol for internet communications is TLS. The bottom line is that certificates not only protect users from suspicious websites, but also help businesses maintain trust in their brand.

SSL/TLS

SSL (Secure Sockets Layer) и TLS (Transport Level Security) — криптографические протоколы, обеспечивающие защищенную передачу данных в компьютерной сети. Они широко используются в веб-браузерах, а также при работе с электронной почтой, обмене мгновенными сообщениями и в IP-телефонии.

Соединение, защищенное протоколом TLS, обладает одним или несколькими следующими свойствами:

• Безопасность: симметричное шифрование защищает передаваемую информацию от прочтения посторонними лицами.
• Аутентификация: «личность» участника соединения можно проверить с помощью асимметричного шифрования.
• Целостность: каждое сообщение содержит код (Message Authentication Code, MAC), с помощью которого можно проверить, что данные не были изменены или потеряны в процессе передачи.

Так как большинство протоколов связи могут быть использованы как с TLS/SSL, так и без него, при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Один способ добиться этого — использовать порт, по которому соединение всегда устанавливается с использованием TLS (например, 443 для HTTPS). Другой способ — использовать специальную команду серверу от клиента переключить соединение на TLS (например, STARTTLS для протоколов электронной почты).

История SSL

SSL изначально разработан компанией Netscape для добавления протокола — HTTPS в свой веб-браузер Netscape Navigator, потому что компания считала, что безопасное соединение между клиентом и сервером в первую очередь послужит успехом развитию Интернета как инструмента бизнеса.

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

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

Устройство протокола SSL

Протокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, LDAP, TELNET и т.д.) и транспортным протоколом TCP/IP. SSL защищает данные, выступая в роли фильтра для обеих сторон и передает их далее на транспортный уровень.

Работу протокола можно разделить на два уровня:

• Слой протокола подтверждения подключения (Handshake Protocol Layer)
• Слой протокола записи

Первый слой, в свою очередь, состоит из трех подпротоколов:

• Протокол подтверждения подключения (Handshake Protocol)
• Протокол изменения параметров шифра (Cipher Spec Protocol)
• Предупредительный протокол (Alert Protocol)

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

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

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

Протокол записи

Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.

Существует четыре протокола записи:

• Протокол рукопожатия (handshake protocol);
• Протокол тревоги (alert protocol);
• Протокол изменения шифра (the change cipher spec protocol);
• Протокол приложения (application data protocol);

Принцип работы SSL

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

Клиент инициирует рукопожатие посылая “hello”-сообщение серверу. Такое сообщение содержит список алгоритмов симметричного шифрования (cipher specs), поддерживаемых клиентом. Сервер отвечает похожим “hello”-сообщением, выбрав при этом наиболее подходящий алгоритм шифрования из полученного списка. Далее сервер отправляет сертификат, который содержит его публичный ключ.

Сертификат — это набор данных, который подтверждает подлинность. Подтвержденная третья сторона, известная как центр сертификации (CA), генерирует сертификат и проверяет его подлинность. Чтобы получить сертификат сервер должен использовать безопасные каналы для отправки своего публичного ключа в центр сертификации. Он генерирует сертификат, который содержит его собственный ID, ID сервера, публичный ключ сервера и другую информацию. А также центр сертификации создает отпечаток (digest) сертификата, который, по сути, является контрольной суммой. Далее центр сертификации создает подпись сертификата (certificate signature), которая формируется путем шифрования отпечатка сертификата приватным ключом центра сертификации.

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

Фаза рукопожатия завершается отправкой “finished”-сообщений, как только обе стороны готовы начать использование секретного ключа. Начинается фаза передачи данных, в ходе которой каждая сторона разбивает исходящие сообщения на фрагменты и прикрепляет к ним коды авторизации сообщений MAC (message authentication code). Код авторизации сообщения это зашифрованный отпечаток, вычисленный на основе содержимого сообщений. Из соображений безопасности, он не совпадает с секретным ключом и вычисляется вместе с секретным ключом на стадии рукопожатия. Для получения полноценного SSL пакета каждая из сторон объединяет данные фрагмента, код авторизации сообщения, заголовки сообщения и шифруют с использованием секретного. При получении пакета, каждая из сторон расшифровывает его и сверяет полученный код авторизации сообщения со своим. Если они не совпадают, то пакет был подделан.

Цифровые сертификаты

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

Способы получения SSL-сертификата:

• Использовать сертификат, выданный центром сертификации (Certification authority)
• Использовать самоподписанный сертификат
• Использовать «пустой» сертификат

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

Хэширование

Хеш-значение является идентификатором сообщения, его размер меньше размера оригинального сообщения. Самыми известными хеш-алгоритмами являются MD5 (Message Digest 5), который создает 128-битное хеш-значение, SHA-1 (Standard Hash Algorithm), создающий 160-битное хеш-значение, SHA-2 и SHA-3. Результат работы алгоритма хеширования — значение, которое используется для проверки целостности передачи данных.

Шифрование

Существует два основных способа шифрования данных: симметричный ключ (общий секретный ключ) и асимметричный ключ (открытый ключ).

Открытый ключ

Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из них используется в качестве открытого (как правило, он публикуется в самом сертификате владельца), второй ключ называется секретным — он держится в тайне и никогда никому не открывается. Оба ключа работают в паре: один используется для запуска противоположных функций другого ключа. Если открытый ключ используется для того, чтобы зашифровать данные, то расшифровать их можно только секретным ключом и наоборот. Такая взаимосвязь позволяет делать две важные вещи.

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

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

RSA — самый распространенный алгоритм шифрования с использованием асимметричных ключей.

Секретный ключ

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

Комбинированный подход

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

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

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

Аутентификация и обмен ключами

SSL поддерживает 3 типа аутентификации:

• аутентификация обеих сторон (клиент — сервер),
• аутентификация сервера с неаутентифицированным клиентом,
• полная анонимность.

Обычно для аутентификации используются алгоритмы: RSA, DSA, ECDSA.

Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный сервер должен предоставить допустимый сертификат клиенту. Каждая сторона отвечает за проверку того, что сертификат другой стороны ещё не истек и не был отменен. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента.

Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret).

Анонимный обмен ключами

Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret).

Аутентификация и обмен ключами при использовании RSA

В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура содержит текущее значение сообщения Client_Hello.random, таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера.

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

Аутентификация и обмен ключами при использовании протокола Диффи-Хеллмана

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

Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты (pre_master_secret) каждый раз, когда они устанавливают соединение. Для того, чтобы предотвратить хранение секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.

Восстановление сессии

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

Администрирование

Обслуживание сертификатов и ключей

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

Хранилище идентификаторов сессий

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

SSL 1.0, 2.0, 3.0 и TLS

Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL 3.0 версии.

Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS 1.0. Его также часто называют SSL 3.1.

Хотя TLS и SSL имеют существенные различия в реализации, разработчики обычно замечают лишь немногие из них, а конечные пользователи вовсе их не различают. Тем не менее TLS 1.0 и SSL 3.0 несовместимы. Значительное различие состоит в том, что TLS требует определенные алгоритмы шифрования, которые SSL не поддерживает. Таким образом TLS сервер должен “откатиться” (downgrade) до SSL 3.0 для работы с клиентами, использующими SSL 3.0.

Принцип работы TLS

Протокол TLS делится на два слоя: TLS Record и TLS Handshake.

Подтверждение связи (handshake)

1. Клиент посылает сообщение ClientHello, указывающее версию SSL или TLS и поддерживаемые клиентом методы шифрования (англ. CipherSuite). Это сообщение также содержит случайное число (набор байт), которое используется в последующих вычислениях. Протокол также позволяет указать поддерживаемые клиентом методы сжатия данных.
2. Сервер отвечает сообщением ServerHello, которое содержит метод шифрования, выбранный сервером из списка, предложенного клиентом, а также идентификатор сессии и еще одно случайное число. Также сервер посылает свой цифровой сертификат. Если серверу нужен сертификат для аутентификации клиента, на этом шаге он может послать клиенту запрос такого сертификата.
3. Клиент проверяет сертификат сервера.
4. Клиент отправляет случайное число, которое клиент и сервер используют для шифрования последующих сообщений. Сама строка из байт шифруется публичным ключом сервера.
5. Если сервер потребовал у клиента сертификат, клиент отсылает набор байт, зашифрованный его секретным ключом, и свой цифровой сертификат, или оповещение об отсутствии сертификата.
6. Сервер проверяет сертификат клиента.
7. Клиент и сервер отправляют друг другу сообщение ChangeCipherSpec, объявляя об изменении режима передачи данных с незащищенного на защищенный.
8. Клиент отправляет сообщение Finished, зашифрованное секретным ключом, и таким образом завершает подтверждение связи со своей стороны.
9. Аналогичные действия производит сервер.
10. На протяжении данной сессии клиент и сервер могут обмениваться сообщениями, зашифрованными секретным ключом.

Возобновление сессии

1. Клиент посылает сообщение ClientHello, используя ID сессии, которую нужно возобновить.
2. Сервер проверяет, есть ли у него в кэше соответствующий идентификатор. Если есть и сервер способен возобновить сессию, он отсылает клиенту сообщение ServerHello с этим же ID сессии. Если нет, сервер генерирует новый ID сессии и выполняет процедуру handshake с клиентом.
3. Клиент и сервер обмениваются сообщениями ChangeCipherSpec, а затем Finished.
4. Передача данных по защищенному каналу возобновляется.

Протокол записи (TLS Record)

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

• Разбиение исходящих сообщений на блоки нужного размера и «склеивание» входящих сообщений.
• Сжатие исходящих сообщений и распаковку входящих (используется не всегда).
• Применение кода аутентификации к исходящим сообщениям и проверку входящих с помощью MAC.
• Шифрование исходящих сообщений и дешифровку входящих.

После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.

Руководство по выживанию — TLS/SSL и сертификаты SSL (X.509)

Это руководство по выживанию рассматривает такую вводящую в ступор тему, как сертификаты TLS/SSL и X.509 (SSL), в том числе самоподписанные сертификаты. В нём присутствуют элементы того, что часто называют инфраструктурой открытых ключей (Public Key Infrastructure, PKI).

То, что мы в просторечии называем сертификатами SSL, в действительности должно называться сертификатами X.509. Термин «сертификат SSL» получил распространение в связи с адаптацией Netscape формата сертификата X.509 (одного из стандартов служб каталогов X.500 ITU) при разработке этой компанией оригинальных версий протокола SSL (Secure Socket Layer) в те доисторические времена, когда мир был ещё молод, по планете бродили динозавры, а Интернет был дружелюбным местом. Термин «сертификат SSL» сохраняется и, скорее всего, сохранится в обозримом будущем, поскольку при произношении «сертификат SSL» и «сертификат X.509» первую из фраз выговаривать удобнее. Безусловно, эксперты-лингвисты смогут замечательно это обосновать, ссылаясь на то, что S звучит куда лиричнее, чем X. Для нас, простых смертных, главное преимущество первой фразы в том, что она короче.

В настоящий момент руководство включает SSL, TLS, некоторые детали о X.509 и их применении, а также кое-какие разъяснения о типах сертификатов, в том числе о сертификатах EV, и о процессе доверия. Создание самоподписанных сертификатов представлено в виде рабочего примера использования пакета OpenSSL.

Вы можете либо купить сертификат SSL (X.509), либо сгенерировать свой собственный (самоподписанный) для тестирования или, в зависимости от приложения, даже применения в производственной среде. Хорошие новости: При использовании самоподписанных сертификатов Вы сэкономите несметное количество денег. Плохие новости: При использовании самоподписанных сертификатов никто кроме Вас и (возможно) Ваших ближайших родственников не сможет им доверять. Но, прежде чем выкладывать все свои сбережения за новенький блестящий сертификат X.509 (SSL) или даже за более дорогой сертификат EV SSL (X.509), Вам, вероятно, хотелось бы знать, что они делают и как они это делают. И если Вы впадаете в ступор как только люди начинают говорить об SSL, защите информации и сертификатах — самое время туда впасть. Это руководство не будет лёгким чтивом.

<укоренившиеся привычки> В приведённом ниже списке RFC гиперссылки указывают на текстовые версии, которые мы скопировали на наш сайт, когда эти RFC были выпущены. Мы начинали делать это очень, очень давно, когда RFC содержались в каких-то странных местах, иногда меняющих своё местоположение, а производительность и доступность этих репозиториев оставляла желать лучшего (мягко сказано). Сегодня всё это далеко не так. У IETF и IANA есть солидные веб-сайты с прекрасной производительностью и постоянно совершенствующимися возможностями. Тем не менее, мы упорно продолжаем следовать нашей укоренившейся привычке без всякой видимой причины (старого пса новым трюкам не выучишь. ).

Примечание: Если Вы хотите/предпочитаете/нуждаетесь в более продвинутом представлении RFC, то следующая информация специально для Вас. Основной репозиторий RFC поддерживается IETF, текстовые версии (которые считаются нормативными) можно найти на www.ietf.org/rfc/rfcXXXX.txt или на www.rfc-editor.org/rfc/rfcXXXX.txt (где XXXX — состоящий из 4 цифр номер RFC, при необходимости дополненный слева нулями). Опубликованные на настоящий момент RFC размещены на https://www.rfc-editor.org/info/rfcXXXX, здесь содержится различная информация и ссылки на текстовые (нормативные) и PDF (ненормативные) версии документов. RFC в также можно посмотреть на http://datatracker.ietf.org/doc/rfcXXXX/, здесь же содержится различная статусная информация по RFC (в том числе сообщения об ошибках), а также ссылки на просмотр в различных форматах, таких как текст, PDF и HTML (это версии документов, находящиеся в работе). Наконец, существует страница поиска по RFC.</укоренившиеся привычки>

Примечание переводчика: в русском варианте страницы ссылки указывают на HTML-версии RFC на сайте https://tools.ietf.org/html/.

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

Содержание:

Протокол TLS/SSL

Основное предназначение сертификатов SSL (X.509) — использование совместно с протоколом TLS/SSL. Secure Sockets Layer (SSL, уровень защищённых сокетов) — протокол, изначально разработанный Netscape в 1992 году для безопасного обмена информацией между web-сервером и браузером по незащищённым сетям. Претерпел несколько изменений, нынешняя версия 3 датируется 1995 годом и используется в различных клиент-серверных приложениях. В связи с распадом Netscape спецификации SSL в дальнейшем обновляться не будут. Таким образом, этот стандарт повторил судьбу известного мёртвого попугая, и, в конце концов, в RFC 7568 SSL v3 признан устаревшим. Теперь это официально мёртвый стандарт, и потому впредь его использовать не стоит, хотя бы ради сохранения на Земле главенства разумного, доброго и вечного.

IETF стандартизировала Transport Layer Security (TLS, безопасность транспортного уровня) версии 1, незначительно отличающийся от SSL, в RFC 2246, версии 1.1 в RFC 4346, наконец версии 1.2 в RFC 5246. Кроме того, в RFC 3546 определено несколько расширений для случаев, когда TLS используются в системах с ограниченной пропускной способностью, таких как беспроводные сети, в RFC 6066 определён ряд расширений TLS, внесённых в формат расширенного приветствия клиента (представленного в TLS 1.2), в RFC 6961 определён метод уменьшения трафика, когда клиент запрашивает у сервера информацию о состоянии сертификата. И, наконец, в RFC 7925 определяется, что происходит с TLS (и DTLS) при его использовании в IoT (Internet of Things, Интернете вещей или Интернете вещичек, как презрительно называем его мы).

При первоначальной установке защищённого соединения, в зависимости от реализации, будут проводиться переговоры о поддержке конкретного протокола из набора SSLv3, TLSv1, TLSv1.1 или TLSv1.2. Все так привыкли к названию SSL, что в большинстве случаев то, что называют SSL, скорее всего является использованием TLS — например, OpenSSL поддерживает и SSL (версии 3) и TLS (версий 1, 1.1 и 1.2). Поскольку SSL и TLS отличаются друг от друга лишь в деталях, дальнейшее описание относится к обоим протоколам.

Примечание: SSLv2 был отменён RFC 6176, в котором приводится ужасающий список всех его недостатков. Та же печальная участь теперь постигла и SSLv3: он был отменён RFC 7568. Все встречающиеся далее упоминания SSL сохранены в тексте по причине широкого распространения этого термина (он до сих пор используется чаще, чем TLS), однако читателям следует помнить, что речь идёт о TLS.

TLS/SSL работают поверх TCP, но ниже по уровню тех конечных пользовательских протоколов, которые они защищают, таких как HTTP или IMAP (как показано на рисунке 1):

За самими протоколами TLS/SSL не закреплено какого-либо общеизвестного номера порта — вместо этого при использовании с протоколом более высокого уровня, например HTTP, принято обозначать, что этот протокол будет использовать защищённый вариант (HTTPS в случае HTTP), у которого как раз есть общеизвестный номер порта (или порт по умолчанию). Обозначение HTTPS просто указывает на то, что нормальный протокол HTTP будет работать поверх соединения TLS/SSL, которые в свою очередь работают поверх TCP. В случае HTTPS общеизвестный номер порта — 443, в случае IMAPS — 993, POP3S — 995 и так далее.

Дальнейшее описание требует некоторого знакомства с терминами MAC (Message Authentication Code, аутентификационный код сообщения), односторонние хэши, симметричные и асимметричные криптографические алгоритмы. Для тех, кто с ними не знаком, рекомендуется почитать это руководство по выживанию, касающееся криптографии. Осторожно, прочтение этого материала может вызывать переутомление и фобии.

Родственный протокол, Datagram Transport Layer Security (DTLS, безопасность транспортного уровня для дейтаграмм), определяет сервис безопасности при использовании UDP (RFC 6347, обновлён в RFC 7507). Поскольку его принципы аналогичны TLS, в дальнейшем в данном руководстве DTLS не обсуждается.

Термин TLS 1.2 Suite B (определённый в RFC 6460) определяет набор шифров (смотрите ниже), совместимых с NSA Suite B Cryptography, и имеет значение только при использовании TLS для приложений в интересах национальной безопасности США.

Обзор — установление защищенного соединения

При установлении защищенного соединения с помощью TLS/SSL, например при использовании HTTPS (порт по умолчанию — 443), между клиентом, который всегда является инициатором соединения, и сервером происходит обмен сообщениями. Первый набор сообщений называется протоколом рукопожатия (Handshake Protocol), после обмена этими сообщениями и клиент и сервер входят в протокол записи (или данных) (Record (Data) Protocol). При обмене сообщениями во время протокола рукопожатия достигаются следующие цели:

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

Отправляются аутентификационные данные. Обычно сервер посылает аутентификационную информацию в форме сертификата (встроенную в сертификат) X.509 (SSL), но протокол поддерживает и другие методы.

Устанавливается идентификатор (ID) сессии, таким образом, при необходимости сессия может быть перезапущена.

Происходят переговоры о наборе шифров, состоящем из алгоритма обмена ключами вместе с типом алгоритма шифрования объёмных данных и типом MAC, которые будут использоваться в последующей сессии обмена данными (протокол записи). Обычно в качестве алгоритма обмена ключами используется асимметричный алгоритм (с закрытым и открытым ключом), такой как RSA, DSA или ECC (Elliptic Curve Cipher, шифр на основе эллиптических кривых, смотрите RFC 5289). Асимметричные алгоритмы потребляют очень много ресурсов процессора и потому для последующего шифрования объемных данных (протокол записи) используются симметричные шифры. Алгоритмы обмена ключами применяются для передачи информации, на основании которой могут быть независимо вычислены сеансовые ключи для симметричного шифра. MAC используется для защиты целостности передаваемых/получаемых данных во время протокола записи.

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

Рисунок 2 — Последовательность обмена сообщениями протоколов TLS/SSL

В фазе протокола рукопожатия проводятся переговоры и устанавливается соединение, а в фазе протокола записи происходит передача (инкапсуляция) зашифрованного потока данных, таких как HTTP, SMTP или IMAP.

На рисунке 2 чёрными стрелками показаны сообщения, отправляемые открытым текстом (незашифрованные); синими — сообщения, отправляемые с использованием открытого ключа, предоставленного сервером (с помощью шифра обмена ключами), для их обработки требуется, чтобы у сервера был доступ к соответствующему закрытому ключу; зелёными — сообщения, отправляемые с использованием того алгоритма шифрования объёмных данных и того MAC, о которых стороны договорились в процессе переговоров.

TLS/SSL позволяют договориться об использовании какого-либо алгоритма сжатия данных (как составной части набора шифров). С учётом скорости современных сетей сжатие данных используется всё реже или вообще не используется, и обычно значение выбранного алгоритма сжатия в согласованном наборе шифров устанавливается в NULL (не используется).

TLS/SSL — детальное описание

В данном разделе приводится более подробное описание обмена сообщениями протоколов TLS/SSL (смотрите рисунок 2 выше) для тех, кто любит покопаться во внутренностях. Если Вам удобнее мириться с тем, что «в мире происходит много необычного», лучше пропустите этот раздел, чтобы не рисковать рассудком.

ClientHello (1): Сообщение ClientHello предлагает список поддерживаемых версий/вариантов протоколов, поддерживаемые наборы шифров в порядке предпочтения и список алгоритмов сжатия (обычно NULL). Клиент также посылает случайное значение размером в 32 байта (отметка текущего времени), которое позднее будет использоваться для вычисления симметричного ключа, и идентификатор сессии, который будет равен нулю, если не было предыдущих сессий, либо ненулевому значению, если клиент считает, что предыдущая сессия существует.

Каждый набор шифров состоит из алгоритма обмена ключами, алгоритма шифрования объёмных данных и алгоритма MAC (хэширования).

Набор шифров, используемый и клиентом и сервером, при первоначальном соединении таков:

Это значение говорит о том, что шифрование выполняться не будет и потому все сообщения до Client Key Exchange (ClientKeyMessage) будут отправляться открытым текстом.

Типичный набор шифров:

Каждому набору шифров присвоен свой код. Значение этого кода (два октета) называется Сигнальным значением набора шифров (Signaling Cipher Suite Value, SCSV) — ещё одна фишка для Вашего гик-лексикона.

Корректные значения наборов шифров можно найти в приложениях C RFC по TLS (RFC 2246 для TLS 1, RFC 4346 для TLS 1.1 и RFC 5246 для TLS 1.2). Значения для ECC (шифров на основе эллиптических кривых) приведены в RFC 4492 и RFC 7027.

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

Расширения, определённые в RFC 3546 и в основном используемые в беспроводных сетях, могут быть применены в сообщении ClientHello на манер обеспечения обратной совместимости. RFC 6066 значительно увеличивает количество расширений TLS, многие из которых могут использоваться в обычных (не беспроводных) сетях. Сервер волен молча проигнорировать те расширения, которые он не понимает.

В RFC 6066 представлен тип расширения TLS Certificate Status (status_request), в котором, по существу, сказано: «Я (клиент) абсолютно не доверяю твоему (сервера) сертификату, но я буду абсолютно доверять твоему (сервера) ответу на мой запрос (Certificate Status) о валидности сертификата(!)». Ответ на запрос Certificate Status (обычно получаемый с помощью OCSP) посылается в сообщении CertificateStatus сразу после сообщения Certificate (смотрите ниже). Видимо, запросы Certificate Status (status-request) стали настолько популярны (среди беспроводных устройств?), что есть риск падения OCSP-серверов. В RFC 6961 представлено расширение «certificate_request_v2», снижающее объёмы трафика от сервера TLS серверу OCSP путём разрешения первому из них кэшировать ответы OCSP, а также от сервера TLS клиенту TLS путём разрешения первому из них отправлять всю необходимую информацию, в том числе о промежуточных сертификатах, в одном сообщении CertificateStatus.

В RFC 6066 определено опциональное расширение Server Name Indication (SNI), позволяющее клиенту при установке первоначального соединения TLS/SSL посылать имя сервера, такое как www.example.com. Данная возможность (поддерживаемая большинством современных браузеров) позволяет web-серверу, обслуживающему несколько web-сайтов, (например, Apache с настроенной функцией VirtualHost) отправлять специфичный для сайта сертификат в своём сообщении Certificate (3). Конфигурация Apache 2 для поддержки SNI.

В RFC 7250 определено расширение client_certificate_format, которое может применяться для указания формата используемого сертификата. Это может быть нормальный формат X.509 или формат RawPublicKey, при котором в последующих сообщениях передачи сертификата протокола рукопожатия сертификат сокращается до одного атрибута subjectPublicKeyInfo.

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

TLS/SSL-клиенты могут включать это сообщение в любую попытку переговоров о понижении версии протокола. Старые сервера проигнорируют такое сообщение, и будет нормальным способом устанавливаться соединение с более низкой версией протокола. Новые сервера, распознающие это сообщение, будут прерывать соединение с клиентом и выдавать предупреждение inappropriate_fallback (86), если предлагаемая клиентом версия протокола ниже, чем та, что поддерживается сервером. Таким образом ограничиваются случаи, когда возможно установление соединения с необоснованным снижением версии протокола.

В RFC 7685 определено расширение, которое может быть использовано для дополнения (нулями) размера сообщения ClientHello в целях смягчения эффекта от работы ошибочных реализаций TLS (такого мы не ещё не пробовали).

В RFC 7633 определено новое расширение сертификата X.509, которое включает в себя список расширений TLS, поддерживаемых этим сертификатом. Если сервер не предоставляет указанных расширений TLS, клиент может сделать предположение о потенциальной небезопасности сессии и прервать её. Очевидно, что такое решение клиент должен принять не позднее окончания фазы Certificate рукопожатия TLS.

ServerHello (2): Сообщение ServerHello возвращает выбранные вариант/номер версии протокола, набор шифров и алгоритм сжатия. Сервер посылает случайное значение размером в 32 байта (отметка текущего времени), которое позднее будет использоваться для вычисления симметричных ключей. Если идентификатор сессии в сообщении ClientHello был равен нулю, сервер создаст и вернёт идентификатор сессии. Если в сообщении ClientHello был предложен идентификатор предыдущей сессии, известный данному серверу, то протокол рукопожатия будет проведён по упрощённой схеме. Если клиент предложил неизвестный серверу идентификатор сессии, сервер возвращает новый идентификатор сессии и протокол рукопожатия проводится по полной схеме.

В RFC 7250 определено расширение server_certificate_format, которое может применяться для указания формата используемого сертификата. Это может быть нормальный формат X.509 или формат RawPublicKey, при котором в последующих сообщениях передачи сертификата протокола рукопожатия сертификат сокращается до одного атрибута subjectPublicKeyInfo.

Certificate (3): Сервер посылает свой сертификат X.509, содержащий открытый ключ сервера, алгоритм которого должен совпадать с алгоритмом обмена ключами в выбранном наборе шифров. Протокол предлагает и другие методы доставки открытого ключа, — можно, например, просто указать на запись DNS KEY/TLSA RR, — но сертификат X.509 является стандартным общепринятым методом. Цель данного сообщения — получение клиентом из доверенного источника открытого ключа сервера, который затем может использоваться этим клиентом для отправки зашифрованного сообщения.

Хотя в этом сообщении обычно посылается только один сертификат, можно послать и так называемую связку сертификатов (certificate bundle) — более одного сертификата в PEM-файле. Например, связки сертификатов могут быть определены с помощью директивы Apache SSLCertificateChainFile, тогда как единичный сертификат должен быть определён директивой SSLCertificateFile. Обычно связки используются при наличии кросс-сертификатов, появляющихся в результате некоторой формы реструктуризации сертификата, например, при корпоративном поглощении одной компании другой или изменении ключа/размера ключа удостоверяющего центра (CA).

Протокол DNSSEC DANE (RFC 6698) позволяет клиентам получать копию сертификата X.509 сервера с помощью запроса к системе DNS. Однако, сертификаты, полученные по системе DNS с помощью DANE, являются дополнительными по отношению к тем, которые получены в процессе нормального обмена сертификатами TLS/SSL, и служат скорее для того, чтобы патологические параноики могли провести дополнительную верификацию, а пользы в плане повышения безопасности приносят немного (если вообще приносят).

RFC 7250 определяет упрощённый формат сертификата, в котором открытый ключ в чистом виде инкапсулируется в обёртку, состоящую из атрибута SubjectPublicKeyInfo (необходимого для описания свойств открытого ключа). Это скромный шаг в сторону более разумного способа обретения открытого ключа непосредственно от аутентифицированного источника, такого как защищённая DNS-запись DNSSEC.

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

Примечание: Если во время переговоров об установлении TLS/SSL сервер запросил сертификат клиента, то клиент должен отправить свой сертификат (в том же формате, который определен для сервера, с тем исключением, что RFC 6066 позволяет любому клиенту посылать URL сертификата вместо полного сертификата) непосредственно за сообщением ServerDone и до сообщения ClientKeyExchange.

ClientKeyExchange (5): Клиент вычисляет так называемый ключ pre-master key, используя случайные числа (или отметки текущего времени) сервера и клиента. Он шифрует этот ключ с помощью открытого ключа сервера, полученного из предоставленного сертификата X.509. Только сервер может расшифровать данное сообщение своим закрытым ключом. Обе стороны независимо друг от друга вычисляют общий секретный ключ master key из ключа pre-master, используя определённый в стандарте алгоритм. Любые сеансовые ключи, которые могут потребоваться, будут производными от этого ключа master key.

Как известно, TLS (и DTLS) могут быть уязвимы к атакам типа «человек посередине» (Man-in-The-Middle, MTM). Для устранения этой уязвимости в RFC 7627 был переопределён метод вычисления ключа master secret (изначально определённый в RFC 5246). В новом методе вместо случайных чисел сервера и клиента используется хэш полной сессии от сообщения ClientHello до сообщения ClientKeyExchange. Клиент демонстрирует, что он способен использовать новый (переопределённый) алгоритм вычисления master secret, путём отправки в ClientHello пустого расширения extended_master_secret. Если сервер поддерживает новый алгоритм, он также отправит пустое расширение extended_master_secret в сообщении ServerHello. Если клиент или сервер не поддерживают новый алгоритм (RFC 7627), они, конечно же, могут прервать сессию, либо продолжить её с использованием старого алгоритма (RFC 5246).

ChangeCipherSpec — клиент (6): Это сообщение указывает, что весь последующий трафик, исходящий от данного клиента, будет зашифрован с помощью выбранного (в результате переговоров) алгоритма шифрования объёмных данных и будет содержать MAC, сформированный по выбранному алгоритму. Номинально это сообщение всегда будет шифроваться текущим шифром, который в стадии установления соединения будет NULL, и, следовательно, данное сообщение отображено на диаграмме как отправляемое в открытом виде. Несмотря на то, что это сообщение показано на диаграмме протокола как отправляемое отдельно, часто оно объединяется с сообщением Client Key Exchange.

Finished — клиент (7): Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и хэшируется с помощью алгоритма MAC, о которых договорились стороны. Если сервер может расшифровать и верифицировать это сообщение (содержащее все предыдущие сообщения), используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, на этом месте сервер прерывает сессию и отправляет сообщение Alert с некоторой (возможно, неконкретной) информацией об ошибке.

Примечание: В RFC 7918 указано, что при определённых условиях клиент может начать передачу данных сразу же после отправки данного сообщения для сокращения времени ожидания соединения. Если при обработке последующих сообщений от сервера произойдёт ошибка, то соединение будет разорвано, но данные скомпрометированы не будут.

ChangeCipherSpec — сервер (8): Это сообщение указывает, что весь последующий трафик, исходящий от данного сервера, будет зашифрован с помощью выбранного (в результате переговоров) алгоритма шифрования объёмных данных и будет содержать MAC, сформированный по выбранному алгоритму. Номинально это сообщение всегда будет шифроваться текущим шифром, который в стадии установления соединения будет NULL, и, следовательно, данное сообщение отображено на диаграмме как отправляемое в открытом виде. Получение данного сообщения неявно говорит клиенту о том, что сервер получил и смог обработать сообщение Finished этого клиента.

Finished — сервер (9): Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и включает MAC, о которых договорились стороны. Если клиент может расшифровать это сообщение, используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, клиент прерывает соединение и выдаёт сообщение Alert и подходящий (хотя и не всегда конкретный) код ошибки.

Record Protocol (протокол записи): Последующие сообщения между сервером и клиентом шифруются с помощью алгоритма шифрования объемных данных и включают MAC, о которых договорились стороны.

Случайные значения, посылаемые клиентом и сервером, и последующий секретный ключ pre-master включают в себя значение времени величиной два байта (для предотвращения атак повторения) и потому, как и во всех криптографических системах, и клиент и сервер должны использовать синхронизированный источник времени, такой как NTP.

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

Обзор сертификатов X.509 (SSL)

Оригинальный стандарт ITU-T X.509, в котором сертификаты получили своё несчастливое имя, — один из серии стандартов спецификации каталогов X.500. Использование сертификатов X.509 в Интернет стандартизировано IETF в RFC 5280, определяющем формат сертификата X.509, а также в RFC 4210, определяющем протокол управления сертификатами (Certificate Management Protocol, CMP), который используется для запросов на доступ и обработку сертификатов X.509 (есть также ряд дополнительных протоколов, используемых для обработки и проверки сертификатов). Наконец, в RFC 3739 определяется то, что называется квалифицированным сертификатом (Qualified Certificate), относящимся к Европейской директиве по электронным подписям (директива 1999/93/EC).

Для интересующихся: Стандарты каталога X.500 ITU-T определяли, помимо прочего, протокол DAP (Directory Access Protocol), который предназначался для поддержки злополучного почтового OSI-сервиса X.400. В IETF хотели получить сервис каталогов без всех этих OSI-наворотов и создали протокол LDAP (Lighweight Directory Access Protocol). Так что вся относящаяся к сертификатам X.509 техническая архитектура берёт своё начало из DAP/LDAP.

X.509 открывает совершенно новый и удивительный мир терминологии. В частности, для обозначения полей в сертификате в нём используется термин «отличительное имя» (Distinguished Name, DN). DN определены IETF в серии RFC по LDAP, конкретнее, в RFC 4514 (рус.). Также используются термины «абстрактная нотация синтаксиса 1» (Abstract Syntax Notation 1, ASN.1) и «идентификатор объекта» (Object Identifier, OID), описанные в серии стандартов X.680 ITU. Наконец, при кодировании используются «особые (или уникальные) правила кодирования» (Distinguished Encoding Rules, DER), описанные в X.690 ITU.

Также существует большое количество связанных с управлением сертификатами стандартов, помеченных как PKCS#X (где X — число), например, PKCS#10 определяет формат запроса на подпись сертификата (Certificate Signing Request, CSR). Они относятся к стандартам, определенным RSA Laboratories. Некоторые из этих стандартов были воспроизведены практически без изменений в качестве RFC, например, упомянутый выше PKCS#10 был опубликован как RFC 2986 (обновлён в RFC 5967). В дополнение к стандартам от IETF, RSA и ITU-T, X.509 был стандартизирован в ряде стран, а также некоторыми промышленными организациями. Те, кто следит за этим вопросом, а также те, кто занимается реализацией, обращают внимание на то, что подобная множественность стандартов может привести к серьезным проблемам в реализации и интерпретации. Вот довольно подробный, большой и пугающий набор заметок по реализации X.509 от Peter Gutmann.

Сертификат X.509 выполняет две различные функции:

Сертификат X.509 (в настоящее время X.509v3) служит контейнером для открытого ключа, который может быть использован для проверки или валидации конечного субъекта (end entity, EE), такого как веб-сайт или LDAP-сервер. Этот субъект определён в поле subject сертификата. Субъект в поле subject описывается в форме уникального или отличительного имени (Distinguished Name, DN), — широко используется в LDAP, —  состоящего из ряда относительных уникальных имён (Relative Distinguished Name, RDN), каждое из которых представляет собой содержащий данные элемент, называемый атрибутом (Attribute). В частности, атрибут CN (commonName), образующий RDN уникального имени, обычно содержит описание конечного субъекта, которому выдан сертификат. Примером CN может быть адрес веб-сайта, такой как CN=www.example.com. Полное DN в поле subject может содержать один или более из следующих RDN: CN= (commonName, общепринятое имя, наименование конечного субъекта, например, website или www.example.com), C= (страна), ST= (штат или область в составе страны), L= (местоположение, номинально определяет адрес, но используется в разных целях, за исключением сертификатов EV, где его предназначение строго определено), OU= (organizationalUnitName, название подразделения компании или какая-либо иная подструктура), O= (organizationName, обычно название компании).

Сертификат X.509 подписан цифровой подписью доверенной удостоверяющей организации (обычно называемой удостоверяющим центром (Certificate Authority) или просто CA), уникальное имя (DN) которой указано в поле issuer сертификата. Это делается, во-первых, для того, чтобы убедиться, что данный сертификат не был подделан, а во-вторых, для того, чтобы подтвердить (удостоверить), что данный открытый ключ для субъекта, указанного в поле subject на самом деле является открытым ключом для данного субъекта. Этот процесс доверия мы опишем далее. Подписывающая организация может быть удостоверяющим центром (Certification Authority, CA), регистрационный центром (Registration Authority, RA) или каким-то другим промежуточным центром (таким как подчинённый удостоверяющий центр (subordinate CA)), кроме того сертификат может быть самоподписанным. Примечание: Закрытый ключ, ассоциированный с открытым ключём в сертификате X.509 пользователя, всегда хранится у пользователя и никогда не разглашается подписывающей организации.

Отдельная структура X.509, называемая списком аннулированных (или отозванных) сертификатов (Certificate Revocation List, CRL, в настоящий момент CRLv2) предоставляет информацию о сертификатах, которые по тем или иным причинам были аннулированы или признаны недействительными. По сути, CRL представляют собой старомодный «пакетный» способ работы с аннулированными сертификатами. В них содержатся большие (порой даже очень большие) списки всех сертификатов, которые были отозваны. Если проверяемого (по серийному номеру) сертификата нет в списке CRL, предполагается, что он ещё действителен. У списков CRL есть множество проблем: они могут обновляться только периодически и только УЦ (издателем сертификатов), из-за большого размера CRL браузеры скачивают их (если вообще это делают) неохотно и нерегулярно. Короче говоря, это не очень удобный и эффективный способ. Для проверки текущего статуса конкретного сертификата (опять же, определяемого по серийному номеру) всё чаще и чаще используется онлайн-способ (OCSP), а спецификация SSL-сертификатов EV, вообще требует обязательного использования OCSP.

Большая часть информации в этом разделе сфокусирована на использовании X.509 для валидации коммуникаций сервера. X.509 может также использоваться и для других целей, таких как идентификация пользователей (включая цифровые подписи) и S/MIME, которые мы обязательно рассмотрим, когда (если) голова болеть перестанет.

Типы сертификатов X.509 и терминология

При обсуждении вопросов, связанных с сертификатами X.509 (SSL), используется несметное количество терминов. Иногда они применяются последовательно, но в основном — нет, что только добавляет неразберихи. Даже в RFC, посвящённым сертификатам, нет строго определения терминологии, пожалуй, лучше всего с этим обстоят дела в RFC 4210. Как правило, удостоверяющие центры (УЦ) предлагают несколько типов сертификатов. За исключением сертификатов EV и квалифицированных сертификатов, имеющих точное назначение и определение, все эти типы сертификатов, по большому счёту, — маркетинговая концепция, цель которой — предоставить выбор по цене/функциональности. Поэтому мы ограничимся лишь поверхностным обзором подобных типов сертификатов, в лучшем случае предоставляя немного технической терминологии. Наконец, не все УЦ одинаковы. Хотя большинство УЦ являются нарочито профессиональными организациями, которые регулярно проверяются или сертифицируются теми или иными национальными организациями, это не всегда так (на сайте УЦ ищите ссылки по аттестации, сертификации и аудиту и смотрите, что там). При покупке сертификата необходимо проявлять бдительность!

Далее предпринята попытка определить наиболее часто используемые термины по удостоверяющим центрам и типам сертификатов в свете того, что было сказано в предыдущем параграфе. Предлагаемые пояснения взяты из технической документации (в основном из RFC, особенно RFC 4210), а также с веб-сайтов удостоверяющих центров.

Удостоверяющий центр (УЦ, он же корневой УЦ, англ. Certificate Authority (CA) a.k.a. root CA): термин «удостоверяющий центр» определяется как субъект, подписывающий сертификаты, в которых выполнены следующие условия: поля issuer и subject совпадают, поле KeyUsage установлено в keyCertSign и/или в поле basicConstraints атрибут cA установлен в TRUE. Как правило, в цепочке сертификатов сертификат корневого УЦ является сертификатом самого верхнего уровня, однако RFC 4210 определяет, что корневым УЦ может быть любой издатель (issuer), сертификат которого получен конечным субъектом (например, браузером) в результате доверенного процесса получения. Поскольку окончательное решение о выдаче любого сертификата остаётся за этим УЦ, термины и условия любого промежуточного сертификата могут быть изменены данным субъектом.

Регистрационный центр (РЦ, он же регистрационный УЦ, англ. Registration Authority (RA) a.k.a. Registration CA): Регистрационный центр (RA) может потребоваться в определенных условиях для обработки специфических характеристик сертификата, например, РЦ может быть делегирован Национальным удостоверяющим центром для специализации на персональных сертификатах, а другой РЦ может специализироваться на сертификатах серверов. РЦ, если таковые вообще имеются, являются, по сути, неким средством для административного удобства. РЦ могут подписывать сертификаты (как подчинёные УЦ), но могут также, выполнив соответствующие проверки конечного субъекта, передавать запрос на подписание корневому УЦ.

Подчинённый центр (подчинённый УЦ, англ. Subordinate Authority a.k.a. Subordinate CA): Общий термин. Любой субъект, подписывающий сертификаты, но не являющийся корневым УЦ. Некоторые подчинённые УЦ — особенно те, которые работают под полным контролем владельца корневого УЦ — могут быть помечены как УЦ (будет присутствовать расширение BasicContraints и cA будет установлено в True). То есть, если РЦ подписывает сертификаты, то он делает это как подчинённый УЦ, и если он работает под контролем корневого УЦ, то он также может быть помечен, как УЦ.

Промежуточный центр (промежуточный УЦ, англ. Intermediate Authority a.k.a. Intermediate CA): Неточный термин, иногда используется для определения субъекта, создающего промежуточные сертификаты, и, таким образом, охватывает РЦ и подчинённые УЦ.

Кросс-сертификаты (они же сертификаты сцепления или мостовые сертификаты, англ. Cross certificates a.k.a. Chain or Bridge certificate): Кросс-сертификат представляет собой сертификат, в котором субъекты в полях subject и issuer не совпадают, но оба являются удостоверяющими центрами (присутствует расширение BasicConstraints и поле cA установлено в True). Как правило, такие сертификаты используются, когда УЦ изменил некоторые элементы свой политики издания сертифиткатов (новая дата истечения срока действия ключа или новый ключ), либо когда один УЦ был поглощён другим, и сертификаты, изданные поглощённым УЦ, привязываются к новому владельцу, чтобы можно было отказаться от использования ранее выданных корневых сертификатов. При использовании в данном контексте термин сертификат сцепления указывает на то, что была создана новая привязка, и иногда называется мостовым сертификатом (он привязывается к новому УЦ или выполняет функции моста к нему). Кросс-сертификаты могут быть установлены на сервере (как часть связки сертификатов — смотрите примечание в разделе Протокол TLS, сообщение Certificate), но при использовании для обеспечения обратной совместимости, например, при обработке EV-сертификата несовместимым с EV клиентом, кросс-сертификат устанавливается на клиенте. За исключением того, что поле cA установлено в True (что, откровенно говоря, мало что меняет) кросс-сертификат представляет собой обыкновенный промежуточный сертификат.

Промежуточные сертификаты (они же сертификаты сцепления, англ. Intermediate certificates a.k.a. Chain certificates): Неточный термин, применяемый к любому сертификату, не подписанному корневым УЦ. Промежуточные сертификаты формируют цепочку, в которой на пути от сертификата конечного субъекта до корневого сертификата может быть сколько угодно промежуточных сертификатов. Промежуточные сертификаты могут быть выпущены подчинёнными УЦ, РЦ или даже напрямую корневым УЦ (хотя технически их следует называть кросс-сертификатами) для различных целей: организации перехода, поглощения или даже просто для дифференциации брендов. В данном контексте термин сцепление бессмысленен (хотя звучит умно и помпезно), он просто указывает на то, что сертификат является частью какой-то цепочки.

Связка сертификатов (англ. Certificate Bundle): Общий термин, указывающий на то, что в один файл (обычно в формате PEM) объединены несколько сертификатов X.509. Связки сертификатов могут передаваться во время протокола рукопожатия TLS/SSL. Обычно связки сертификатов используются для административных целей во время некоторых изменений состояния УЦ, например, поглощения, изменения политики, ключа, даты истечения срока действия ключа и т.п.

Квалифицированные сертификаты (англ. Qualified certificates): Определённый в RFC 3739 термин «квалифицированные сертификаты» относится к персональным сертификатам (а не к сертификатам серверов или сертификатам конечного субъекта) и ссылается на Директиву Европейского союза об электронной подписи (1999/93/EC), сфокусированную на единообразном определении индивидуума в целях электронной подписи, авторизации или аутентификации. В частности, данное RFC позволяет содержать в поле subject в порядке очерёдности атрибуты commonName (CN=), givenName (GN=) или pseudonym=, также может присутствовать поле subjectDirectoryAttributes, содержащее какие-либо из атрибутов dateOfBirth=, placeOfBirth=, gender=, countryOfCitizenship= и countryOfResidence=. Наконец, в этом RFC определены два новых расширения biometricInfo и Qualified Certificate statements (qcStatements). Квалифицированный сертификат определяется по наличию расширения qcStatements со значением qcStatement-2. Большинство правительств конкретных стран добавили для включения в такие сертификаты ряд дополнительных полей. В некоторых случаях на то были реальные причины, в других — просто желание продемонстрировать свои амбиции и сделать невыносимой жизнь тех, кто занимается реализацией стандартов сертификатов.

Неквалифицированные сертификаты (англ. non-Qualified certificates): Вообще, так называют персональные сертификаты, не удовлетворяющие требованиям стандарта квалифицированных сертификатов. Издатели квалифицированных сертификатов также употребляют этот термин по отношению к другим сертификатам с намёком на то, что эти сертификаты более низкого качества.

Сертификат конечного субъекта, он же листовой сертификат (англ. End-Entity Certificate a.k.a Leaf Certificate): Тут всё непросто. Термин «конечный субъект» (в английском варианте могут использоваться как end-entity, так и end entity) изначально определяется в X.509, а затем в RFC 4949 и RFC 5280. Во всех случаях смысл в том, что сертификат конечного субъекта — это сертификат, в котором для защиты конечного субъекта, описанного в атрибуте CN= полей subject или subjectAltName, используется закрытый ключ (соответствующий открытому ключу, указанному в сертификате конечного субъекта). С другой стороны, иногда этот термин используется для указания на то, что закрытый ключ (соответствующий открытому ключу, указанному в сертификате конечного субъекта) не используется для подписи сертификатов, то есть, сертификат конечного субъекта не является промежуточным сертификатом, как правило, не является корневым (CA) сертификатом, и, следовательно, не используется в каком-либо процессе проверки подписи. Термин «листовой сертификат» используется для указания на то, что сертификат конечного субъекта, как правило, является последним сертификатом в цепочке. Сами решайте, помогают подобные термины понимать происходящее, или только мешают этому.

Мультихостовые сертификаты (англ. Multi-host certificates): Сертификат сервера обычно в поле subject содержит атрибут CN=hostname, например, CN=www.example.com. Имя хоста разрешается системой DNS, которая может выдавать для этого хоста несколько IP-адресов (если в DNS имеется несколько записей A или AAAA). В этом случае серверный сертификат X.509 (SSL) с одним и тем же именем хоста может быть реплицирован на все подобные хосты (очевидно, соответствующий закрытый ключ также должен быть реплицирован на каждый хост, что может представлять собой проблему при использовании аппаратных криптографических устройств, в этом случае некоторые УЦ с удовольствием продадут Вам дополнительные сертификаты (которые будут называться мультихостовыми) чтобы обойти эту проблему). Если же присутствует несколько имён хостов, таких как www.example.com, example.com или www1.example.com, в таком случае требуется специальных подход и специальные типы сертификатов, описанные ниже как мультидоменные сертификаты и сертификаты с возможностью подстановки.

Мультидоменные сертификаты (англ. Multi-domain certificates): Некоторые УЦ продают мультидоменные сертификаты, охватывающие несколько доменных имён, например, таких как www.example.com, example.com или даже www.example.net. Это достигается путём использования нескольких записей в поле subjectAltName и описывается далее. С технической точки зрения на этот процесс практически нет ограничений, например, в одном сертификате X.509 (SSL) могут поддерживаться www.example.com и www.example.net, но у большинства УЦ предусмотрены на это какие-либо коммерческие ограничения, которые, впрочем, обычно можно преодолеть путём дополнительных капиталовложений. Иногда для этих целей можно использовать описанные ниже сертификаты с возможностью подстановки, но имена хостов в таких сертификатах ограничены одним доменом.

Сертификаты с возможностью подстановки (англ. Wildcard certificates): Некоторые УЦ продают сертификаты с возможностью подстановки, в которых поле subject содержит CN=*.example.com (* — это шаблон подстановки). Такие сертификаты поддерживают любое имя хоста в составе домена, то есть *.example.com будет поддерживать www.example.com и mail.example.com, но не example.com и, очевидно, не example.net (для этих целей могут подойти описанные выше мультидоменные сертификаты).

Сертификаты EV (сертификаты расширенной валидации они же расширенные сертификаты, англ. EV (Extended Validation) Certificates a.k.a. Extended Certificates): Сертификаты EV отличаются наличием расширения CertificatePolicies, содержащего зарегистрированные OID в поле policyIdentifier. Подробнее сертификаты EV описаны ниже.

Сертификаты DV (сертификаты валидации домена, англ. DV (Domain Validation) Certificates): Некоторые УЦ выпускают то, что называется сертификатами валидации домена (DV). Этот термин не используется повсеместно. Подразумевается, что удостоверяющий центр подтверждает только тот факт, что лицо или организация, запросившая данный сертификат, является владельцем доменного имени. То есть значение CN= в полях subject или subjectAltName, например, www.example.com, может рассматриваться как верное, а вот информация об организации (C=, ST=, L=, OU= или O=) не должна рассматриваться как верная, и эти значения должны быть либо пустыми, либо содержать соответствующий текст, например, «not valid» («неверно»).

Сертификаты OV (сертификаты валидации организации, англ. OV (Organizational Validation) Certificates): Некоторые УЦ выпускают то, что называется сертификатами валидации организации (OV). Этот термин не используется повсеместно. Подразумевается, что удостоверяющий центр подтверждает тот факт, что лицо или организация, запросившая данный сертификат, является владельцем доменного имени, а также подтверждает предоставленные в сертификате сведения об организации. То есть значения CN=, C=, ST=, L=, OU= или O= в полях subject или subjectAltName могут рассматриваться как верные. Хотя на первый взгляд это выглядит весьма основательно, всё же такие сертификаты не дотягивают до уровня сертификатов EV, требующих дополнительных условий квалификации.

Внутридоменные сертификаты (англ. Domain-Only Certificates): Общий термин, обычно несёт негативную окраску, применяется к сертификатам, в которых процесс верификации конечного пользователя, с точки зрения тех, кто применяет данный термин, варьируется от поверхностного до вообще никакого.

Сертификаты защиты контента при цифровой передаче (Digital Transmission Content Protection, DTCP): Такие сертификаты выпускаются и управляются Администратором лицензирования цифровой передачи (Digital Transmission Licencing Administrator, DTLA — www.dtcp.com) и обычно используются Smart-телевизорами, медиа-плеерами и прочими подобными устройствами при проигрывании на них лицензионных материалов. Сертификаты DTCP не используют формат X.509, но они могут быть задействованы в протоколе рукопожатия TLS (RFC 7562). Далее в этом документе они не описываются.

Цепочки сертификатов X.509

Сертификаты X.509 могут формировать цепочки, то есть они могут быть подписаны одним или более промежуточными удостоверяющими центрами в иерархической манере, либо сертификат может быть просто подписан корневым УЦ напрямую. Концепция регистрационных центров (РЦ), выступающих в роли промежуточных подписывающих удостоверяющих центров, представлена в упомянутых выше RFC. Понятие «регистрационный центр (РЦ)» (иногда в стандартах EV именуемый «подчинённым УЦ»), вводится для описания организации, у которой на самом деле был приобретён сертификат X.509, например, лицензированного агента, сертификат которого подписан (возможно, также в результате иерархической цепочки подписания) удостоверяющим центром, представляющим собой УЦ самого верхнего уровня или корневой УЦ. По структуре чем-то похоже на операторов реестра DNS и регистраторов, если организация DNS Вам знакома. В RFC 4158 есть полезная, но крайне запутанная и неудобоваримая информация о том, как можно надёжно построить цепочку сертификатов с помощью пар полей subject и issuer, дополняя их, кроме всего прочего, полями SubjectKeyIdentifier и AuthorityKeyIdentifier.

Сертификат самого верхнего уровня в иерархии подписания называется корневым сертификатом, сертификатом УЦ или даже иногда корневым сертификатом УЦ. Корневые сертификаты получаются каким-либо доверенным способом (в случае браузеров они распространяются с программным обеспечением браузера и периодически обновляются) и при валидации цепочки сертификатов обычно называются якорями доверия. При получении от сервера в процессе рукопожатия TLS/SSL сертификата (или связки сертификатов) конечного субъекта, программа, получившая сертификат, должна проверить его и весь путь до корневого сертификата (сертификата УЦ), включая, при необходимости, все промежуточные сертификаты (которые, опять же, обычно распространяются с программным обеспечением браузера). Корневой сертификат (сертификат УЦ) распознаётся по наличию одинаковых значений в полях issuer и subject, по тому, что поле KeyUsage установлено в keyCertSign и/или в поле BasicConstraints атрибут cA установлен в TRUE. Процесс построения цепочки сертификатов описан в RFC 4158, валидация цепочки сертификатов описана в RFC 5280. Различные варианты подписания сертификатов показаны на рисунке 3:

Рисунок 3 — Цепочки сертификатов X.509

Использование сертификатов X.509

Издатель сертификата (issuer) идентифицируется с использованием формата Distinguished Name (DN, уникального имени), который в оригинале разрабатывался для представления расположения объекта в DIT (информационном дереве каталога) DAP или LDAP. DN не следует путать с сетевым адресом или URL/URI. Обычно DN имеет формат CN=Type of Certificate, OU=Certificate Division, O=Certificate Company name,C=Country (CN=, OU=, O=, C=), но может иметь и более простой формат OU=, O=, C=, или даже CN=, O=, C=, наконец (чтобы немного запутать ситуацию) он может иметь формат CN=, OU=, DC=, DC=. В общем, формат может быть разным — вариантов много. DN состоит из нескольких разделённых запятыми RDN (Relative Distinguished Names, относительных уникальных имён), то есть CN= или C= представляют собой RDN в составе DN. Сертификат X.509 не содержит URI для получения по сети каких либо сертификатов для образования цепочки, но он может содержать (в других полях) URI для получения CRL. Использующие сертификаты приложения, — к примеру, браузеры или почтовые клиенты, — должны заранее получить корневой сертификат, а если существует цепочка сертификатов, то и все промежуточные сертификаты, каким-либо способом, по сети или нет. Корневые сертификаты наиболее известных УЦ распространяются с браузерами (и доступны для соответствующих им почтовых клиентов), смотрите раздел «Работа с сертификатами в основных браузерах».

Примечание: Распространяемые с программным обеспечением большинства браузеров (и почтовых клиентов) корневые сертификаты добавляются в соответствии с критериями, определяемыми поставщиком браузера, и варьирующимися от «кто больше заплатит» до тотальной проверки легитимности УЦ и соответствия их другим требованиям.

При обращении приложения к сервису с поддержкой TLS/SSL, в процессе диалога рукопожатия TLS/SSL оно получает сертификат (или связку сертификатов) сервера. После этого приложение (например, браузер) выделит атрибут CN из DN в поле subject (и/или в поле subjectAltName, смотрите RFC 6125) для проверки субъекта (скажем, адреса веб-сервера, такого как www.example.com). Затем наше приложение будет использовать DN в поле issuer сертификата X.509 сервера для нахождения соответствующего корневого сертификата в своём локальном хранилище (и, если такового не обнаружено, генерации исключения — обычно в виде непонятного, пугающего пользователя диалога). Если найден валидный корневой сертификат, то тем самым подлинность предоставленного сервером сертификата считается установленной. В итоге (если всё прошло успешно) открытый ключ, содержащийся в сертификате X.509, считается безопасным (доверенным) и пригодным для проведения коммуникаций с указанным в поле subject субъектом.

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

Рисунок 4 — Использование сертификатов X.509

Сертификаты X.509 в организациях, предоставляющих услуги веб-хостинга

Владельцы веб-сайтов подвергаются значительному давлению по поводу внедрения шифрования на основе сертификатов X.509 (SSL). Источники этого давления обычно имеют благие намерения (но это не говорит о том, что они правы).

Когда владелец веб-сайта одновременно является и его оператором, такое внедрение не создаёт больших проблем. Владелец/оператор сайта просто должен определиться, является ли внедрение TLS экономически эффективным. С другой стороны, многие владельцы сайтов делегируют функции оператора сайта специалистам веб-хостинговых компаний (так называемые многопользовательские сайты). И тут может возникнуть более серьёзная проблема.

Так в чём же дело?

Проблема связана с выдачей сертификатов X.509, а также с владением закрытыми ключами, ассоциированными с этим сертификатом X.509. В частности, имеет место одна единственная (в большинстве случаев) транзакция (пункт 5 в последовательности обмена сообщениями протокола TLS), в которой требуется, чтобы у сервера был доступ к закрытому ключу соответствующего сертификата (напомним, что в асимметричной криптографии (с открытым и закрытым ключами) клиент шифрует сообщение с использованием открытого ключа, и только владелец закрытого ключа, — в данном случае сервер, — может расшифровать это сообщение).

Теперь представьте, что собственник example.com делегировал обслуживание веб-сайта с этим доменным именем веб-хостинговой организации, имеющей доменное имя example.net. Если браузер пользователя соединяется с TLS-сервисом на www.example.com, то он ожидает увидеть сертификат с именем www.example.com (то есть с именем того сайта, к которому он подключается). Если же он получит сертификат с именем www.example.net (доменное имя хостинговой организации), то будет немного расстроен (на самом деле он либо начнёт злорадно выдавать пользователю неприятные сообщения, либо подкрасит адресную строку угрожающим красным цветом).

Чтобы проблема не была такой острой, в RFC 6066 была введена SNI (Server Name Indication, индикация имени сервера), позволяющая клиенту (браузеру) явно указать в сообщении ServerHello, что он подключается к www.example.com, давая возможность нашему супер-умному серверу предоставлять ожидаемый сертификат (www.example.com). Победа! Браузер снова счастлив, ура!

Ни один нормальный удостоверяющий центр (CA) не выдаст сертификат для example.com какому-то там example.net. Только владелец домена (который должен тем или иным способом доказать своё право собственности) может получить сертификат на свой домен. Однако, как мы помним из пункта 5 последовательности обмена сообщениями протокола TLS, серверный хост должен иметь у себя не только сертификат, но и ассоциированный с ним закрытый ключ. Ой! Юристы уже радостно потирают руки! Ой-ой-ой!

В RFC 7711 предлагается решение, при котором пользователь (example.com) может (используя ресурсные записи DNS SRV) явно делегировать предоставление SSL-сертификата третьей стороны (в нашем случае example.net) для проверки подлинности своего сайта, путём указания на расположенную где-то на веб-хосте специально сформированную запись в формате JSON. Пользователю не нужно покупать безумно дорогой SSL-сертификат и, следовательно, не нужно предоставлять свой закрытый ключ хостинг-провайдеру. В теории, перед посещением веб-сайта пользователя наш браузер будет выполнять запрос DNS SRV, а затем, используя полученный URL, прочтёт запись делегирования (предположим, по логике нашего примера, в этой записи указано, что полномочия делегированы example.net). При получении этой информации, браузер с радостью примет сертификат от example.net при доступе к example.com. Наш браузер доволен, никаких неприятных сообщений и угрожающих цветов. Все счастливы, кроме, пожалуй, юристов.

Примечание: В этом же RFC опционально пользователю разрешается указать, что он намеренно предоставил своему хостинг-провайдеру свой сертификат X.509 (и, неявно, свой закрытый ключ).

У этой проблемы существует и другое возможное решение с использованием DNSSEC и DANE, когда-нибудь мы его тоже обязательно задокументируем. Только не надейтесь, что это будет скоро.

Протоколы, связанные с сертификатами (CMP, CMC/CMS, CRMF, SCVP, OCSP, HTTP)

Сертификат X.509 представляет собой структуру данных. Различные протоколы позволяют производить манипуляции с сертификатами через коммуникационную сеть. Такие операции с сертификатами X.509, как отправка запроса на подписание, получение подписанного сертификата и другие, определены, в частности, в протоколе управления сертификатами (Certificate Management Protocol, CMP, RFC 4210) и в PKCS #10 (RFC 2986), и описаны далее в этом руководстве.

Беглый обзор: Для манипуляций с сертификатами и списками отзыва сертификатов (Certificate Revocation Lists, CRL) определен ряд протоколов. Протокол управления сертификатами (Certificate Management Protocol, CMP, RFC 4210, обновлён в RFC 6712) предоставляет методы для манипуляции сертификатами (формат сообщений сертификатов (Certificate Request Message Format, CRMF) определён в RFC 4211). В RFC 4210 определено несколько коммуникационных методов (таких как HTTPS), которые могут быть использованы для транспортировки запросов сертификата по сети, но не дано явного определения транспортного протокола для обработки сертификатов (смотрите CMC/CMS ниже).

Протокол CMC/CMS (Certificate Management over CMS, управление сертификатами поверх CMS), определён в RFC 5272, RFC 5273, RFC 5274 и обновлён в RFC 6402, позволяет осуществлять безопасную транспортировку запросов сертификата от запрашивающей стороны к УЦ (включая любые промежуточные РЦ) и обратно. Формат сообщения может быть либо PKCS #10 (RFC 2896), либо CMRF (RFC 4211). Этот протокол следует называть CMC, но иногда его называют CMS. Технически, CMS — это Cryptographic Message Syntax (синтаксис криптографического сообщения), в котором описывается только формат конверта запроса и ответа (для PKCS #10 или CRMF). Данный протокол определяет ряд операций, которые могут быть выполнены над сертификатами, в том числе обновление якорей доверия (корневых сертификатов), поддерживаемых у запрашивающей сертификат стороны. Это большой и насыщенный (сложный) протокол.

Протокол онлайн-получения статуса сертификата (Online Certificate Status Protocol, OCSP, RFC 6960) — это протокол для онлайн-проверки подлинности сертификатов. RFC 6066 расширяет стандарт TLS чтобы клиент мог запрашивать OCSP-статус сертификата во время фазы протокола рукопожатия, а RFC 6961 определяет упрощённый формат ‘certificate_request_v2’, позволяющий снизить объёмы трафика сервера OCSP.

Протокол серверной валидации сертификатов (Server-Based Certificate Validation Protocol, SCVP, RFC 5055) позволяет делегировать недоверенному серверу некоторые клиентские функции, а именно построение и валидацию пути сертификации. Если же сервер SCVP является ещё и доверенным, то он может предоставлять дополнительную функциональность, например, проверку статуса сертификата (как OCSP) или получение промежуточных сертификатов (как CMP).

В RFC 4387 определены некоторые ограниченные манипуляции с сертификатами X.509, ключами и списками CRL по протоколу HTTP с использованием метода GET (как раз этот метод мы использовали, когда последний раз покупали сертификат X.509). RFC 4386 определяет использование DNS-записей SRV для обнаружения репозиториев сертификатов и сервисов OCSP.

Протокол управления сертификатами (Certificate Management Protocol, CMP)

Протокол управления сертификатами (CMP) определён в RFC 4210 (обновлён в RFC 6712), формат сообщений запроса сертификатов (Certificate Request Message Format, CRMF) определён в RFC 4211.

В дальнейшем описание будет расширено.

Протокол серверной валидации сертификатов (Server-Based Certificate Validation Protocol, SCVP)

В дальнейшем будет приведено описание. Варианты OCSP в значительной степени заменяют этот протокол.

Управление сертификатами поверх CMS (Certificate Management over CMS, CMC/CMS)

В дальнейшем будет приведено описание.

Протокол онлайн-получения статуса сертификата (Online Certificate Status Protocol, OCSP)

Протокол онлайн-получения статуса сертификата (OCSP) определён в RFC 6960, а переработанный, обеспечивающий высокую производительность формат сообщений определён в RFC 5019 (The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments (облегчённый профиль OCSP для крупномасштабных сред)). В этом формате существенно уменьшен размер OCSP-запросов для одного сертификата и исключено большинство необязательных (OPTIONAL) полей в запросах и ответах (смотрите примечание ниже). RFC 6960 (отменяющий действие RFC 2560 и RFC 6277) просто уточняет некоторые моменты в оригинальных RFC для достижения большей совместимости с RFC 5019, а также добавляет свои собственные, совершенно новые туманные места в спецификацию. В RFC 6961 определён новый формат ‘certificate_request_v2’, позволяющий серверам кэшировать (сохранять) ответы, а также позволяющий посылать в одном сообщении информацию о всех имеющих отношение к запросу сертификатах (включая промежуточные).

OCSP — это онлайн альтернатива спискам отзыва сертификатов (Certificate Revokation List, CRL). Если удостоверяющий центр поддерживает сервис OCSP, URI этого сервиса обычно указывается в поле AuthorityInfoAccess (AIA) сертификата (удостоверяющие центры, выпускающие сертификаты EV, обязаны поддерживать OSCP). Клиент отправляет запрос, опционально подписанный электронной подписью, идентифицирующий сертификат, который требуется проверить, и получает от сервера OCSP подписанный ответ, указывающий статус сертификата как действующий (good), отозванный (revoked) или неизвестный (unknown). В RFC разрешено передавать запросы и ответы посредством ряда различных транспортных протоколов (в частности, в качестве примеров упомянуты LDAP, SMTP и HTTP) с указанием конкретной транспортной схемы в URI поля AIA сертификата, подвергающегося проверке. Также RFC определяет формат сообщений HTTP (используются GET и POST) при транспортировке OCSP. Формат сообщений запроса и ответа:

Подпись запроса OCSP является необязательной, и, если она присутствует, в поле requestorName должен быть указан субъект, подписавший сообщение. Очевидно, для проверки подписи у получателя сообщения должен быть открытый ключ субъекта, подписавшего сообщение (или его делегированного агента).

Поставщики сертификатов EV (Extended Validation) обязаны предоставлять сервис OCSP, для всех остальных типов сертификатов этот сервис является опциональным.

Статус good в поле certStatus согласно RFC означает «не отозван», но в полях расширения (Extensions) может быть доступна дополнительная информация.

Статус unauthorized в поле responseStatus указывает на то, что сервер, выдающий ответ, не имеет достоверной информации по этому сертификату.

В RFC 6960 определено несколько расширений для сообщений, кроме того, в них можно включать любые расширения CRL (RFC 2459).

Обычно ответ подписывается УЦ, издавшим сертификат, указанный в поле serialNumber, но протокол позволяет подписывать ответ делегированному удостоверяющему центру. В этом случае ответ должен включать сертификат (содержащий открытый ключ делегированного центра, подписавшего ответ) в поле certs, и этот сертификат должен быть подписан издателем сертификата, указанного в поле serialNumber.

RFC 5019 определяет усовершенствованный формат сообщений (полностью совместимый с полным форматом OCSP) путём исключения большинства необязательных (OPTIONAL) полей с целью снижения нагрузки на сеть при передаче сообщений. Нововведения в протоколе: поддержка OCSP поверх HTTP только с использованием методов GET и POST. Нововведения в запросах: запрос ограничивается единственным сертификатом (значение поля requestList будет 1), обходится без необязательного поля singleRequestExtensions, необязательных структур requestExtensions и optionalSignature (если запрос подписан, отвечающий сервер вправе проигнорировать подпись). Нововведения в ответах: путём принудительного ограничения на один сертификат в запросе, RFC 5019 уже уменьшает сложность (и размер) ответа, кроме того, исключено необязательное поле responseExtensions (но поле singleResponseExtensions может быть включено). Опять же, если ответ подписан делегированным УЦ, он должен включать сертификат (содержащий открытый ключ делегированного центра, подписавшего ответ) в поле certs, и этот сертификат должен быть подписан издателем сертификата, указанного в поле serialNumber.

Узкие места OCSP

OCSP разрабатывался как система реального времени (в противоположность пакетной природе классических списков CRL), так что теоретически клиенты могут проверить статус любого сертификата до его принятия и использования. В частности, при обработке сертификата EV любая реализация клиента (например, браузер) в буквальном смысле обязана выполнить OCSP-проверку чтобы реализовать концепцию безопасности EV. Это означает, к примеру, что в результате каждого обращения к сервису HTTPS может (а в случае EV должна) происходить дополнительная проверка УЦ посредством обращения к сервису OCSP. Поскольку всё больше сайтов реализуют благонамеренную, но, по существу, ошибочную политику использования HTTPS для всего подряд (вместо того, чтобы настроить более значимый и надёжный сервис DNSSEC), производительность серверов OCSP резко снижается и они просто встают на колени от своего рода DDoS-атаки (хоть и из благих побуждений).

RFC 6066 расширяет стандарт TLS, чтобы клиент мог запрашивать статус сертификата у сервера TLS (OCSPStatusRequest), тем самым, возможно, ещё более усугубляя проблему загрузки OCSP, упростив реализацию опроса OCSP и поощряя каждого клиента его выполнять. В RFC 6961 предпринята попытка решить проблему загрузки OCSP путём использования нового запроса TLS ‘certificate_request_v2’, который, предположительно, позволяет (хотя при опросе OCSP сервер не обязательно должен придерживаться такого поведения) кэшировать ответы OCSP на сервере (снижая тем самым загрузку OCSP из-за проверок достоверности в режиме реального времени) и посылать несколько сообщений о статусе сертификатов (включая все промежуточные сертификаты) в одном блоке. И наконец (мы на это надеемся, что это будет конец), поскольку многочисленные промежуточные сертификаты могут в сумме иметь серьёзный размер, в RFC 7924 определён метод, с помощью которого клиент может сообщить серверу, что у него уже есть все необходимые для проверки промежуточные сертификаты.

Формат сертификата X.509

В этом разделе в умопомрачительных (но не всеобъемлющих) подробностях описывается формат и назначение основных полей (технически называемых атрибутами) сертификата X.509. Этот формат определён в RFC 5280 (обновлён в RFC 6818).

Сертификат X.509 представляет собой структуру ASN.1, закодированную с помощью определённых в X.690 уникальных правил кодирования (Distinguished Encoding Rules, DER), и включающую в себя многочисленные ссылки на глобально уникальные идентификаторы объектов (Object Identifiers, OID).

В X.509 (и LDAP) многие используют бестолковую псевдоВенгерскую нотацию (или lowerCamelCase, если Вы предпочитаете этот термин). В общем случае стоит помнить, что плохие реализации X.509 чувствительны к регистру символов, хорошие — нет. Более того, все правила соответствия LDAP, относящиеся к манипулированию DN, являются нечувствительными к регистру; это означает, что имена атрибутов нечувствительны к регистру.

RFC 7250 определяет упрощённый формат сертификата для случаев, когда открытый ключ был получен в результате других доверенных процессов (возможно, офф-лайн). Этот минимальный формат сертификата использует только атрибут subjectPublicKeyInfo (и два его подполя). О том, что будет применяться данный минимальный формат сертификата, указывается в сообщениях ClientHello и ServerHello в ходе рукопожатия TLS/SSL.

Выводимый OpenSSL сертификат X.509 выглядит так (основные поля описаны ниже):

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

Сертификат X.509 состоит из следующих полей (атрибутов):

Однако некоторые сертификаты используют DN из поля issuer и заменяют атрибут CN (RDN) именем аутентифицируемого субъекта. Исходя из такой логики, DN субъекта, сформированный на основании DN поля issuer из примера выше, будет выглядеть так:

В приведённом примере CN=www.example.com будет срабатывать, если при доступе к веб-сайту используется URL http://www.example.com. Если же для доступа к этому сайту также используется http://example.com, процесс проверки сертификата завершится неудачей. В этом случае можно использовать поле subjectAltName для расширения сферы действия сертификата, чтобы включить example.com (или любые другие доменные имена, на которые распространяется действие этого сертификата).

Хотя большинство сертификатов в настоящее время (2011 год) используют для описания субъекта RDN CN= поля subject, RFC 6125 рекомендует использовать поле subjectAltName, содержащее наименование конечного субъекта, и чтобы при валидации наименования субъекта значение поля subjectAltName имело бы приоритет перед значением атрибута CN= в поле subject. Возможно, через некоторое время все приложения и издатели сертификатов будут придерживаться этих принципов, и потому, для обработки всех возможных вариантов, наименование субъекта следует помещать и в значение атрибута CN= поля subject, и в поле subjectAltName.

Поле subject может быть пустым, в этом случае субъект, который будет аутентифицирован, определяется в поле subjectAltName.

Форма CN=www.example.com/emailAddress=me@example.com встречается часто и обычно создаётся по умолчанию инструментами OpenSSL при генерации запроса на подписание сертификата (Certificate Signing Request, CSR). В этой форме определяется второй атрибут emailAddress, который может присутствовать или не присутствовать. Большинство удостоверяющих центров требуют, чтобы строка с указанием адреса электронной почты оставалась пустой при создании CSR с помощью OpenSSL, возможно затем, чтобы продать Вам ещё один сертификат для защиты адресов электронной почты. Или это кажется Вам слишком циничным? Замечания по полям сертификата subject и subjectAltName.

Великое множество расширений определено в различных RFC, далее представлены только самые значимые (по нашему скромному мнению). Расширения могут быть помечены как критичные (CRITICAL). Примечание: Пометка CRITICAL имеет интересную и тонкую интерпретацию. Если обрабатывающее сертификат программное обеспечение видит значение с пометкой CRITICAL (которую оно всегда может интерпретировать), но не может распознать данное расширение, оно ДОЛЖНО отказаться от обработки и НЕ принимать этот сертификат.

В RFC 5280 даны определения стандартных расширений (OID которых начинается на 2.5.29, определёны в оригинальных стандартах X.509), а также так называемых «частных расширений» (Private Extensions) (OID которых начинается на 1.3.6.1.5.5.7.1). Распределение номеров для расширений из пространства OID Private Internet поддерживается IANA. Приведённые ниже расширения, если это не оговаривается отдельно, являются стандартными (OID из пространства 2.5.29).

В RFC 7633 определено расширение сертификата X.509 из пространства Private Internet (OID 1.3.6.1.5.5.7.1.24 id-pe-tlsfeature), позволяющее включать в сертификат расширения функционала TLS (идентифицирующиеся по значениям TLS-кодов). По сути, такие расширения могут позволить клиенту выявить потенциально мошеннический сервер. Так, если сертификат содержит расширение функционала TLS status_request, а сервер не возвращает информации о статусе (в сообщении CertificateStatus), то клиент может сделать вывод о потенциальной небезопасности сессии.

Разрешается присутствие нескольких записей. Использование subjectAltName — путь решения проблемы нескольких имён DNS у одного сервера. Например, если доступ к серверу осуществляется с использованием https://www.example.com и https://example.com, то www.example.com может присутствовать в атрибуте CN= поля subject, а example.com может присутствовать в поле dNSName этого расширения, или, чаще, оба имени www.example.com и example.com будут присутствовать в записях dNSName. Примечание: в этих полях могут быть любые доменные имена, например, сразу и www.example.com, и www.example.net. Требование общего корня доменного имени не выдвигается. Не все удостоверяющие центры поддерживают использование subjectAltName. Генерация записей subjectAltName в самоподписанных сертификатах средствами OpenSSL — несколько грубоватый процесс, мы подробно описали его ниже. Замечания по полям сертификата subject и subjectAltName.

Все поля, за исключением SignatureAlgorithm и SignatureValue закодированы с помощью правил кодирования ASN.1 DER (Distinguished Encoding Rules), определённых в стандарте X.690 ITU-T. Цифровая подпись охватывает все закодированные DER поля, кроме, очевидно, самой себя.

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

Замечания по полям сертификата subject и subjectAltName

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

Проверка доменного имени по сертификатам X.509

В RFC 6125 определяется набор правил, цель которых — уменьшить путаницу между клиентами, серверами и УЦ, выдающими сертификаты, по вопросу того, как следует описывать или как могут быть описаны конечные субъекты в атрибутах subject и subjectAltName. (В RFC 6186 описан способ обнаружения хоста электронной почты с помощью ресурсных записей SRV DNS, а в RFC 7817 разъясняются требования RFC 6125 в отношении протоколов, связанных с электронной почтой). Исторически конечные субъекты определялись в RDN CN= атрибута subject, и хотя это до сих пор поддерживается (в основном по историческим соображениям), в RFC 6125 предпочтительным названо использование атрибута subjectAltName, позволяющего обеспечить большую гибкость и ясность. RFC 6125 определяет четыре возможности для проверки конечной системы:

Примечание: Во всех случаях при использовании subjectAltName может присутствовать более одного типа имени. Кроме того, может быть определено более одного субъекта для каждого типа имени. Конечные субъекты, описанные во всех присутствующих типах, образуют совокупность конечных субъектов данного сертификата. В случае использования поля subject действие сертификата распространяется только на одного конечного субъекта, описанного в RDN CN= (хотя в этом случае также может присутствовать атрибут subjectAltName).

В поле subjectAltName содержится атрибут типа dNSName. В этом случае указанное имя представляет собой имя конечного субъекта, на которого распространяется действие данного сертификата.

В RFC 7817 сказано, что для электронной почты в качестве конечного субъекта следует указывать либо доменную часть адреса электронной почты (RFC822), к примеру, для адреса user@example.com конечным субъектом будет example.com, и/или в качестве конечного субъекта может быть указано FQDN хоста, получающего электронную почту, например, mail.example.com.

В поле subject содержится едиственное значение атрибута CN, например, cn=hostname (могут также присутствовать другие RDN, но при проверке доменного имени они игнорируются). В этом случае hostname представляет собой имя конечного субъекта, на которого распространяется действие данного сертификата.

В RFC 7817 сказано, что для электронной почты в качестве конечного субъекта следует указывать либо доменную часть адреса электронной почты (RFC822), к примеру, для адреса user@example.com конечным субъектом будет example.com, и/или в качестве конечного субъекта может быть указано FQDN хоста, получающего электронную почту, например, mail.example.com.

В поле subjectAltName содержится атрибут типа otherName, а значение type самого атрибута otherName установлено в SRV (oid = 1.3.6.1.5.5.7.8.7) (определено в RFC 4985).

В RFC 6186 определён порядок использования ресурсных записей DNS SRV для нахождения сервисов, связанных с электронной почтой (формат довольно странный). Эти рекомендации используются в RFC 7817.

В поле subjectaltName содержится атрибут типа uniformResourceIdentifier. В этом случае тип сервиса определяется явно.

Списки отзыва сертификатов (Certificate Revocation Lists, CRL)

Списки отзыва сертификатов (CRL) — метод, с помощью которого сертификаты могут быть признаны недействительными до наступления даты, указанной в поле NotAfter сертификата. Обычно CRL выпускаются тем же УЦ, который выпустил и сам сертификат. CRL могут быть получены различными методами, например, посредством LDAP, HTTP или FTP. Формат CRL (в частности CRLv2, текущая версия) определён в RFC 5280, а затем обновлён в RFC 6818.

Теоретически, при получении сертификата от сервера, программное обеспечение, получившее сертификат, должно проверить, что этот сертификат отсутствует в CRL (не был отозван). Чтобы свести к минимуму возможность ошибочного приёма отозванного сертификата, каждый раз при получении сертификата от сервера должна быть получена последняя версия CRL. Поскольку CRL содержит список всех отозванных сертификатов какого-либо УЦ, он может быть внушительных размеров и создавать, таким образом, неприемлемую избыточность трафика при первоначальном соединении TLS/SSL. Кроме того, в зависимости от политики удостоверяющего центра, CRL могут обновляться каждый час, 12 часов, раз день и т.д. Суть в том, что полученные файлы CRL, даже если мы запрашиваем их снова и снова при каждом получении сертификата, всё равно могут содержать просроченные данные.

На практике получение CRL каждый раз при проверке сертификата выполняется довольно редко (если вообще выполняется), многие системы полагаются на кэши CRL, которые периодически обновляются. В RFC 5280 для описания частоты обновления CRL используется обтекаемый термин suitably-recent (достаточно свежие) . Онлайн версия списков отзыва, известная как Online Certificate Status Protocol (OCSP), определена в RFC 2560, переработана в RFC 5019 и обновлена в RFC 6277. Формат CRL:

Version	Необязательное поле. В общем случае это поле будет указывать на версию 2 (CRLv2). Поскольку нумерация начинается с нуля, значение этого поля будет 1. Если поле опущено, подразумевается версия 2 (значение 1).
Signature	Значением данного поля должен быть тот же OID, что указан в поле SignatureAlgorithm ниже.
Issuer	DN удостоверяющего центра, подписавшего и, следовательно, издавшего данный CRL. Это может быть корневой или некорневой удостоверяющий центр. Смотрите также описание поля issuer сертификата.
ThisUpdate	Время и дата создания CRL. Формат даты может быть UTCTime (YYMMDDHHMMSSZ) или GeneralizedTime (YYYYMMDDHHMMSSZ). Z в формате представления времени — символьная константа, указывающая на смещение относительно часового пояса Zulu Time (UTC, он же время по Гринвичу (GMT)), при её отсутствии подразумевается локальное время.
NextUpdate	Время и дата создания следующего CRL. Формат даты может быть UTCTime (YYMMDDHHMMSSZ) или GeneralizedTime (YYYYMMDDHHMMSSZ). Z в формате представления времени — символьная константа, указывающая на смещение относительно часового пояса Zulu Time (UTC, он же время по Гринвичу (GMT)), при её отсутствии подразумевается локальное время.
RevokedCerticates	В CRL отозванные сертификаты идентифицируются по их серийным номерам. Серийные номера не глобально уникальны, но уникальность поддерживается в серийных номерах сертификатов, выпущенных одним УЦ, таким образом, для получения уникальности клиенты должны использовать комбинацию серийного номера и поля issuer.
Extensions	Несколько расширений CRL определены в RFC 3280, ни одно из них не помечено как критичное (CRITICAL) и многие из них могут присутствовать лишь в случае непрямого CRL, то есть CRL, выпущенного сторонним УЦ (не тем УЦ, который выпустил отзываемый сертификат).
SignatureAlgorithm	Алгоритм (идентифицируемый по OID), используемый для подписания сертификата, и любые ассоциированные с ним параметры. Например, OID цифровой подписи RSA с SHA1 (sha1WithRSAEncryption): Это значение должно совпадать с указанным в поле signature CRL. Список действительных для использования с сертификатами X.509 OID определён в RFC 3279.
SignatureValue	Битовая строка, содержащая цифровую подпись.

Процесс доверия — удостоверяющие центры и сертификаты X.509

Как было сказано выше, сертификат X.509 является доверенным источником открытого ключа субъекта, указанного в сертификате (обычно указывается в атрибуте CN поля subject или в дополнении subjectAltName). Доверие формируется во время процесса создания сертификата. В зависимости от УЦ, процесс получения сертификата X.509 будет различаться в деталях, но, в общем случае, он состоит из следующих шагов:

Первое (самого высокого уровня) звено в цепи доверия — это удостоверяющий центр (УЦ). УЦ считаются доверенными организациями либо потому, что они сами так заявляют, либо потому, что они удовлетворяют каким-либо стандартам. Самой признанной организацией в сфере стандартизации УЦ в Северной Америке является WebTrust, и большинство УЦ указывают в документации, что они подвергались ревизии аккредитованным аудитором WebTrust (хотя в последнее время всё чаще подобные проверки выполняют и другие крупные международные аудиторские конторы). Сам факт основания УЦ является первым шагом в создании линии доверия. В какой-то момент времени УЦ генерирует одну или несколько пар асимметричных ключей и с помощью закрытого ключа выпускает самоподписанный сертификат (поля issuer и subject данного сертификата X.509 совпадают и в расширении BasicConstraints cA установлен в TRUE). Этот сертификат является корневым сертификатом удостоверяющего центра, а закрытый ключ, парный к которому открытый ключ содержится в корневом сертификате, используется для подписания пользовательских сертификатов. Корневые сертификаты (или сертификаты УЦ) распространяются среди конечных пользователей посредством какого-либо доверенного процесса, чаще всего с инсталлятором браузера.

Пользователь, желающий получить сертификат, рассматривает продукты различных удостоверяющих центров (УЦ) и выбирает наиболее подходящий для него УЦ. Выбранному УЦ (или одному из его агентов — регистрационных центров (РЦ)) подаётся заявка на конкретный тип сертификата SSL (X.509). В зависимости от типа сертификата затребывается и (как правило) проверяется различная информация, такая как наименование бизнеса, регистрационный номер бизнеса или иная идентификационная информация. Опять же, в зависимости от типа сертификата, могут быть затребованы дополнительные подтверждения идентичности. В основном вся эта информация подвергается ручной обработке (хотя процесс может быть в большей или меньшей степени автоматизирован). В результате этих проверок устанавливается следующее звено в цепи доверия.

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

После выбора продукта SSL, предоставления необходимой идентификационной информации и проверки её удостоверяющим центром, пользователю предлагается сгенерировать набор асимметричных ключей и с помощью закрытого ключа подписать запрос на подписание сертификата (Certificate Signing Request, CSR), в котором, кроме прочей информации, будет содержаться открытый ключ из сгенерированной пары ключей. Формат CSR определён в RFC 2986 (перепубликация стандарта RSA, PKCS#10, обновлён в RFC 5967) и содержит следующие данные:

CSR подписывается с помощью закрытого ключа из пары закрытого и открытого ключей, соответствующий открытый ключ помещается в поле SubjectPublicKeyInfo этого CSR.

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

Процедура создания CSR описана далее.

CSR загружается на сервер УЦ (обычно по FTP или HTTP). УЦ использует данные из CSR и, возможно, другую информацию, полученную из заявки на сертификат SSL, для создания сертификата X.509 пользователя, обычно со сроком действия от 1 до 3 лет. Наконец, УЦ подписывает сертификат пользователя (поля SignatureAlgorithm и SignatureValue) используя закрытый ключ, парный к которому открытый ключ содержится в корневом сертификате УЦ. Сертификат X.509 тем или иным способом (FTP/HTTP/EMAIL) отправляется пользователю.

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

При получении браузером сертификата от веб-сайта (во время протокола рукопожатия TLS/SSL) должен быть проверен весь путь вплоть до корневого сертификата (сертификата УЦ). На этом пути может быть один или несколько уровней сертификатов, в зависимости от поставщика сертификата. Корневые сертификаты (сертификаты УЦ), а также какие-либо необходимые промежуточные сертификаты, обычно распространяются в составе программного обеспечения основных браузеров. Распространяемые таким способом корневые сертификаты (сертификаты УЦ) часто называются якорями доверия — широко распространённый термин, используемый для описания любой базовой структуры или информации, полученной путём доверенного распространения, с помощью которой можно проверить/аутентифицировать полученную информацию. В RFC 5914 (и немного в RFC 5937) определено, каким образом могут быть организованы, использованы и обработаны такие якоря доверия в конкретных случаях применения сертификатов X.509/SSL.

Сертификаты EV

Сертификаты расширенной валидации (Extended Validation, EV) определены CA/Browser Forum и включают в себя сочетание продвинутых методов канцелярских проверок и технических процессов. Цель сертификатов EV — обеспечение повышенного доверия к конечным пользователям, хотя в стандартах прямо заявляется, что эти сертификаты не гарантируют, что владелец сертификата занимается заявленной деятельностью (бизнесом) — только то, что владелец действительно существует.

В браузерах, поддерживающих сертификаты EV, при защищённом соединении пользователь видит обычный значок замка, но при применении сертификата EV строка состояния подсвечивается зелёным цветом. В настоящий момент сертификаты EV поддерживают следующие браузеры: MSIE (только 7) и последние версии Konqueror, Firefox (v3+) и Opera(9.5+). Обычно сертификаты EV значительно дороже, нежели другие типы сертификатов. Характеристики стандарта издания сертификатов EV:

Удостоверяющий центр должен быть аттестован на соответствие EV и подвергаться ежегодной переаттестации.

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

Удостоверяющие центры следуют практикам, изложенным в RFC 3647, который имеет статус информационного (INFORMATIONAL), то есть все остальные могут его не придерживаться.

Стандартизируется использование и значение некоторых атрибутов DN в поле subject, а также добавляются несколько новых. В частности, следующие атрибуты определены как требуемые (REQUIRED) — эквивалент ключевого слова MUST из RFC в стандартах EV:

1. O — organizationalName (OID 2.5.4.10). Полное юридическое название организации пользователя.
2. businessCategory (OID 2.5.4.15). Определяет, какие категории сертификатов могут подойти, могут быть разделы 5b, 5c или 5d.
3. C — Country — (OID 2.5.4.6), ST — stateOrProvinceName — (OID 2.5.4.8) и L — localityName — (OID 2.5.4.7). Значения всех этих атрибутов должны соответствовать легальной юрисдикции бизнес-субъекта (а не, скажем, расположению веб-сервера).
4. serialNumber (OID 2.5.4.5). Регистрационный номер бизнеса.
5. CN — CommonName — (OID 2.5.4.3). Доменное имя хоста, например, www.example.com.

Обязательное требование: предоставление EV-удостоверяющими центрами онлайновых (24×7) возможностей проверки статуса любого сертификата EV. Обычно это достигается путём использования Online Certificate Status Protocol (OCSP) (RFC 2560).

Обязательное требование: сертификаты EV могут выдаваться только для аутентификации серверов (по крайней мере пока), то есть в атрибуте CN= должно быть имя сервера, такое как www.example.com или mail.example.com.

Точное указание на то, что это именно сертификат EV, производится путём использования зарегистрированного OID (уникального для каждого УЦ) в поле CertificatePolicies.

Примеры — самоподписанные сертификаты

В этом разделе показано использование команд OpenSSL для выполнения задач, связанных с сертификатами X.509. Для иллюстрации всех функций работы с сертификатами он охватывает генерацию того, что в просторечии называется самоподписанными сертификатами. Термин «самоподписанные» требует небольшого разъяснения, поскольку у него два потенциальных значения.

Если подходить строго, то этот термин означает сертификат, в котором значения полей issuer и subject совпадают. В этом смысле все корневые сертификаты являются самоподписанными. Второе значение — то, когда пользователь становится сам себе удостоверяющим центром (УЦ), что является альтернативой покупке сертификата X.509 у официально признанных УЦ, таких как Verisign или Thawte (и других), которые уже являются доверенными (их корневые сертификаты (сертификаты УЦ) предустанавливаются на компьютер пользователя основными инструментами работы с сертификатами, например, браузерами). Полученный браузером с веб-сайта во время фазы протокола рукопожатия TLS/SSL сертификат пользователя (конечного субъекта), изданный одним из официально признанных УЦ, может быть отслежен (и, следовательно, аутентифицирован) браузером вплоть до удостоверяющего центра (УЦ) с использованием поля issuer полученного сертификата. Чтобы браузер не выводил сообщений об ошибках, должен быть предустановлен корневой сертификат УЦ (а также любые промежуточные сертификаты). Для определения установленных сертификатов используется термин якорь доверия. Корневые сертификаты большинства коммерческих УЦ и многих национальных УЦ распространяются и инсталлируются с программным обеспечением браузеров, таких как MSIE, Firefox, Opera и т.д.

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

Когда программное обеспечение с поддержкой TLS/SSL (браузер) впервые встречает самоподписанный сертификат и подразумевается, что у браузера нет копии соответствующего корневого сертификата, будет сгенерировано сообщение, спрашивающее пользователя, желает ли он принять сертификат. С другой стороны, самоподписанный корневой сертификат может быть предустановлен или импортирован на компьютер пользователя, в этом случае браузер не будет генерировать сообщения об ошибке.

Примечание по срокам действия сертификатов и размерам ключей: Большинство сертификатов, описанных в последующих подразделах, имеют срок действия от 1 до 3 лет. Однако, большинство коммерческих корневых сертификатов, поставляемых с браузерами, имеют сроки действия от 10 до 20 лет! Нет ничего страшного в использовании достаточно длительных сроков действия сертификатов, чтобы не беспокоиться об их постоянном перевыпуске. Текущая (2011 год) рекомендация по длине ключа RSA, — 2048 бит, — действительна до 2030 года (вследствие чего срок действия многих ныне действующих корневых сертификатов истекает около 2028 года, давая им запас времени в пару лет для увеличения размера ключа, прежде чем ключи размером 2048 бит не перестанут быть легитимными в 2030 году). Рекомендации RSA по силе и требуемым срокам действия ключей. Аналогичные рекомендации по размеру (2048 бит) и срокам действия (до 2030 года) ключей также содержатся в специальной публикации 800-57, часть 1, ревизия 2, таблица 4 Национального института стандартов и технологий США (National Institute of Standards and Technology, US NIST).

Обзор процесса

В приведённых далее последовательностях действий используются команды OpenSSL (тестировалось с OpenSSL 0.9.8n и 1.0.0e) для генерации самоподписанных сертификатов X.509, которые могут быть установлены и использованы серверными системами TLS/SSL, такими как веб, FTP, LDAP или почтовыми системами (агентами SMTP). Команды OpenSSL используют множество параметров, в том числе ответы по умолчанию, сроки действия и поля сертификатов, из файла openssl.cnf (в FreeBSD — /etc/ssl/openssl.cnf), и если Вы собираетесь работать с сертификатами всерьёз, стоит просмотреть и, по мере необходимости, отредактировать этот файл, чтобы потом меньше было печатать параметров в командной строке.

Примечание: Есть серьёзные опасения, что ошибки, допущенные при редактировании openssl.cnf или при экспериментах с CA.pl (полезный скриптовый файл), могут привести к падению небес на землю. Сделайте резервную копию обоих файлов, прежде чем начинать что-либо делать, тогда Вы в любой момент сможете вернуть Вашу систему в первоначальное состояние, если что-то пойдёт не так. Помните: всё что Вы делаете, Вы делаете на свой страх и риск.

Создаваемые при работе с сертификатами файлы будут содержать либо открытые ключи, которые обычно не требуют особенной защиты, либо закрытые ключи, которые необходимо хорошо защищать. Будут ли оба типа файлов храниться в одной структуре каталогов или нет — зависит от локальной политики безопасности. Многое также зависит от требований окружения. Как и с любым сложным программным обеспечением, существует огромное множество способов что-либо сделать, но из них лишь два-три могут оказаться действительно полезными методами (Really Useful Methods, RUM™).

Примечание по работе в FreeBSD: На свежеустановленной FreeBSD 8.1 в установке openssl по умолчанию (0.9.8n) отсутствует скрипт CA.pl. Если Вы запрашивали инсталляцию исходных кодов, то его можно найти в /usr/src/crypto/openssl/apps/CA.pl. Другой вариант — использовать систему портов (/usr/ports/security/openssl), а затем выполнить make patch (просто скачать и распаковать openssl, но не устанавливать его), после чего найти скрипт с помощью find ./ -name «CA.pl». Поскольку PERL в FreeBSD больше не устанавливается по умолчанию, его нужно установить самостоятельно.

Метод 1: Корневой сертификат, сертификат сервера

Создаётся сертификат УЦ, то есть корневой сертификат, который можно импортировать в браузер в целях тестирования, а также один сертификат сервера, который может быть использован сервером, например, Apache. Для упрощения процесса используется стандартный скрипт OpenSSL CA.pl (для упрощения примеров мы переместили его в /etc/ssl, Вы же указывайте своё расположение).

Примечание: Для генерации сертификатов, которые можно было бы использовать с несколькими именами сервера, например, example.com, www.example.com или www.example.net требуется процесс, описанный ниже.

Дополнительные пояснения и примечания смотрите далее. Файл demoCA/cacert.pem, являющийся корневым сертификатом, может быть скопирован и импортирован в браузер.

Метод 2: Только сертификат сервера

Это самый простой (в одну команду) путь создания сертификата X.509, который можно будет использовать и как сертификат сервера, и как корневой сертификат (сертификат УЦ). Поскольку этот сертификат самоподписанный (и присутствует поле CA:True), он может быть импортирован в браузер или другое клиентское ПО как корневой сертификат (сертификат УЦ). Запрашиваемая последовательность атрибутов относится к DN того сервера, для которого генерируется сертификат. В частности, атрибут CN должен определять имя хоста сервиса, такое как www.example.com, а не имя хоста компьютера. То есть, если веб-сервис имеет адрес https://www.example.com, а выполняется на хосте webserver.example.com, следует использовать CN=www.example.com. Далее показан стандартный диалог OpenSSL, значения #обрамлённые_знаками_решётки# должны быть заменены на требуемые, например, #имя_сервера# следует заменить на действительное имя сервера, который подлежит аутентификации, скажем, www.exmple.com или ldap.example.com.

Примечание: Для генерации сертификатов, которые можно было бы использовать с несколькими именами сервера, например, example.com, www.example.com или www.example.net требуется процесс, описанный ниже.

Примечание: Параметр -x509 используется для создания самоподписанного сертификата УЦ. -nodes подавляет диалог запроса парольной фразы. -days 1059 устанавливает срок действия сертификата: 2 года 329 дней.

<ляп> Читатели могут задаться вопросом, зачем здравомыслящему человеку может потребоваться создавать сертификат сроком действия 2 года 329 дней? Тому есть две причины. Во-первых, если можно так сделать, то почему бы и нет? Во-вторых, внимательные читатели могли заметить, что 3 года составляет 1095 дней а не 1059, которые были использованы в тестах. Если честно, при первоначальном запуске тестов мы перепутали 5 и 9 (по молодости лет, плохому зрению или глупости — решайте сами) и вместо того, чтобы перезапустить тесты с 1095 днями, мы оставили 1059 и придумали эту глупую отмазку. Наконец, поскольку предполагается, что текущие рекомендации по размеру ключей в 2048 бита будут действительны до 2030 года, можно вполне разумно задать это значение в -days 6205 (по состоянию на 2013 год): 17 лет с учётом високосных лет.</ляп>

Метод 3: Корневой сертификат УЦ и несколько сертификатов

Если Вы собираетесь генерировать несколько сертификатов, скажем, для использования во внутренней системе, этому стоит посвятить некоторое время и усилия. Мы пробовали несколько методов и этот, на наш взгляд, самый простой. В нём используется стандартный скрипт CA.pl для создания удостоверяющего центра, при этом инициализируются множество директорий и файлов, которые очень проблематично настроить другим способом, а затем используются команды openssl для генерации CSR и подписания сертификатов, поскольку таким способом достигается больший контроль над переменными и (относительно) меньший уровень проблем.

Размещение и предварительная подготовка. Необязательный этап, позволяющий печатать меньше параметров в командной строке. Решите, где Вы собираетесь построить свой репозиторий сертификатов. Для наглядности мы создадим его в /etc/ssl, и это размещение будет использоваться далее по тексту. Измените его в соответствии с Вашими потребностями. Переместите скрипт CA.pl (если Вы не можете его найти, используйте locate CA.pl) в /etc/ssl/CA.pl либо туда, где Вы собираетесь создавать репозиторий сертификатов. Мы также переименовали этот скрипт в ca.pl из-за патологического отвращения к клавише shift, но если Вы не разделяете наших взглядов, просто используйте CA.pl в примерах.

Файлы ca.pl (или CA.pl) и /etc/ssl/openssl.cnf оказывают существенное влияние на работу как самого скрипта, так и команды openssl. Произведённые нами изменения показаны ниже, для удобства в файле CA.pl (ca.pl) приведены только изменённые строки:

Чтобы упростить себе жизнь, мы сделали следующие изменения в /etc/ssl/openssl.cnf (опять же, приведены только изменённые строки):

Стоит проверить все остальные значения этого файла — вдруг Вы захотите что-то изменить.

Создание удостоверяющего центра. Первая команда создаёт корневой сертификат удостоверяющего центра (УЦ) и некоторые другие служебные файлы. Создаётся пара ключей — открытый и закрытый. Открытый ключ записывается в корневой сертификат /etc/ssl/ca/cacert.pem, закрытый ключ — в /etc/ssl/ca/private/cakey.pem. Формат файла по умолчанию — PEM. Запрашиваемые детали DN будут использованы для формирования полей issuer и subject этого корневого сертификата, а также для поля issuer всех последующих подписанных сертификатов, укажите их в соответствии со своими требованиями. Парольная фраза обязательна, она устанавливается для защиты закрытого ключа и будет запрашиваться при всех последующих подписаниях сертификатов, так что её стоит запомнить:

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

Создаётся стандартная структура директорий:

Срок действия созданного корневого сертификата (ca/cacert.pem) — 10 лет (3650 дней) согласно отредактированному значению в файле ca.pl. Соответствующий закрытый ключ (ca/private/cakey.pem) защищён парольной фразой PEM, но всё равно его следует защищать установкой минимально возможных прав доступа (назначаемые по умолчанию права 0644 неоправданно высоки). Запрашиваемый Challenge Password — простой пароль, который может быть использован для защиты доступа к сертификатам, CSR и последующим сертификатам X.509. Большинство (если не все) коммерческие удостоверяющие центры не приветствуют установку этого пароля и сопутствующего опционального названия компании (Optional Company Name), и во всех примерах это поле оставляется незаполненным. Если Вы хотите отключить запрос этих значений, отредактируйте /etc/ssl/openssl.cnf:

Создание запроса на подписание сертификата (CSR). Запрашиваемые в этом случае атрибуты DN будут относиться к полю subject итогового сертификата.

Эта команда может использоваться и для создания запроса CSR (Certificate Signing Request) в коммерческий УЦ, а поскольку большинство УЦ не приветствуют паролей, просто нажмите ENTER при запросе A challenge password (о том, как совсем отключить эти запросы смотрите выше). Опциональное значение emailAddress также остаётся пустым, главным образом потому, что для сертификата сервера оно не имеет никакого значения, а также потому, что в большинстве запросов в коммерческие УЦ оно не заполняется.

Эта команда создаёт новый запрос на подписание сертификата (в /etc/ssl/ca/certs/cert1csr.pem), который затем должен быть подписан с помощью закрытого ключа УЦ, и закрытый ключ (который, за счёт использования параметра -nodes, не будет защищён парольной фразой — ведь мы будем использовать его в серверном приложении) в /etc/ssl/ca/private/cert1key.pem. Значение CN (в примере — www.example.com) — это используемое приложением имя сервиса. Оно могло бы быть ldap.example.com, либо любым другим подходящим именем. Имейте также ввиду, что такой сертификат сработает при доступе на https://www.example.com, но если для доступа к тому же сервису используется https://example.com, то Вам перед созданием CSR нужно обязательно добавить атрибут сертификата subjectAltName с помощью описанной ниже процедуры (и использовать в секции VirtualHost настроек Apache директиву ServerAlias). Имя сервиса не следует путать именем хоста сервера. Так, если к веб-сервису обращаются как к https://www.example.com, а он выполняется на хосте webserver.example.com, в CN нужно использовать www.example.com.

Для просмотра запроса сертификата выполните:

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

Создание и подписание сертификата конечного пользователя. Эта команда принимает на входе CSR (ca/certs/cert1csr.pem) и создаёт сертификат конечного пользователя (конечного субъекта) (ca/certs/cert1.pem):

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

Поле issuer полученного в результате сертификата формируется из поля subject корневого сертификата (ca/cacert.pem), а поле subject нового сертификата — из CSR. Многие значения по умолчанию команда берёт из openssl.cnf: срок действия (default_days =), ключ подписания (private_key =) и DN издателя из корневого сертификата (certificate =). В зависимости от требований Вашей системы параметр -policy policy_anything может быть обязательным. Он указывает на определённую в файле openssl.cnf секцию policy_anything, которая позволяет задавать в DN поля subject сертификата значения атрибутов, отличные от соответствующих атрибутов в DN поля issuer. При отсутствии этого параметра по умолчанию используется -policy policy_match, накладывающее ограничения на значения RDN C=, ST= и O=.

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

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

Полезные команды

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

Импорт самоподписанного корневого сертификата. Созданный на этапе 2 файл в формате PEM (ca/cacert.pem) может быть импортирован непосредственно в MSIE и Firefox, чтобы они не выдавали запросы о недоверенных сертификатах. Процедура импорта описана ниже.

Метод 3A: Создание подчинённых УЦ, промежуточных сертификатов и кросс-сертификатов

В методе 3 создаётся простая цепочка из двух сертификатов: сертификата конечного субъекта (сервера) и корневого сертификата УЦ. В методе 3A производится исследование того, что можно добавить к этой структуре (по тем или иным причинам). Мы создадим подчинённый УЦ, возможно, второй корневой УЦ, а также, основываясь на этой структуре, создадим всевозможные кросс-сертификаты и промежуточные сертификаты.

Основные настройки: Выполните этапы 1 и 2 метода 3. Создаётся просто структура директорий и наш первый корневой УЦ. Если Вы уже прошли все этапы метода 3, то ни одно из имён файлов, создаваемых далее не будет конфликтовать с уже созданными, так что Вы ничего не потеряете и Ваша система не нарушится. По завершении этого процесса будут созданы следующие директории и файлы:

Создаём подчинённый УЦ:

Создаём новые директории, скажем, subca и subca/private (с теми же правами, что и ca/private). Этот шаг просто позволит поддерживать порядок (в своём роде):

Редактируем openssl.cnf, создаём секцию [ sub_ca ], она может находиться в любом месте файла, но для определённости создадим её перед секцией [ user_certs ]. Различные параметры в этой секции будут использоваться для переопределения обычных параметров, используемых при подписании сертификата.

Создаём сертификат подчинённого УЦ:

Создаём CSR для подчинённого УЦ и подписываем его с использованием корневого сертификата УЦ:

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

Четыре расширения X509v3 extensions, — следствие использования аргумента -extensions sub_ca, — переопределяют обычные характеристики сертификата. Если от корневого УЦ требуется подписать обычный сертификат конечного субъекта, просто опустите этот аргумент. Технически, получившийся в результате сертификат (ca/subca/subca1cert.pem) — это кросс-сертификат, поскольку и полученный сертификат, и сертификат издателя имеют поле basicConstraints, в котором cA установлено в True.

Подписание сертификата конечного субъекта подчинённым УЦ:

Чтобы подписать сертификат конечного субъекта с использованием ключа подчинённого УЦ, нам сначала нужно скопировать файл openssl.cnf и переименовать его, скажем, в subca1.cnf. Теперь внесём изменения в subca1.cnf (эти изменения просто сообщат openssl где брать различные файлы, относящиеся к subCA, тогда как стандартный файл openssl.cnf продолжит ссылаться на информацию о корневом УЦ):

Теперь создадим CSR на сертификат конечного субъекта и подпишем его ключом subCA:

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

В данном случае издатель сертификата — subCA1, а не root CA1, как было при подписании запроса на создание сертификата подчинённого УЦ. Чтобы разрешить проверку подлинности сертификата конечного субъекта по всей цепочке, в браузер должны быть импортированы ОБА сертификата: корневого УЦ (ca/cacert.pem) и подчинённого УЦ (ca/subca/subca1cert.pem).

Другие возможности:

Используя подобную технику, можно создать второй корневой УЦ (root CA2), при этом, понятное дело, потребуется ещё одна копия openssl.cnf, либо второй подчинённый УЦ (subCA2), опять же, с уникальным конфигурационным файлом. Короче, любой каприз.

Сертификаты с несколькими именами сервера

Если сертификат предназначен для использования на хосте, у которого больше одного имени DNS, скажем, https://www.example.com, https://example.com или даже www.example.net, то вам нужно указать использование атрибута сертификата subjectAltName в запросе на подписание сертификата (CSR). Чтобы это сделать, отредактируйте файл openssl.cnf как показано ниже (приведены только изменённые строки):

При запуске команды на создание CSR добавьте к её аргументам -reqexts «v3_req» только в том случае, когда Вам нужно включить дополнительные поля subjectAltName. Хотя в приведённом примере показано добавление трёх имён, на практике можно добавить любое количество. Каждое включение имеет формат DNS:hostname.domain.name, несколько включений должны быть разделены запятыми, а все вместе они должны быть заключены в кавычки. Вот запрос на создание CSR из этапа 3 метода 3 с дополнительным аргументом:

Если при создании CSR не указывался аргумент -reqexts, по этому CSR будет создан обычный сертификат с единственным именем сервера. Приведённый пример работает как дополнение рассмотренного выше метода 3 и представляет собой наиболее гибкий подход.

Примечание: Если Вы хотите выпустить несколько сертификатов с разным набором имён серверов в каждом, то лучшей стратегией будет простое копирование и переименование стандартного конфигурационного файла (openssl.cnf) во что-то более осмысленное, а затем использование аргумента -config filename для выбора каждого из файлов по мере необходимости. Количество подобных конфигурационных файлов может быть любым, просто помните их имена и предназначение.

Если Вы хотите создать сертификаты с несколькими именами сервера в методах 1 или 2, то в дополнение к приведённым выше правкам openssl.cnf добавьте это:

При такой модификации атрибуты сертификата subjectAltName будут безусловно добавляться в каждый CSR.

Замечания по форматам файлов, связанных с SSL

В настоящее время существует множество форматов файлов, используемых для хранения сертификатов, ключей и других данных, связанных с X.509/SSL. Иногда расширения таких файлов дают представление об их содержимом, иногда — нет. Прежде чем углубляться в детали, прочтите этот краткий обзор:

Все связанные с SSL объекты (сертификаты, ключи и прочие) изначально используют кодировку DER. DER — это бинарная (8 бит) кодировка. Это, кроме всего прочего, означает, что пересылать такие данные по электронной почте нельзя. PEM (Privacy Enhanced Mail) — это метод простого перекодирования (с использованием base64) первоначальных форматов DER в нечто такое, что может быть отправлено по электронной почте или передано по другим коммуникационным системам.

Некоторые стандарты PKCS#X, в частности, PKCS#7 (и его CMS-эквивалент от IETF RFC 5652), PKCS#12 и PKCS#8, представляют собой контейнеры (закодированные в формат DER), используемые для определения нескольких объектов в одном и том же файле. Если файл содержит один объект, скажем, сертификат или CRL, то такому объекту контейнер не требуется (хотя, опционально, он может быть и заключён в контейнер).

По своей сути, единичный ключ выглядит как один объект, и потому контейнер ему не требуется. Однако, помимо самого ключа, требуется также информация об алгоритме его использования (а также другие параметры), следовательно, для единичного ключа всё-таки требуется контейнер для определения составляющих объектов этого ключа (в данном случае PKCS#8). И наоборот, сертификат X.509v3 содержит много различной информации, и потому может показаться, что для него требуется контейнер. Но сертификат X.509v3 сам по себе является контейнером. Поэтому, если в файле содержится только единичный сертификат, то он не нуждается в контейнере (например, файлы с расширениями .cer или .crt). Однако, когда в одном файле содержится сертификат и закрытый ключ (файлы с расширениями .p12/.pkx), то в этом случае присутствуют как минимум два объекта, требующие определения, и потому здесь контейнер необходим (в данном случае PKCS#12).

Многие форматы из стандартов PKCS#X представляют собой контейнеры (закодированные в DER), содержимое которых по своей природе предназначено для передачи посредством какой-либо системы связи, например, запросы на подписание сертификата (CSR). В таких случаях сформированные данные, независимо от расширения файла, в конечном итоге кодируются в PEM.

Во многих случаях содержимое файла определяется контекстом ситуации, а не расширением файла. Так, если ожидается, что файл должен содержать только сертификат (без закрытого ключа), то он может иметь расширения как .pem, так и .crt, и даже .cer.

В качестве простейшего теста откройте файл, независимо от его расширения, в текстовом редакторе. Если там какая-то абракадабра, значит он закодирован в DER. Если Вы можете прочитать ‘——BEGIN’ — это PEM.

Формат PEM

В качестве формата по умолчанию (основного формата) OpenSSL поддерживает формат почты повышенной конфиденциальности Privacy Enhanced Mail (PEM). Изначальный формат сертификатов X.509, как, впрочем, и всех остальных объектов, связанных с SSL, — ASN.1 DER (бинарный формат). PEM кодирует бинарный блок DER в base64 (RFC 3548), при этом создаётся текстовая версия (подмножество набора символов ASCII/IA5) которая может, кроме всего прочего, пересылаться почтовыми системами. Закодированные в PEM объекты включают заголовочную и завершающую строки, каждая из которых начинается и заканчивается ровно пятью дефисами и представляет собой пригодное для чтения людьми описание того содержимого в формате base64, которое заключено между этими строками. Файлы PEM выглядят примерно так:

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

Текст BEGIN CERTIFICATE и END CERTIFICATE из примера может принимать различные значения, описывающие функциональность и формат материала, содержащегося между строками-ограничителями. В любом файле PEM может быть более одного элемента (каждый из которых ограничен последовательностью ——BEGIN ——END), а также этот файл может содержать другую информацию до, после и между такими элементами, но не внутри ограничителей. Формат PEM определён в RFC 1421 для использования с S/MIME (RFC 3850).

Ключевые слова, используемые в элементах BEGIN формата PEM

В RFC 7468 определено несколько ключевых слов (или меток), которые могут встречаться в файлах, закодированных в PEM, в элементах ——BEGIN и ——END (но, как это ни удивительно, не определён репозиторий IANA для этих ключевых слов). Кроме того, заголовочный файл pem.h из пакета OpenSSL (версии 1.0.2d) содержит другие ключевые слова (некоторые из которых явно упразднены в RFC 7468, некоторые могут быть неявно упразднёнными — смотрите примечания ниже). В таблице ниже приведены ключевые слова, собранные из двух источников и снабжённые соответствующими описаниями и комментариями.

Примечание: В закодированных в PEM файлах данные ключевые слова должны присутствовать в обоих элементах BEGIN и END. Для краткости строки ——BEGIN и —-END не показаны, то есть, если в таблице приведено ключевое слово CERTIFICATE, то в PEM-файле оно будет присутствовать дважды: в ——BEGIN CERTIFICATE—— и в ——END CERTIFICATE——.

Ключевое слово	Источник	Применение	Примечания
CERTIFICATE	RFC 7468	Содержит один закодированный в DER сертификат X.509v3, как определено в разделе 4 RFC 5280	В RFC 7468 названы устаревшими ключевые слова X509 CERTIFICATE и X.509 CERTIFICATE
X509 CRL	RFC 7468	Содержит один закодированный в DER список отзыва сертификатов X.509, как определено в разделе 5 RFC 5280	В RFC 7468 названо устаревшим ключевое слово CRL
CERTIFICATE REQUEST	RFC 7468	Содержит один закодированный в DER запрос сертификата PKCS#10 (он же CSR), как определено в RFC 2986 и дополнено в RFC 5967	В RFC 7468 названо устаревшим ключевое слово NEW CERTIFICATE REQUEST
PKCS7	RFC 7468	Содержит закодированный в DER контейнер PKCS#7 (CMS) (в который может быть заключено несколько сертификатов), как определено в RFC 2315	В RFC 7468 названо устаревшим ключевое слово CERTIFICATE CHAIN и неявно осуждается использование нескольких сертификатов в одной структуре PKCS#7 (в RFC 7468 предлагается заменить PKCS#7 на IETF CMS RFC 5652, смотрите ниже).
CMS	RFC 7468	Содержит закодированный в DER контейнер CMS (в который может быть заключено несколько сертификатов), как определено в RFC 5652	В основном обратно совместим с описанной выше структурой PKCS#7
PRIVATE KEY	RFC 7468	Содержит незашифрованный закодированный в DER контейнер PKCS#8 с одним ключом, как определено в разделе 2 RFC 5958	В RFC 5958 структура PrivateKeyInfo (из RFC 5208) переименована в OneAsymmetricKey, что позволяет помещать в один контейнер как открытый, так и закрытый ключи. Однако, в RFC 7468 этот формат НЕ поддерживается для закодированных в PEM открытых ключей (смотрите описание ключевого слова PUBLIC KEY ниже). Поскольку контейнер PKCS#8 идентифицирует ключевой алгоритм, он неявно делает устаревшим (хотя прямо об этом не говорится) использование ключевых слов RSA PRIVATE KEY, DSA PRIVATE KEY, EC PRIVATE KEY or ANY PRIVATE KEY, DSA PARAMETERS, EC PARAMETERS, DH PARAMETERS (все они могут быть сгенерированы с использованием OpenSSL).
ENCRYPTED PRIVATE KEY	RFC 7468	Содержит зашифрованный закодированный в DER контейнер PKCS#8 с одним ключом, как определено в разделе 3 RFC 5958
PUBLIC KEY	RFC 7468	Содержит закодированную в DER структуру SubjectPublicKeyInfo (мини-контейнер) с одним открытым ключом, как определено в разделе 4.1.2.7 RFC 5280	Структура SubjectPublicKeyInfo описывает ключевой алгоритм и, следовательно, RFC 7468 неявно делает устаревшим (хотя прямо об этом не говорится) использование ключевых слов DSA PUBLIC KEY, RSA PUBLIC KEY и ECSDA PUBLIC KEY (все они могут быть сгенерированы с использованием OpenSSL).
ATTRIBUTE CERTIFICATE	RFC 7468	Содержит закодированный в DER атрибутный сертификат (Attribute certificate), как определено в RFC 5755	Атрибутные сертификаты представляют собой закодированные в DER сертификаты X.509, НЕ содержащие открытого ключа. В основном они используются в целях авторизации (а не аутентификации). В заголовочном файле pem.h OpenSSL (1.0.2d) нет соответствующего ключевого слова PEM для такого типа сертификата.
CERTIFICATE PAIR	pem.h	??	Определён в заголовочном файле pem.h OpenSSL, но отсутствует в RFC 7468. В настоящий момент целевой контент не установлен.
TRUSTED CERTIFICATE	pem.h	??	Определён в заголовочном файле pem.h OpenSSL, но отсутствует в RFC 7468. В настоящий момент целевой контент не установлен, но предположительно это сертификат, где в поле BasicConstraints атрибут cA установлен в TRUE.
PKCS #7 SIGNED DATA	pem.h	??	Определён в заголовочном файле pem.h OpenSSL, но отсутствует в RFC 7468. В стандарте PKCS#7 разрешено несколько типов контента (‘content types’), один из которых — подписанные данные (эта опция не относится к широко внедрённым).
SSL SESSION PARAMETERS	pem.h	??	Определён в заголовочном файле pem.h OpenSSL, но отсутствует в RFC 7468. В настоящий момент целевой контент не установлен.
X9.42 DH PARAMETERS	pem.h	??	Определён в заголовочном файле pem.h OpenSSL, но отсутствует в RFC 7468. В настоящий момент целевой контент не установлен.

Имена файлов

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

Применение	Расширение файла	Закрытый ключ	Формат	Примечания
Ключ	.pem	да	PEM	Закодированный в PEM ключ в формате DER в контейнере PKCS#8/RFC 5958, может быть зашифрован или не зашифрован (можно понять по ключевому слову PEM), хотя чаще не зашифрован, поскольку так его используют обычно. Ключевые слова PEM: PRIVATE KEY или ENCRYPTED PRIVATE KEY.
.der	да	DER	Используется редко. Ключ в формате DER в контейнере PKCS#8/RFC 5958, может быть зашифрован или не зашифрован, хотя чаще не зашифрован, поскольку так его используют обычно.
.key	да	PEM	Такое расширение используется во многих *nix-системах для обозначения закрытого ключа. Закодированный в PEM ключ в формате DER в контейнере PKCS#8/RFC 5958, может быть зашифрован или не зашифрован, хотя чаще не зашифрован, поскольку так его используют обычно. Ключевые слова PEM: PRIVATE KEY или ENCRYPTED PRIVATE KEY.
Сертификат	.crt	нет	PEM или DER	Обычно в формате PEM (в RFC 7468 предлагается, чтобы это расширение всегда означало PEM-формат). Содержит только сертификат X.509v3. Не контейнер. Такой формат принимают браузеры MSIE, Firefox и Chrome.
.cer	нет	PEM или DER	Обычно в формате DER (в RFC 7468 предлагается, чтобы это расширение всегда означало DER-формат). Содержит только сертификат X.509v3. Не контейнер. Такой формат принимают браузеры MSIE, Firefox и Chrome.
.pem	может быть	PEM	Расширение файла не говорит о его содержимом. В файле может быть практически что угодно, от одного ключа до нескольких сертификатов в связке сертификатов УЦ, заключённых в контейнер PKCS#7 (CMS), или даже запрос сертификата PKCS#10. Ключевое слово PEM поможет определиться с содержимым. В некоторых контекстах считается, что файл с таким расширением эквивалентен файлу с расширением .crt. Такой формат принимает только Firefox.
.der	может быть	DER	Расширение файла не говорит о его содержимом. В файле может быть практически что угодно, от одного ключа до нескольких сертификатов в связке сертификатов УЦ, заключённых в контейнер PKCS#7 (CMS), или даже контейнер PKCS#12, или ещё что-то. В некоторых контекстах считается, что файл с таким расширением эквивалентен файлу с расширением .cer. Такой формат принимает только Firefox.
.p12	может быть	PKCS#12 (RFC 7292)	PKCS#12 (RFC 7292) представляет собой формат закодированного в DER контейнера общего назначения. Может содержать (и, как правило, содержит) один или несколько сертификатов X.509v3 и может содержать (и, как правило, содержит) закодированный в DER закрытый ключ, но может содержать и другие типы данных. Такой формат принимают браузеры MSIE и Chrome.
.pfx	да	RFC 7292	PKCS#12 (RFC 7292) представляет собой формат закодированного в DER контейнера общего назначения. То же, что и файл с расширением .p12, но обычно используется в системах Microsoft и по соглашению содержит один (или несколько) сертификатов X.509v3, закодированных в DER, и закодированный в DER закрытый ключ. Такой формат принимают браузеры MSIE и Chrome.
.p7b	нет	PKCS#7 (или RFC 5652)	PKCS#7 (или RFC 5652) CMS DER-контейнер, закодированный в PEM. Может содержать один или несколько сертификатов, а также другие объекты. Такой формат принимают браузеры MSIE, Firefox и Chrome. Может быть закодирован в PEM, а может быть и нет.
Разное	.csr	нет	PEM/PKCS#10	Также может использоваться расширение .pem. Запрос сертификата (CSR). Содержит закодированный в PEM контейнер в формате DER PKCS#10 (RFC 7292), содержит открытый ключ пользователя, тип алгоритма и атрибуты, которые требуется добавить в сертификат.
.crl	нет	PKCS#7 или структура списка сертификатов	Список отзыва сертификатов (CRL) представляет собой закодированную в DER структуру списка сертификатов. Может быть заключена в контейнер PKCS#7 (RFC 2315, или (чаще) просто закодированная в DER структура списка сертификатов, определённая в разделе 5 RFC 5280. Обычно закодирована в PEM. Такой формат принимают браузеры MSIE и Chrome.

Связки сертификатов

Номинально, ответственность за проверку полученного от сервера сертификата конечного субъекта несёт клиент. При этом всё чаще требуется проверять ещё и промежуточные сертификаты и/или кросс-сертификаты. Поэтому, если раньше сертификаты распространялись по одному, то теперь в практику входит распространение нескольких сертификатов — мультисертификатов (multi-certificate). Подобные мультисертификаты обычно называются связками сертификатов (certificate bundles), связками сертификатов УЦ (ca-bundles) или цепочками сертификатов (certificate chains). Регулярное обновление миллионов клиентов выдвигает серьёзные требования к логистике, поэтому всё более популярным становится распространение новых промежуточных сертификатов или кросс-сертификатов (и даже корневых сертификатов) через сервер. Существует три основных метода создания связок сертификатов:

С помощью структуры PKCS#7 (или RFC 5652). Обычно итоговый файл имеет расширение .p7b (поддерживается браузерами MSIE и Chrome для импорта мультисертификатов). Файлы с таким расширением никогда не содержат закрытого ключа.

С помощью структуры PKCS#12 (RFC 7292), представляющей собой суперконтейнер для PKCS#7 и PKCS#8. Итоговый файл может иметь расширения .p12 или .pkx (поддерживается браузерами MSIE и Chrome для импорта мультисертификатов). По соглашению, файл с расширением .pkx содержит и сертификат (PKCS#7), и закрытый ключ (PKCS#8); файл с расширением .p12 может как содержать, так и не содержать закрытого ключа. Для веб-серверов IIS требуются файлы с расширением .pfx (хотя также поддерживаются файлы с расширением .p12).

Объединение в определенном порядке закодированных в PEM сертификатов. Поскольку PEM-файлы с сертификатами (ключевое слово PEM CERTIFICATE) представляют собой текстовые файлы, их можно объединить друг с другом вручную с помощью текстового редактора или такой команды unix:

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

Команды OpenSSL для конвертации, извлечения и манипуляций с сертификатами и ключами

В этом разделе показаны некоторые команды OpenSSL для выполнения различных манипуляций. В качестве исходного в OpenSSL используется формат PEM.

Таблица соответствия стандартов PKCS#X и RFC

В этом разделе даны перекрёстные ссылки с широко используемых стандартов PKCS на их RFC-эквиваленты.

Номер PKCS	RFC	Примечание
PKCS#1	RFC 8017	Контейнер для алгоритма RSA, охватывающего криптографические примитивы, схемы шифрования и схемы подписи.
PKCS#5	RFC 8018	Метод парольной защиты зашифрованных данных (используется в PCKS#8, PKCS#7 и PKCS#12).
PKCS#7	RFC 2315	Контейнер синтаксиса криптографического сообщения (Cryptographic Message Syntax, CMS). Обычно закодирован в PEM. Помимо других сущностей, в него часто заключаются один или несколько CRL (в этом случае файл может иметь расширение .crl, но не всегда), или один или несколько сертификатов (ExtendedCertificatesAndCertificates) (расширение файла .p7b). Отдельный стандарт CMS от IETF (в основном, но не полностью, совместимый с PKCS#7) определён в RFC 5652.
PKCS#8	RFC 5958	RFC переопределяет спецификацию PKCS#8. Контейнер ключей, куда могут помещаться как закрытые, так и открытые ключи. Однако чаще ассоциируется с закрытыми ключами. Опционально может быть зашифрован. Если закодирован в PEM, в RFC рекомендуется использовать файл с расширением .pem, если закодирован в DER, рекомендуется использовать файл с расширением .p8 (поддерживается не везде).
PKCS#9	RFC 2985 и RFC 7894	Атрибуты расширения, которые могут использоваться в PKCS#7, PKCS#8 и PKCS#10.
PKCS#10	RFC 2986, обновлено в RFC 5967	Закодированный в DER контейнер запроса сертификата. Содержит несколько атрибутов, описывающих алгоритм открытого ключа, а также атрибуты которые будут включены в итоговый сертификат. Почти всегда в формате PEM.
PKCS#12	RFC 7292	Общий контейнер для персональных данных. Данный контейнер состоит из контейнеров PKCS#7 и PKCS#8 внутри защищённой структуры. Расширения файлов — .p12 и .pkx. Исключительно в формате DER.

Работа с сертификатами в основных браузерах

Сертификаты могут быть импортированы в некоторые системы с помощью процедур, описанных в этом разделе. Периодически эта информация может изменяться. Для браузеров приводится версия браузера, чтобы показать, для какой именно версии приведённый метод является актуальным. Описывается импорт корневого или промежуточного сертификатов (в случае Chrome и MSIE должны быть выбраны соответствующие вкладки «Промежуточные центры сертификации» (Intermediate) или «Доверенные корневые центры сертификации» (Trusted Root)). Только Firefox напрямую принимает файлы с расширением .pem. Для MSIE и Chrome любые файлы с корневыми сертификатами, созданные с помощью описанных выше методов 1, 2, 3 или 3A, имеющие расширение .pem, можно просто переименовать из ca/cacert.pem в ca/cacert.cer или ca/cacert.crt по Вашему выбору.

MSIE (11): MSIE принимает файлы с расширением .cer, .crt, .p7b, .pfx, .p12 (возможно, и другие). MSIE -> Меню «Сервис» (Tools) -> «Свойства обозревателя» (Internet Options) -> Вкладка «Содержание» (Content) -> Кнопка «Сертификаты» (Certificates) -> Выберите соответствующее хранилище сертификатов -> Кнопка «Импорт» (Import), а затем выполните запросы мастера импорта.

Альтернативный метод для систем Windows 7+: использовать Консоль управления (Microsoft Management Console, MMC) с установленной оснасткой «Сертификаты» (Certificate). Перейдите к соответствующему хранилищу сертификатов -> Меню «Действие» (Actions) -> «Все задачи» (All tasks) -> «Импорт» (Import), а затем выполните запросы мастера импорта (принимает файлы с расширением .cer, .crt, .p7b, .pfx, .p12 (возможно, и другие)).

В окружении AD сертификаты также можно распространить с помощью объектов групповых политик (Group Policy Object, GPO). Загрузите «Администрирование» (Administrative Tools) -> «Управление групповой политикой» (Group Policy Manager) -> Раскройте пункт «Домены» (Domains) -> Щёлкните правой кнопкой мыши на «Default Domain Policy» и выберите «Изменить» (Edit) -> Раскройте пункт «Конфигурация компьютера» (Computer configuration) -> Раскройте пункт «Политики»->Раскройте пункт «Конфигурация Windows» (Windows Settings)->Раскройте пункт «Параметры безопасности» (Security Settings)->Раскройте пункт «Политики открытого ключа» (Public Key Settings)->Щёлкните правой кнопкой мыши на «Доверенные корневые центры сертификации» (Trusted Root Certificate Authorities)->Выберите «Импорт» (Import), а затем выполните запросы мастера импорта.

Firefox (41.x.x) Firefox принимает файлы с расширением .pem, .cer, .crt, .der или .p7b. Выберите меню «Инструменты» (Tools) -> «Настройки» (Options) -> «Дополнительные» (Advanced) -> Вкладка «Сертификаты» (Certificates) -> «Просмотр сертификатов» (View Certificates) -> Нажмите кнопку «Импортировать» (Import) и выберите файл.

Chrome (46.x.x.x) Chrome принимает файлы с расширением .cer, .crt, .p7b, .pfx, .p12 suffix (возможно, и другие). Выберите «Настройки» (Settings) -> Нажмите ссылку «Показать дополнительные настройки» (Enable Advanced Settings) -> Перейдите к разделу HTTPS/SSL -> Кнопка «Настроить сертификаты» (Manage Certificates) -> Выберите соответствующую вкладку -> Кнопка «Импорт» (Import), а затем выполните запросы мастера импорта.

RFC по теме

Список RFC, относящихся к TLS, сертификатам X.509 и PKI. Большинство из них упоминается в тексте этого документа. Список не полный, но мы обновляем его по мере обновления текста или при публикации подходящего RFC. Так что в конечном счёте он станет исчерпывающим.

Изменения страницы

Дата последнего изменения указана внизу страницы.

1. 25 января 2017 г.: В таблице соответствия стандартов PKCS#X и RFC обновлена ссылка на RFC для PKCS#5, добавлена информация по PKCS#1 со ссылкой на RFC. В список RFC добавлены RFC 8017 и 8018.
2. 16 сентября 2016: Исправлена опечатка в аббревиатуре CRMF. Добавлено примечание о введённом в RFC 7918 «фальстарте», позволяющем клиенту начинать передачу сообщения сразу после отправки ‘Finished’, не дожидаясь получения ‘Finished’ от сервера. В список RFC добавлены RFC 7918 и 7935.
3. 28 июля 2016 г.: Обновлён список RFC. Новый раздел об использовании полей subject и subjectAltName в сертификатах.
4. 13 июля 2016 г.: Добавлены недостающие гиперссылки.
5. 13 февраля 2016 г.: Обновлён список RFC, исправлены некорректные гиперссылки. Новый раздел об использовании сертификатов в окружении (многопользовательском) хостинг-провайдеров.
6. 2 ноября 2015 г.: Добавлена информация по связанным с TLS/SSL/сертификатами именам файлов, форматам и PKCS-контейнерам. Обновлена информация по импорту сертификатов в Chrome, Windows, MSIE и Firefox.
7. 28 октября 2015 г.: Обновлён список RFC. Добавлено определение сертификата конечного субъекта.
8. 23 октября 2015 г.: Обновлён список RFC. Добавлено примечание по расширению, позволяющему дополнять нулями размер сообщения ClientHello. Добавлено примечание по определённому в RFC 7633 расширению типа » Pivate Internet», позволяющее включать в сертификат расширения функционала TLS, что помогает в предотвращении атак. В описание расширений сертификата добавлены OID, чтобы можно было различить стандартные расширения X.509 (из пространства 2.5.29) и расширения «Private Internet» (из пространства 1.3.6.1.5.5.7.1). Текст примеров сокращён (в интересах пользователей с небольшими экранами).
9. 29 сентября 2015 г.: Обновлён список RFC. В описание протоколов TLS/SSL добавлено примечание по Extended Master Secret.
10. 14 июля 2015 г: Обновлён список RFC. Добавлено примечание об отмене SSL v3.0.
11. 10 июля 2015 г: Обновлён список RFC. Добавлено примечание о сертификатах Data Transmission Content Protection (DTCP) и их использовании в протоколе рукопожатия TLS (как определено в RFC 7562).
12. 30 мая 2015 г.: Обновлён список RFC. Добавлено примечание об определённом в RFC 7507 «наборе шифров» TLS_FALLBACK_SCSV.
13. 15 марта 2015 г.: Обновлён список RFC.
14. 5 января 2015 г.: Исправлена битая ссылка на раздел «Цепочки сертификатов X.509», исправлено неверное указание поля subjectPublicKeyInfo. Исправлена опечатка в описании поля subjectAltName для правильной идентификации использования атрибута dNSName.
15. 4 июля 2014 г.: Примечания об упрощённом формате сертификата, определённом в RFC 7250, в описаниях сообщений ClientHello, ServerHello, формата сертификата X.509 и атрибута SubjectPublicKeyInfo. Обновлён список RFC.
16. 21 января 2014 г.: Примечание в описании сообщения ClientHello о расширении Server Name Indication (SNI). Обновлён список RFC.
17. 22 декабря 2013 г.: Обновлён список RFC.
18. 18 декабря 2013 г.: Обновлён список RFC.
19. Ноябрь 2013 г.: Страница переделана в HTML5
20. Ноябрь 2013 г.: Порядок терминов на странице изменён с SSL/TLS на TLS/SSL для отображения современных тенденций.
21. Ноябрь 2013 г.: Обновлён рисунок 2.
22. Октябрь 2013 г.: В список RFC добавлены RFC 7027 и 7030. Обновлён текст, касающийся ECC.

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.