какие сертификаты необходимы для проверки подлинности сервера

Настройка уровней проверки подлинности сервера и шифрования

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

Дополнительные сведения об узле сеансов удаленных рабочих столов см. на странице «Службы удаленных рабочих столов» Технического центра Windows Server 2008 R2 ( https://go.microsoft.com/fwlink/?LinkId=140438 ).

Существует три уровня безопасности.

	Примечание

SSL (TLS 1.0) используется для проверки подлинности сервера и шифрования всех данных, передаваемых между сервером и клиентом.

Этот вариант используется по умолчанию.

Будет использоваться наиболее безопасный уровень, поддерживаемый клиентом. Если поддерживается, будет использоваться SSL (TLS 1.0). Если SSL (TLS 1.0) не поддерживается клиентом, будет использоваться уровень безопасности RDP.

Уровень безопасности RDP

Связь между сервером и клиентом использует встроенное RDP-шифрование. При выборе этого уровня безопасности проверку подлинности на уровне сети использовать нельзя.

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

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

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

Существует четыре уровня шифрования.

	Внимание!

При использовании этого уровня данные, которыми обмениваются клиент и сервер, шифруются и расшифровываются методами шифрования на основе стандарта FIPS 140-1. Клиенты, не поддерживающие этот уровень шифрования, не могут подключаться к серверу.

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

Совместимый с клиентским

Этот режим задан по умолчанию.

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

При использовании этого уровня шифруются только те данные, которые пересылаются от клиента к серверу, с помощью 56-битного шифрования. Данные, пересылаемые от сервера к клиенту, не шифруются.

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

На сервере узла сеансов удаленных рабочих столов откройте компонент «Конфигурация узла сеансов удаленных рабочих столов». Чтобы открыть конфигурацию узла сеансов удаленных рабочих столов, нажмите кнопку Пуск, затем последовательно выберите пункты Администрирование, Службы удаленных рабочих столов и Конфигурация узла сеансов удаленных рабочих столов.

В области Подключения щелкните правой кнопкой мыши имя подключения и выберите пункт Свойства.

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

Если выбран уровень безопасности SSL (TLS 1.0), выберите сертификат, установленный на сервере Узел сеансов удаленных рабочих столов, или нажмите кнопку По умолчанию, чтобы создать самозаверяющий сертификат. Если используется самозаверяющий сертификат, имя сертификата будет отображено как Автоматически созданный.

Проверку подлинности сервера и шифрование также можно настроить путем применения следующих параметров групповой политики:

Этот параметр групповой политики находится в разделе Конфигурация компьютера\Политики\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Хост-сервер сеансов удаленных рабочих столов\Безопасность. Для его настройки можно использовать редактор локальных групповых политик или консоль управления групповыми политиками. Обратите внимание, что эти параметры имеют приоритет над параметрами, заданными в оснастке Конфигурация узла сеансов удаленных рабочих столов, за исключением параметра политики «Шаблон сертификата проверки подлинности сервера».

Чтобы выбрать для сервера Узел сеансов удаленных рабочих столов FIPS-совместимый уровень шифрования, примените параметр групповой политики Системная криптография: использовать FIPS-совместимые алгоритмы для шифрования, хеширования и подписывания. Этот параметр находится в разделе Конфигурация компьютера\Политики\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности. Для его настройки можно использовать редактор локальных групповых политик или консоль управления групповыми политиками. Обратите внимание, что этот параметр имеет приоритет над параметром, заданным в оснастке Конфигурация узла сеансов удаленных рабочих столов, и параметром политики Установить уровень шифрования для клиентских подключений.

Источник

Всё о SSL-сертификатах простыми словами: устройство, типы, выбор

Если вы уже сталкивались с созданием собственного сайта, то наверняка краем уха слышали про сертификат SSL и HTTPS — поэтому в нашем новом посте расскажем, как защитить данные посетителей сайта, чем HTTPS отличается от HTTP, что такое SSL-сертификат и какие виды сертификатов существуют?

Что такое SSL-сертификат

SSL (Secure Sockets Layer — уровень защищённых сокетов) — это протокол шифрования, который позволяет кодировать данные для более безопасного обмена.

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

Благодаря SSL информация, которая передаётся, защищена от посторонних: администратора Wi-Fi сети, провайдера, оператора и других лиц — значит она не может быть перехвачена и использована в мошеннических целях. Кроме того, SSL-сертификат выступает в качестве подтверждения надёжности ресурса и даёт возможность проверить, кто является его настоящим владельцем.

Можно сказать, что SSL-сертификат — это своего рода уникальная цифровая подпись сайта.

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

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

А если на сайт установлен OV или EV сертификат, то при клике на замочек, появятся данные об организации, которой принадлежит сайт.

В таких типах сертификатов во вкладке «Подробнее» вы найдёте следующую информацию:

Разница между HTTP и HTTPS

Как вы уже знаете, каждый вбитый в поисковую строку запрос проходит путь от вас (пользователя) к серверу и обратно. Такая коммуникация возможна благодаря работе протокола HTTP. Аббревиатура расшифровывается как Hypertext Transfer Protocol. И всем он хорош — только данные не шифрует, а значит злоумышленники могут перехватить вашу личную информацию (данные банковских карт, пароли, реквизиты).

Для безопасности данных был внедрён протокол HTTPS — HyperText Transfer Protocol Secure (то есть защищённый протокол HTTP). В этом случае передача данных осуществляется по такому же протоколу, но с криптографическим шифрованием, о чём говорит дополнительная буква «S». HTTPS работает благодаря SSL/TLS-сертификату.

SSL/TLS-сертификат ― это цифровая подпись сайта. С её помощью подтверждается его подлинность.

Перед тем как установить защищённое соединение, браузер запрашивает этот SSL-сертификат и обращается к центру сертификации, чтобы подтвердить легальность документа. Если он действителен, то браузер и сервер доверяют друг другу и договариваются о разовом шифре. Так происходит каждую сессию, то есть каждый раз при обмене запросами и ответами. Вот откуда взялась и что означает «S» в HTTPS.

Каким сайтам нужен SSL?

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

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

Какие виды SSL-сертификатов есть и кто их выдаёт?

Есть специальные центры сертификации или как ещё называют — удостоверяющие центры (УЦ). Вы могли встречать названия таких УЦ: Symantec, Comodo, GlobalSign, Thawte, GeoTrust, DigiCert. Они подтверждают подлинность ключей шифрования с помощью сертификатов электронной подписи.

Кроме того, есть проекты, CloudFlare или LetsEncrypt, где можно получить сертификат бесплатно и самостоятельно. Такой сертификат выпускается на 3 месяца и далее требует продления. Однако во время их установки и дальнейшей работы есть ряд нюансов, которые стоит учитывать. Например, при выборе сертификата Cloudflare учтите, что он выдаётся сразу на 50 сайтов. Тем самым сертификат будет защищать не только ваш домен, но и ещё несколько чужих, что несёт за собой риски безопасности. Также у Cloudflare нет печати доверия. Если говорить о недостатках LetsEncrypt, то сюда можно отнести поддержку далеко не всех браузеров, отсутствие гарантии сохранности данных сайта и печати доверия.

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

Итак, существует несколько типов SSL-сертификатов по источнику подписи и типу проверки данных.

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

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

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

Какой SSL-сертификат выбрать?

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

Например, если вы просто хотите уберечь пользователей вашего веб-сайта от навязчивых предупреждений браузера о посещении непроверенного сайта, будет достаточно за несколько минут получить простой DV (Domain Validation) сертификат. Если же вы используете свою интернет-площадку для операций, требующих повышенного уровня безопасности данных компании и клиентов — стоит задуматься об EV (Extended Validation) сертификате. А если вы используете не один, а несколько веб-адресов для сайта или сайтов компании — для вас на рынке представлены сертификаты Wildcard и SAN.

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

4 причины установить SSL-сертификат

Безопасность данных

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

Доверие к сайту

Пользователи привыкают, что все крупные проекты используют SSL-сертификаты. Надпись «Защищено» и замочек дают посетителю сайта представление о том, что он и его данные находятся в безопасности.

Поддержка сторонних сервисов

Некоторые платёжные системы (Яндекс.Деньги) и сервисы (Голосовой помощник Google Chrome) работают только с сайтами с HTTPS протоколом. Если специфика вашей работы подразумевает взаимодействие с аналогичными сервисами, рекомендуем вам установить SSL-сертификат.

Фактор ранжирования

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

SSL-сертификат от авторитетного УЦ говорит о надёжной защите пользовательских данных — это не только хороший способ заслужить доверие пользователей и поисковых систем, но и большой вклад в стабильное продвижение и развитие сайта.

Источник

Сертификат проверки подлинности сервера CMG

Применяется к: Configuration Manager (текущая ветвь)

Первый шаг при настройках шлюза управления облаком (CMG) — это получить сертификат проверки подлинности сервера. CmG создает службу HTTPS, к которой подключаются интернет-клиенты. Для создания защищенного канала серверу требуется сертификат проверки подлинности сервера. Для этого вы можете приобрести сертификат у публичного поставщика или выдать его из инфраструктуры общедоступных ключей (PKI).

При создании CMG в консоли Configuration Manager вы предоставляете этот сертификат. Общее имя (CN) этого сертификата определяет имя службы CMG.

Напоминание о терминологии CMG, используемой в этой статье:

Имя развертывания. Первая часть имени службы плюс расположение Azure для развертывания облачной службы. Компонент диспетчера облачных служб точки подключения службы использует это имя при развертывании CMG в Azure. Имя развертывания всегда находится в домене Azure. Расположение Azure зависит от метода развертывания, например:

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

Выберите тип сертификата

Сначала определите, где нужно получить сертификат. Необходимо учитывать несколько факторов.

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

Используйте сертификат от поставщика общедоступных и глобальных доверенных сертификатов.

Windows клиенты включают доверенные органы корневого сертификата (CAs) от этих поставщиков. С помощью сертификата, выданного одним из этих поставщиков, клиенты автоматически доверяют ему.

Этот сертификат связан со стоимостью, определенной поставщику.

Используйте сертификат, выданный корпоративным ЦС из инфраструктуры общедоступных ключей (PKI).

Большинство корпоративных реализации PKI добавляют надежные корневые ЦС в Windows клиентов. Например, если вы используете службы сертификатов Active Directory с групповой политикой. Если вы выдали сертификат проверки подлинности сервера CMG из ЦС, которому ваши клиенты не доверяют автоматически, добавьте надежный корневой сертификат CA в интернет-клиенты.

Если вы планируете установить клиента Configuration Manager из Intune,вы также можете использовать профили сертификатов Intune для предоставления сертификатов для клиентов. Дополнительные сведения см. в странице Настройка профиля сертификата.

Может потребоваться внутренняя стоимость выпуска сертификатов, но внешние затраты, связанные с этим сертификатом, обычно не связаны.

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

Сводное сравнение типов сертификатов

Дополнительные сведения об использовании сертификата подпольной карты с помощью CMG см. в справке Set up a CMG.

Глобально уникальное имя

Набор масштабирования виртуальных машин

На домашней странице портала Azure выберите Создание ресурса в службах Azure.

Поиск набора масштабирования виртуальных машин. Нажмите Создать.

Выберите группу Подписка и Ресурсы, которую вы будете использовать для CMG.

Выберите область, которую вы будете использовать для CMG. Например, (США) Запад США.

Интерфейс отображает, доступно ли доменное имя или уже используется другой службой.

Не создавайте службу на портале, просто используйте этот процесс для проверки доступности имен.

Учетная запись хранилища CMG с поддержкой контента

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

Поиск учетной служба хранилища учетной записи.

Проверьте свое имя в поле служба хранилища учетной записи.

Выпуск сертификата

Сертификат проверки подлинности сервера CMG поддерживает следующие конфигурации:

Длина ключа 2048 или 4096 бит

Этот сертификат поддерживает основных поставщиков хранения для частных ключей сертификата (v3). Дополнительные сведения см. в обзоре сертификатов CNG v3.

Использование сертификата общедоступных поставщиков

Сторонний поставщик сертификатов не может создать сертификат для домена Azure, например, так как корпорация cloudapp.azure.com Майкрософт владеет этими доменами. Вы можете получить сертификат, выданный только для домена, который у вас есть. Основная причина получения сертификата у сторонного поставщика заключается в том, что ваши клиенты уже доверяют корневому сертификату поставщика.

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

Для общего имени сертификата веб-сервера (CN):

Чтобы определить имя службы, примените префикс имени развертывания () к доменным GraniteFalls именем организации ( contoso.com ).

Далее необходимо создать псевдоним DNS CNAME.

Использование корпоративного сертификата PKI

Выдача сертификата веб-сервера из PKI организации зависит от продукта. Инструкции по развертыванию сертификата службы для облачных точек распространения для служб сертификатов Active Directory. Этот процесс обычно применяется к сертификату проверки подлинности сервера CMG.

Для общего имени сертификата веб-сервера (CN):

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

Используйте имя развертывания Azure. Этот параметр не требует псевдонима DNS CNAME. Например:

Если имя развертывания Azure изменится, потребуется перенастановка службы для изменения этого имени службы. Например, если имя службы находится в домене, вы не можете преобразовать классическую облачную службу cloudapp.net CMG в набор масштабов виртуальных машин. Если вы используете доменное имя для имени службы CMG, вы можете обновить DNS CNAME для нового имени развертывания.

Используйте это имя службы для общего имени сертификата (CN).

Создание псевдонима ЦНС CNAME

Если в имени службы CMG используется доменное имя организации (), необходимо создать запись канонического имени GraniteFalls.contoso.com DNS (CNAME). В этом псевдониме имя службы с именем развертывания.

Создание записи CNAME в общедоступных DNS организации. Служба CMG в Azure и все клиенты, которые ее используют, должны устранить имя службы. Например:

Contoso называет их CMG GraniteFalls.

В публичном пространстве имен DNS Contoso администратор DNS создает новую запись CNAME для имени службы с именем contoso.com GraniteFalls.contoso.com развертывания GraniteFalls.WestUS.CloudApp.Azure.Com Azure.

Клиентская политика Configuration Manager включает имя службы GraniteFalls.contoso.com CMG. Клиент решает имя службы с помощью псевдонима CNAME с именем GraniteFalls.WestUS.CloudApp.Azure.Com развертывания. Затем он может разрешить IP-адрес имени развертывания для связи со службой в Azure.

Дальнейшие действия

Продолжить настройку CMG, настроив Azure Active Directory (Azure AD):

Источник

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

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

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

Мы рассмотрим следующие вопросы:

1. Запуск сервера

Для того чтобы организовать работу сервера — нам понадобится следующее:

В данном проекте содержится Maven-обёртка, поэтому запустить его можно и не устанавливая Maven. Тут будут приведены сведения и о стандартных командах, рассчитанных на mvn, и о командах, ориентированных на использование Maven-обёртки.

Если вы хотите запустить этот проект с использованием Java 8 — вы можете переключиться на более старую его версию с использованием нижеприведённой команды.

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

Сервер можно привести в рабочее состояние, вызвав метод main класса App или выполнив следующую команду в корневой директории проекта:

Вот команда, рассчитанная на Maven-обёртку:

2. Отправка приветствия серверу (без шифрования)

Ответ должен выглядеть примерно так:

В клиенте реализован интеграционный тест, основанный на Cucumber. Его можно запустить, обратившись к классу ClientRunnerIT из IDE, или выполнив в корневой директории следующую команду:

При использовании Maven-обёртки это будет такая команда:

Тут имеется файл Hello.feature, который описывает шаги интеграционного теста. Этот файл можно найти в папке ресурсов теста клиентского проекта.

Есть и другой метод запуска и клиента, и сервера. Он представлен следующей командой, выполняемой в корневой директории проекта:

Вариант этой команды для Maven-обёртки выглядит так:

3. Включение HTTPS на сервере (односторонний TLS)

Речь идёт о следующих настройках:

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

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

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

Создать хранилище ключей с открытым и закрытым ключами можно с помощью следующей команды:

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

Замечательно! Только что мы настроили TLS-шифрование соединений между сервером и клиентом! Испытать сервер можно так:

Клиент можно запустить и прибегнув к классу ClientRunnerIT.

В результате можно будет увидеть следующее сообщение:

И приведём её к такому виду:

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

Дело тут в том, что клиент собирается наладить обмен данными по HTTPS. Он, при выполнении процедуры рукопожатия, получает сертификат сервера, который он пока не может распознать. А это значит, что нам ещё нужно создать хранилище TrustStore. В таких хранилищах находятся доверенные сертификаты. Клиент сопоставляет то, что он получает в ходе процедуры рукопожатия, с тем, что есть в TrustStore. Если полученный им сертификат входит в список доверенных сертификатов — процедура продолжается. А прежде чем создавать TrustStore — нужно обзавестись сертификатом сервера.

Экспортировать сертификат сервера можно такой командой:

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

TrustStore для клиента мы создали, но сам клиент пока об этом не знает. А это значит, что клиенту надо сообщить о том, что ему следует пользоваться TrustStore, указав адрес хранилища и пароль. Клиенту надо сообщить и о том, что включена аутентификация. Всё это делается путём приведения файла application.yml клиентского приложения к такому виду:

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

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

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

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

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

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

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

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

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

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

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

5. Установление двустороннего TLS-соединения с использованием доверенного удостоверяющего центра

Есть и другой способ организации двусторонней аутентификации. Он основан на использовании доверенного удостоверяющего центра. У такого подхода есть сильные и слабые стороны.

1. Создание удостоверяющего центра

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

Ещё можно воспользоваться существующим удостоверяющим центром.

2. Создание файла запроса на подпись сертификата

Вот её вариант для сервера:

Вот — эта команда для клиента:

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

3. Подписание сертификата с помощью запроса на подпись сертификата

Вот соответствующая команда для клиента:

Вот команда для сервера:

4. Замена неподписанного сертификата подписанным

Экспортируем подписанный сертификат:

Выполним на клиенте следующие команды:

На сервере выполним такие команды:

5. Организация взаимодействия клиента и сервера, основанного исключительно на доверии к удостоверяющему центру

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

Сделаем это, выполнив на клиенте следующую команду:

На сервере выполним такую команду:

В хранилищах TrustStore всё ещё хранятся собственные сертификаты клиента и сервера. Эти сертификаты нужно удалить.

Выполним на клиенте такую команду:

Вот — команда для сервера:

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

6. Автоматизация различных подходов к аутентификации

Всё, о чём мы говорили выше, можно автоматизировать с помощью скриптов, которые находятся в папке script рассматриваемого нами проекта. Для запуска скриптов можете воспользоваться следующими командами:

Протестированные клиенты

Ниже приведён список протестированных клиентов. Настройки для HTTP-клиента, написанного на чистом Java, можно найти в классе ClientConfig. В директории service нашего проекта содержатся отдельные HTTP-клиенты, выполняющие демонстрационные запросы. Настройки HTTP-клиентов, основанных на Kotlin и Scala, включены в состав проекта в виде вложенных классов. Все примеры клиентов используют одну и ту же базовую конфигурацию SSL, созданную в классе SSLConfig.

Источник