Что такое код asp serverconfigssl128


Содержание

Что такое код asp serverconfigssl128

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

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

Веб-сервер IIS предоставляет SSL как встроенную, готовую к использованию службу. Поскольку SSL работает под HTTP, его применение не изменяет способа работы с HTTP-запросами. Все шифрование и дешифрацию берут на себя функциональные средства SSL программного обеспечения веб-сервера (в данном случае — IIS). Единственное отличие состоит в том, что адрес, защищенный SSL, начинается с https://, а не http://. Трафик SSL также проходит через другой порт (обычно веб-серверы используют порт 443 для SSL-запросов и порт 80 — для обычных запросов).

Чтобы сервер поддерживал SSL-соединения, он должен иметь установленный сертификат X.509 (название X.509 было выбрано для соответствия стандарту каталогов X.500). Чтобы реализовать SSL, понадобится приобрести сертификат, установить его и соответствующим образом сконфигурировать IIS. Все эти шаги подробно описаны в последующих разделах.

Понятие сертификатов

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

Организация приобретает сертификат у известного центра сертификации (Certificate Authority — CA) и устанавливает его на своем веб-сервере. Клиент доверяет CA и потому готов доверять информации сертификата, подписанного CA. Эта модель работает достаточно хорошо, т.к. маловероятно, чтобы злоумышленник решился на дополнительные расходы по приобретению и установке фальсифицированного сертификата. Центр сертификации также сохраняет информацию о каждом зарегистрированном пользователе. Однако наличие сертификата никоим образом не гарантирует надежность сервера, безопасность приложения или легитимность бизнеса. В этом смысле область действия сертификатов фундаментально ограничена.

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

имя, название организации и адрес держателя;

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

даты проверки сертификата;

серийный номер сертификата.

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

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

Что собой представляет SSL

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

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

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

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

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

Клиент отправляет запрос на соединение с сервером.

Сервер подписывает свой сертификат и отправляет его клиенту. Это завершает фазу квитирования («рукопожатия») при обмене.

Клиент проверяет, издан ли сертификат CA, которому он доверяет. Если это так, он переходит к следующему шагу. В сценарии с веб-браузером клиент может предупредить пользователя сообщением о том, что он не распознал CA, и предложить пользователю принять решение о продолжении. Клиент распознает CA, когда его сертификат помещается в хранилище доверенных корневых центров сертификации (Trusted Root Certification Authorities) операционной системы. Сертификаты, находящиеся в этом хранилище, можно просмотреть в Google Chrome щелкнув на кнопке Настройки Показать дополнительные настройки HTTPS/SSL Управление сертификатами Доверенные сертификаты:

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

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

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

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

Клиент шифрует ключ сеанса, используя открытый ключ сервера (из сертификата), и затем отправляет серверу зашифрованный ключ сеанса.

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

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

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

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

Конфигурирование SSL на IIS 8

Прежде всего, понадобится издать сертификат для веб-сервера. Для этого раскройте корневой узел веб-сервера в навигационном дереве консоли управления и выберите средство Server Certificates (Сертификаты сервера), как показано на рисунке ниже:

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

В детальном представлении средства Server Certificates панель задач в правой части консоли управления содержит необходимую задачу для установки серверных сертификатов. Она позволяет автоматически создать запрос сертификата, который можно применить для запроса нового сертификата у CA. Для создания нового запроса просто используется ссылка на задачу Create Certificate Request (Создать запрос сертификата) в панели задач, что позволит создать тот же закодированный в Base64 файл запроса для отправки его в запросе к CA.

После получения сертификата от CA можно завершить выполняющийся запрос, щелкнув на ссылке Complete Certificate Request (Завершить запрос сертификата) в панели задач внутри средства Server Certificates консоли управления. Подобным образом можно запросить и сконфигурировать сертификат SSL для автономного веб-сервера. Если необходимо запросить сертификат для вашего собственного CA, можно воспользоваться , щелкнув на ссылке Create Domain Certificate (Создать сертификат домена). Затем этот сертификат конфигурируется на вашем собственном CA и применяется для подписания изданных им сертификатов.

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

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

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

Конфигурирование привязок для SSL

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

Чтобы применять SSL для приложений, сконфигурированных внутри веб-сайта, понадобится настроить привязку протокола SSL для веб-сайта. Для этого просто выберите веб-сайт (такой как Default Web Site (Веб-сайт по умолчанию)) в навигационном дереве диспетчера служб IIS и щелкните на ссылке Bindings (Привязки) в панели задач справа. Откроется диалоговое окно Web Site Bindings (Привязки сайта), которое позволяет сконфигурировать необходимые привязки. Добавьте новые привязки, чтобы обеспечить доступ к приложению через разные IP-адреса, порты и протоколы. Диалоговое окно Web Site Bindings показано на рисунке ниже:

Щелкнув на кнопке Add (Добавить), можно добавить новую привязку веб-сайта. Щелкнув на кнопке Edit (Изменить), можно модифицировать существующую привязку в списке. На рисунке ниже показана конфигурация привязки для включения SSL на веб-сайте:

Легко заметить, что протокол сконфигурирован как https, запущенный на IP-адресе по умолчанию для сервера, с использованием порта 443 для SSL-доступа (который является портом по умолчанию для SSL). Далее в раскрывающемся списке в нижней части окна можно выбрать сертификат, используемый для трафика SSL на выбранном веб-сайте.

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

Шифрование информации с помощью SSL

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

Здесь можно указать, требуется ли SSL-кодирование для выбранного веб-приложения и нужны ли клиентские сертификаты для аутентификации пользователей. При использовании аутентификации с применением клиентского сертификата потребуется сконфигурировать отображение сертификатов на пользователей, чтобы они были в конечном итоге аутентифицированы IIS при извлечении определенного сертификата.

Эти отображения должны быть настроены в разделе внутри раздела конфигурационного файла web.config. За дополнительной информацией об отображении клиентских сертификатов обращайтесь к документации Microsoft, доступной в MSDN.

После включения SSL для веб-сайта можно проверить его работоспособность, запустив в браузере:

Обратите внимание, что браузер Google Chrome отобразил перечеркнутую надпись https. Это связано с тем, что в этом примере я использовал самоподписанный сертификат, который не подтвержден CA. Это удобно когда вы разрабатываете сайт и вам нужно просто протестировать его при работе с SSL. Однако в развернутом веб-сайте нужно будет приобрести лицензированный сертификат в компаниях CA. Например, ниже показан сайт Сбербанка, который использует лицензированный сертификат, обратите внимание, что Google Chrome извлекает информацию о названии организации из сертификата:

ИТ База знаний

ShareIT — поделись знаниями!

Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Похожее и популярное

Пошаговый ввод в домен Windows 10

Apache или IIS – сравнение и преимущества

Погружение в Iptables – теория и настройка

Как восстановить пароль от root в CentOS 7

Установка SSL сертификата на IIS – сервере

Простой способ сделать HTTPS

2 минуты чтения

Подключение по HTTPS – признак надежности и безопасной передачи данных. Чтобы реализовать безопасное подключение по HTTPS, нужно иметь SSL сертификат. В статье расскажем, как сгенерировать самоподписанный сертификат (self signed), а также как импортировать файл сертификата в формате .pfx. После, покажем установку и применение сертификатов к сайту в веб – сервере Microsoft IIS (Internet Information Services).

В статье мы используем IIS (Internet Information Services) версии 10.0.14393.0

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

Открываем IIS Manager. Далее, в меню слева (раздел Connections) нажимаем на корень (как правило это хостнейм вашей машины) и в открывшейся в центральной части рабочей области дважды кликаем левой кнопкой на Server Certificates:

IIS так же можно запустить из под Administrative Tools

В правом меню видим меню навигации Actions. Нажимаем на Create Self-Signed Certificate…. Открывается следующее окно:

Указываем имя для нашего сертификата и нажимаем «OK». Далее, выбираем наш сайт в меню слева:

Как только нажали на наш сайт, выбираем в правом поле меню Bindings, далее, редактируем текущее HTTPS подключение (по 443 порту) нажав Edit и выбираем сгенерированный самоподписанный SSL сертификат.

Нажимаем ОК. После, открываем командную строку cmd и перезагружаем IIS сервер командой:

Кстати, для рестарта, можно использовать просто команду iisreset без ключа restart

Импорт сертификата .pfx

Аналогично как и с самоподписанным сертификатом (раздел Connections) нажимаем на корень и кликаем на Server Certificates. Далее, справа, нажимаем Import:

Открываем на .pfx файл:

Когда для вас создавали .pfx, на него установили пароль – введите этот пароль в поле ниже и нажмите OK.

Далее, все стандартно – выбираем сайт слева → Bindings → редактируем текущее подключение по 443 порту → выбираем сертификат, который только что сделали в разделе SSL certificate → нажимаем OK.

По окончанию, снова рестартуем IIS:

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас :( Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации :) Просто оставьте свои данные в форме ниже.

Что такое код asp serverconfigssl128

The ServerConfigFlags property contains flags, as seen in the Flags section, that specify the server configuration established at startup.

You can configure this property at the following locations in the IIS metabase.

Metabase Path

IIS Admin Object Type

[IIS 5.0][IIS 5.1][IIS 6.0]

A value of true indicates that the server can perform automatic anonymous user password synchronization between the Web authentication manager (WAM) and the Microsoft Windows authentication manager.

8 (hex 0x00000008)

[IIS 5.0][IIS 5.1][IIS 6.0]

A value of true indicates that 128-bit Secure Sockets Layer (SSL) processing is installed on the server.

2 (hex 0x00000002)

[IIS 5.0][IIS 5.1][IIS 6.0]

A value of true indicates that 40-bit Secure Sockets Layer (SSL) processing is installed on the server.

1 (hex 0x00000001)

[IIS 5.0][IIS 5.1][IIS 6.0]

A value of true indicates that the locality allows encryption.

4 (hex 0x00000004)

Client: Requires Windows XP Professional, Windows 2000 Professional, or Windows NT Workstation 4.0.

Server: Requires Windows Server 2003, Windows 2000 Server, or Windows NT Server 4.0.

Настройка защиты данных ASP.NET Core Configure ASP.NET Core Data Protection

При инициализации системы защиты данных применяются параметры по умолчанию , основанные на рабочей среде. When the Data Protection system is initialized, it applies default settings based on the operational environment. Эти параметры обычно подходят для приложений, выполняющихся на одном компьютере. These settings are generally appropriate for apps running on a single machine. Существуют случаи, когда разработчику может потребоваться изменить параметры по умолчанию. There are cases where a developer may want to change the default settings:

  • Приложение распределено между несколькими компьютерами. The app is spread across multiple machines.
  • По соображениям соответствия. For compliance reasons.

В этих сценариях система защиты данных предоставляет богатый API настройки. For these scenarios, the Data Protection system offers a rich configuration API.

Как и файлы конфигурации, кольцо ключа защиты данных следует защищать с помощью соответствующих разрешений. Similar to configuration files, the data protection key ring should be protected using appropriate permissions. Вы можете выбрать шифрование неактивных ключей, но это не помешает злоумышленникам создавать новые ключи. You can choose to encrypt keys at rest, but this doesn’t prevent attackers from creating new keys. Таким образом, безопасность приложения затронута. Consequently, your app’s security is impacted. Доступ к расположению хранилища, настроенному с помощью защиты данных, должен иметь только само приложение, аналогично тому, как вы защищаете файлы конфигурации. The storage location configured with Data Protection should have its access limited to the app itself, similar to the way you would protect configuration files. Например, если вы решили сохранить ключ на диске, используйте разрешения файловой системы. For example, if you choose to store your key ring on disk, use file system permissions. Убедитесь, что только удостоверение, под которым выполняется веб-приложение, имеет доступ на чтение, запись и создание этого каталога. Ensure only the identity under which your web app runs has read, write, and create access to that directory. При использовании хранилища больших двоичных объектов Azure только веб-приложение должно иметь возможность чтения, записи или создания новых записей в хранилище больших двоичных объектов и т. д. If you use Azure Blob Storage, only the web app should have the ability to read, write, or create new entries in the blob store, etc.

Метод расширения адддатапротектион возвращает идатапротектионбуилдер. The extension method AddDataProtection returns an IDataProtectionBuilder. IDataProtectionBuilder предоставляет методы расширения, которые можно объединить в цепочку для настройки параметров защиты данных. IDataProtectionBuilder exposes extension methods that you can chain together to configure Data Protection options.

протекткэйсвисазурекэйваулт ProtectKeysWithAzureKeyVault

Чтобы сохранить ключи в Azure Key Vault, настройте систему с помощью протекткэйсвисазурекэйваулт в классе Startup : To store keys in Azure Key Vault, configure the system with ProtectKeysWithAzureKeyVault in the Startup class:

Задайте место хранения ключевых звонков (например, персисткэйстоазуреблобстораже). Set the key ring storage location (for example, PersistKeysToAzureBlobStorage). Расположение должно быть задано, поскольку вызов ProtectKeysWithAzureKeyVault реализует иксмленкриптор , который отключает автоматические параметры защиты данных, включая место хранения ключевых звонков. The location must be set because calling ProtectKeysWithAzureKeyVault implements an IXmlEncryptor that disables automatic data protection settings, including the key ring storage location. В предыдущем примере для сохранения ключа используется хранилище BLOB-объектов Azure. The preceding example uses Azure Blob Storage to persist the key ring. Дополнительные сведения см. в разделе поставщики хранилища Key: службы хранилища Azure. For more information, see Key storage providers: Azure Storage. Вы также можете сохранить ключ в локальной системе с помощью персисткэйстофилесистем. You can also persist the key ring locally with PersistKeysToFileSystem.

@No__t-0 — это идентификатор ключа хранилища ключей, используемый для шифрования ключей. The keyIdentifier is the key vault key identifier used for key encryption. Например, ключ, созданный в хранилище ключей с именем dataprotection в contosokeyvault , имеет идентификатор ключа https://contosokeyvault.vault.azure.net/keys/dataprotection/ . For example, a key created in key vault named dataprotection in the contosokeyvault has the key identifier https://contosokeyvault.vault.azure.net/keys/dataprotection/ . Укажите приложение с ключом распаковки и разрешениями на ключ для хранилища ключей. Provide the app with Unwrap Key and Wrap Key permissions to the key vault.

ProtectKeysWithAzureKeyVault перегрузок: ProtectKeysWithAzureKeyVault overloads:

  • Протекткэйсвисазурекэйваулт (идатапротектионбуилдер, KeyVaultClient, String) позволяет использовать KeyVaultClient для обеспечения возможности использования хранилища ключей системой защиты данных. ProtectKeysWithAzureKeyVault(IDataProtectionBuilder, KeyVaultClient, String) permits the use of a KeyVaultClient to enable the data protection system to use the key vault.
  • Протекткэйсвисазурекэйваулт (идатапротектионбуилдер, String, String, X509Certificate2) позволяет использовать ClientId и сертификат X509Certificate , чтобы система защиты данных использовала хранилище ключей. ProtectKeysWithAzureKeyVault(IDataProtectionBuilder, String, String, X509Certificate2) permits the use of a ClientId and X509Certificate to enable the data protection system to use the key vault.
  • Протекткэйсвисазурекэйваулт (идатапротектионбуилдер, строка, строка, строка) позволяет использовать ClientId и ClientSecret , чтобы система защиты данных использовала хранилище ключей. ProtectKeysWithAzureKeyVault(IDataProtectionBuilder, String, String, String) permits the use of a ClientId and ClientSecret to enable the data protection system to use the key vault.

персисткэйстофилесистем PersistKeysToFileSystem

Чтобы хранить ключи в общем UNC-ресурсе, а не в расположении % LocalAppData% по умолчанию, настройте систему с помощью персисткэйстофилесистем: To store keys on a UNC share instead of at the %LOCALAPPDATA% default location, configure the system with PersistKeysToFileSystem:

Илон Маск рекомендует:  Что такое код fbsql_field_name

Если изменить расположение сохраняемости ключей, система больше не шифрует неактивных ключей автоматически, так как не знает, является ли DPAPI подходящим механизмом шифрования. If you change the key persistence location, the system no longer automatically encrypts keys at rest, since it doesn’t know whether DPAPI is an appropriate encryption mechanism.

Протекткэйсвис @ no__t-0 ProtectKeysWith*

Можно настроить систему для защиты неактивных ключей, вызвав любой из API настройки протекткэйсвис @ no__t-1 . You can configure the system to protect keys at rest by calling any of the ProtectKeysWith* configuration APIs. Рассмотрим приведенный ниже пример, в котором ключи хранятся в общем UNC-ресурсе и шифруются с помощью определенного сертификата X. 509: Consider the example below, which stores keys on a UNC share and encrypts those keys at rest with a specific X.509 certificate:

В ASP.NET Core 2,1 или более поздней версии можно предоставить X509Certificate2 протекткэйсвисцертификате, например сертификат, загруженный из файла: In ASP.NET Core 2.1 or later, you can provide an X509Certificate2 to ProtectKeysWithCertificate, such as a certificate loaded from a file:

Дополнительные примеры и обсуждение встроенных механизмов шифрования ключей см. в разделе неактивных ключей шифрования . See Key Encryption At Rest for more examples and discussion on the built-in key encryption mechanisms.

унпротекткэйсвисаницертификате UnprotectKeysWithAnyCertificate

В ASP.NET Core 2,1 или более поздней версии можно поворачивать сертификаты и расшифровывать ключи в неактивном виде, используя массив сертификатов X509Certificate2 с унпротекткэйсвисаницертификате: In ASP.NET Core 2.1 or later, you can rotate certificates and decrypt keys at rest using an array of X509Certificate2 certificates with UnprotectKeysWithAnyCertificate:

сетдефаулткэйлифетиме SetDefaultKeyLifetime

Чтобы настроить систему на использование времени жизни ключа, равного 14 дням, вместо 90 дней по умолчанию, используйте сетдефаулткэйлифетиме: To configure the system to use a key lifetime of 14 days instead of the default 90 days, use SetDefaultKeyLifetime:

SetApplicationName SetApplicationName

По умолчанию система защиты данных изолирует приложения друг от друга на основе их корневых путей к содержимому , даже если они совместно используют один и тот же физический репозиторий ключей. By default, the Data Protection system isolates apps from one another based on their content root paths, even if they’re sharing the same physical key repository. Это предотвращает понимание приложениями защищенных полезных данных друг друга. This prevents the apps from understanding each other’s protected payloads.

Для совместного использования защищенных полезных данных между приложениями: To share protected payloads among apps:

  • Настройте SetApplicationName в каждом приложении с тем же значением. Configure SetApplicationName in each app with the same value.
  • Используйте одну и ту же версию стека API для защиты данных в приложениях. Use the same version of the Data Protection API stack across the apps. Выполните одно из следующих действий в файлах проекта приложений: Perform either of the following in the apps’ project files:
    • Сослаться на ту же версию общей платформы через метапакет Microsoft. AspNetCore. app. Reference the same shared framework version via the Microsoft.AspNetCore.App metapackage.
    • Сослаться на ту же версию пакета защиты данных . Reference the same Data Protection package version.

дисаблеаутоматиккэйженератион DisableAutomaticKeyGeneration

У вас может быть сценарий, в котором приложение не должно автоматически выполнять откат ключей (создание новых ключей) по мере их истечения. You may have a scenario where you don’t want an app to automatically roll keys (create new keys) as they approach expiration. Одним из примеров могут быть приложения, настроенные в связи «первичная/вторичная», в которой только основное приложение отвечает на вопросы управления ключами, а дополнительные приложения просто имеют доступное только для чтения представление круга ключей. One example of this might be apps set up in a primary/secondary relationship, where only the primary app is responsible for key management concerns and secondary apps simply have a read-only view of the key ring. Вторичные приложения можно настроить так, чтобы они обрабатывали ключевое кольцо как доступное только для чтения, настроив систему с DisableAutomaticKeyGeneration: The secondary apps can be configured to treat the key ring as read-only by configuring the system with DisableAutomaticKeyGeneration:

Изоляция отдельных приложений Per-application isolation

Когда система защиты данных предоставляется узлом ASP.NET Core, она автоматически изолирует приложения друг от друга, даже если эти приложения выполняются в той же учетной записи рабочего процесса и используют один и тот же материал основного ключа. When the Data Protection system is provided by an ASP.NET Core host, it automatically isolates apps from one another, even if those apps are running under the same worker process account and are using the same master keying material. Это в некоторой степени аналогично модификатору IsolateApps из элемента System. Web . This is somewhat similar to the IsolateApps modifier from System.Web’s element.

Механизм изоляции работает путем рассмотрения каждого приложения на локальном компьютере в качестве уникального клиента, поэтому IDataProtector с корнем для любого конкретного приложения автоматически включает идентификатор приложения в качестве дискриминатора. The isolation mechanism works by considering each app on the local machine as a unique tenant, thus the IDataProtector rooted for any given app automatically includes the app ID as a discriminator. Уникальный идентификатор приложения — это физический путь приложения: The app’s unique ID is the app’s physical path:

  • Для приложений, размещенных в службах IIS, уникальный идентификатор — это физический путь IIS приложения. For apps hosted in IIS, the unique ID is the IIS physical path of the app. Если приложение развернуто в среде веб-фермы, это значение является стабильным при условии, что среды IIS настроены одинаково на всех компьютерах в веб-ферме. If an app is deployed in a web farm environment, this value is stable assuming that the IIS environments are configured similarly across all machines in the web farm.
  • Для автономных приложений, работающих на сервере Kestrel, уникальный идентификатор — это физический путь к приложению на диске. For self-hosted apps running on the Kestrel server, the unique ID is the physical path to the app on disk.

Уникальный идентификатор предназначен для того, чтобы выдерживать сброс @ no__t-0both отдельного приложения и самого компьютера. The unique identifier is designed to survive resets—both of the individual app and of the machine itself.

Этот механизм изоляции предполагает, что приложения не являются вредоносными. This isolation mechanism assumes that the apps are not malicious. Вредоносное приложение всегда может повлиять на любое другое приложение, выполняемое в той же учетной записи рабочего процесса. A malicious app can always impact any other app running under the same worker process account. В общей среде размещения, в которой приложения взаимно не считаются доверенными, поставщик услуг размещения должен принять меры по обеспечению изоляции на уровне ОС между приложениями, включая разделение базовых хранилищ ключей приложений. In a shared hosting environment where apps are mutually untrusted, the hosting provider should take steps to ensure OS-level isolation between apps, including separating the apps’ underlying key repositories.

Если система защиты данных не предоставляется узлом ASP.NET Core (например, если создать экземпляр с помощью изоляции приложения DataProtectionProvider ) по умолчанию отключена. If the Data Protection system isn’t provided by an ASP.NET Core host (for example, if you instantiate it via the DataProtectionProvider concrete type) app isolation is disabled by default. Если изоляция приложений отключена, все приложения, которые поддерживаются одним и тем же материалом для ключа, могут совместно использовать полезные данные, если они предоставляют соответствующие цели. When app isolation is disabled, all apps backed by the same keying material can share payloads as long as they provide the appropriate purposes. Чтобы обеспечить изоляцию приложений в этой среде, вызовите метод SetApplicationName объекта конфигурации и укажите уникальное имя для каждого приложения. To provide app isolation in this environment, call the SetApplicationName method on the configuration object and provide a unique name for each app.

Изменение алгоритмов с помощью Усекриптографикалгорисмс Changing algorithms with UseCryptographicAlgorithms

Стек защиты данных позволяет изменить алгоритм по умолчанию, используемый созданными новыми ключами. The Data Protection stack allows you to change the default algorithm used by newly-generated keys. Самый простой способ сделать это — вызвать усекриптографикалгорисмс из обратного вызова конфигурации: The simplest way to do this is to call UseCryptographicAlgorithms from the configuration callback:

По умолчанию EncryptionAlgorithm имеет значение AES-256-CBC, а Валидатионалгорисм по умолчанию — HMACSHA256. The default EncryptionAlgorithm is AES-256-CBC, and the default ValidationAlgorithm is HMACSHA256. Политика по умолчанию может быть задана системным администратором с помощью политики на уровне компьютера, но явный вызов UseCryptographicAlgorithms переопределяет политику по умолчанию. The default policy can be set by a system administrator via a machine-wide policy, but an explicit call to UseCryptographicAlgorithms overrides the default policy.

Вызов UseCryptographicAlgorithms позволяет указать нужный алгоритм из предопределенного встроенного списка. Calling UseCryptographicAlgorithms allows you to specify the desired algorithm from a predefined built-in list. Не нужно беспокоиться о реализации алгоритма. You don’t need to worry about the implementation of the algorithm. В приведенном выше сценарии система защиты данных пытается использовать реализацию CNG AES при запуске в Windows. In the scenario above, the Data Protection system attempts to use the CNG implementation of AES if running on Windows. В противном случае он возвращается к управляемому классу System. Security. Cryptography. AES . Otherwise, it falls back to the managed System.Security.Cryptography.Aes class.

Реализацию можно указать вручную с помощью вызова усекустомкриптографикалгорисмс. You can manually specify an implementation via a call to UseCustomCryptographicAlgorithms.

Изменение алгоритмов не влияет на существующие ключи в кольце ключа. Changing algorithms doesn’t affect existing keys in the key ring. Он влияет только на вновь созданные ключи. It only affects newly-generated keys.

Указание пользовательских управляемых алгоритмов Specifying custom managed algorithms

Чтобы указать пользовательские управляемые алгоритмы, создайте экземпляр манажедаусентикатеденкрипторконфигуратион , указывающий на типы реализации: To specify custom managed algorithms, create a ManagedAuthenticatedEncryptorConfiguration instance that points to the implementation types:

Чтобы указать пользовательские управляемые алгоритмы, создайте экземпляр манажедаусентикатеденкриптионсеттингс , указывающий на типы реализации: To specify custom managed algorithms, create a ManagedAuthenticatedEncryptionSettings instance that points to the implementation types:

Как правило, свойства *Type должны указывать на конкретные, допускающие создание экземпляров (с помощью общедоступного конструктора без параметров) SymmetricAlgorithm и KeyedHashAlgorithm, несмотря на то, что системные специальные параметры, например typeof(Aes) для удобным. Generally the *Type properties must point to concrete, instantiable (via a public parameterless ctor) implementations of SymmetricAlgorithm and KeyedHashAlgorithm, though the system special-cases some values like typeof(Aes) for convenience.

SymmetricAlgorithm должен иметь длину ключа ≥ 128 бит и размер блока ≥ 64 бит, и он должен поддерживать шифрование в режиме CBC с заполнением PKCS #7. The SymmetricAlgorithm must have a key length of ≥ 128 bits and a block size of ≥ 64 bits, and it must support CBC-mode encryption with PKCS #7 padding. KeyedHashAlgorithm должен иметь размер дайджеста > = 128 бит и должен поддерживать ключи длиной, равную длине дайджеста хэш-алгоритма. The KeyedHashAlgorithm must have a digest size of >= 128 bits, and it must support keys of length equal to the hash algorithm’s digest length. KeyedHashAlgorithm строго не обязательно должен быть HMAC. The KeyedHashAlgorithm isn’t strictly required to be HMAC.

Указание пользовательских алгоритмов CNG Windows Specifying custom Windows CNG algorithms

Чтобы указать пользовательский алгоритм CNG Windows с помощью шифрования в режиме CBC с проверкой HMAC, создайте экземпляр кнгкбкаусентикатеденкрипторконфигуратион , содержащий алгоритмную информацию: To specify a custom Windows CNG algorithm using CBC-mode encryption with HMAC validation, create a CngCbcAuthenticatedEncryptorConfiguration instance that contains the algorithmic information:

Чтобы указать пользовательский алгоритм CNG Windows с помощью шифрования в режиме CBC с проверкой HMAC, создайте экземпляр кнгкбкаусентикатеденкриптионсеттингс , содержащий алгоритмную информацию: To specify a custom Windows CNG algorithm using CBC-mode encryption with HMAC validation, create a CngCbcAuthenticatedEncryptionSettings instance that contains the algorithmic information:

Алгоритм блочного блочного шифра должен иметь длину ключа > = 128 бит, размер блока > = 64 бит и должен поддерживать шифрование в режиме CBC с использованием дополнений PKCS #7. The symmetric block cipher algorithm must have a key length of >= 128 bits, a block size of >= 64 bits, and it must support CBC-mode encryption with PKCS #7 padding. Хэш-алгоритм должен иметь размер дайджеста > = 128 бит и должен поддерживать открытие с флагом BCRYPT @ no__t-0ALG @ no__t-1HANDLE @ no__t-2HMAC @ no__t-3FLAG. The hash algorithm must have a digest size of >= 128 bits and must support being opened with the BCRYPT_ALG_HANDLE_HMAC_FLAG flag. Свойства *Provider могут иметь значение null, чтобы использовать поставщик по умолчанию для указанного алгоритма. The *Provider properties can be set to null to use the default provider for the specified algorithm. Дополнительные сведения см. в документации по BCryptOpenAlgorithmProvider . See the BCryptOpenAlgorithmProvider documentation for more information.

Чтобы указать пользовательский алгоритм CNG Windows, используя Галоис/шифрование в режиме счетчика с проверкой, создайте экземпляр кнггкмаусентикатеденкрипторконфигуратион , содержащий алгоритмную информацию: To specify a custom Windows CNG algorithm using Galois/Counter Mode encryption with validation, create a CngGcmAuthenticatedEncryptorConfiguration instance that contains the algorithmic information:

Чтобы указать пользовательский алгоритм CNG Windows, используя Галоис/шифрование в режиме счетчика с проверкой, создайте экземпляр кнггкмаусентикатеденкриптионсеттингс , содержащий алгоритмную информацию: To specify a custom Windows CNG algorithm using Galois/Counter Mode encryption with validation, create a CngGcmAuthenticatedEncryptionSettings instance that contains the algorithmic information:

Алгоритм симметричного блочного шифра должен иметь длину ключа > = 128 бит, размер блока ровно 128 бит и должен поддерживать шифрование GCM. The symmetric block cipher algorithm must have a key length of >= 128 bits, a block size of exactly 128 bits, and it must support GCM encryption. Чтобы использовать поставщик по умолчанию для указанного алгоритма, можно задать для свойства енкриптионалгорисмпровидер значение null. You can set the EncryptionAlgorithmProvider property to null to use the default provider for the specified algorithm. Дополнительные сведения см. в документации по BCryptOpenAlgorithmProvider . See the BCryptOpenAlgorithmProvider documentation for more information.

Указание других пользовательских алгоритмов Specifying other custom algorithms

Несмотря на то, что не предоставляется в качестве API первого класса, система защиты данных достаточно расширяема, чтобы можно было указать практически любой тип алгоритма. Though not exposed as a first-class API, the Data Protection system is extensible enough to allow specifying almost any kind of algorithm. Например, можно хранить все ключи, содержащиеся в аппаратном модуле безопасности (HSM), и обеспечивать пользовательскую реализацию подпрограмм шифрования и расшифровки. For example, it’s possible to keep all keys contained within a Hardware Security Module (HSM) and to provide a custom implementation of the core encryption and decryption routines. Дополнительные сведения см. в статье иаусентикатеденкриптор в разделе расширение криптографии Core . See IAuthenticatedEncryptor in Core cryptography extensibility for more information.

Сохранение ключей при размещении в контейнере DOCKER Persisting keys when hosting in a Docker container

При размещении в контейнере DOCKER ключи должны поддерживаться в одном из следующих: When hosting in a Docker container, keys should be maintained in either:

  • Папка, которая является томом DOCKER, который сохраняется за пределами времени существования контейнера, например общего тома или тома, подключенного к узлу. A folder that’s a Docker volume that persists beyond the container’s lifetime, such as a shared volume or a host-mounted volume.
  • Внешний поставщик, например Azure Key Vault или Redis. An external provider, such as Azure Key Vault or Redis.

Сохранение ключей с помощью Redis Persisting keys with Redis

Для хранения ключей следует использовать только версии Redis, поддерживающие сохраняемость данных Redis . Only Redis versions supporting Redis Data Persistence should be used to store keys. Хранилище BLOB-объектов Azure является постоянным и может использоваться для хранения ключей. Azure Blob storage is persistent and can be used to store keys. Дополнительные сведения см. в разделе проблема GitHub. For more information, see this GitHub issue.

How to enable SSL_RSA_WITH_RC4_128_MD5 cipher in java 8 server?

I have an test environment client application which uses SSLv3 and SSL_RSA_WITH_RC4_128_MD5 cipher suite. I need to use SSLv3 client because it cannot be changed now. I enabled Java server (running on java 8 JVM) to allow SSLv3 and RC4 cipher suites by editing java.security file. I know that java 8 has disabled RC4 for security reasons.

When I run the java 8 client to connect to java 8 server with SSLv3 and SSL_RSA_WITH_RC4_128_MD5 cipher suite, I am getting error «SSLHandshakeException:no cipher suites in common» because the client is sending SSL_RSA_WITH_RC4_128_MD5 and Server does not know about SSL_RSA_WITH_RC4_128_MD5.

java 8 is supposed to have enabled SSL_RSA_WITH_RC4_128_MD5 cipher suite by default. see Cipher suites in Java 8

if I run the server in java 6 then client can connect and everything works. I would like to use java 8 in the server.

is there a way to enable SSL_RSA_WITH_RC4_128_MD5 cipher suite in Java 8.

Проверка параметров SSL/TLS-серверов в консоли FreeBSD

Если Вы захотите выяснить параметры SSL/TLS некоторого публичного HTTPS-сервера, Вам поможет не нуждающийся в представлении SSL Server Test от Qualys SSL Labs. А что делать, если потребуется проверить аналогичные параметры HTTPS-серверов, доступ к которым ограничен, или серверов FTP, IRC, IMAP, POP3, SMTP, XMPP и PostgreSQL, которые поддерживают SSL/TLS? Не думаю, что Вы сильно удивитесь, если я предложу воспользоваться популярными в мире Linux и Unix инструментами, к числу которых относятся OpenSSL, nmap и SSLScan.

Какие параметры мы будем проверять?

Эта заметка описывает относительно простые в использовании и доступные в большинстве операционных систем семейства Linux / Unix способы проверки таких параметров SSL/TLS-серверов, как свойства и отсутствие ошибок установки их собственных SSL-сертификатов (далее — сертификатов), свойства и корректность работы цепочек сертификатов, в состав которых входят серверные сертификаты, поддержка TLS-расширений Server Name Indication и OCSP stapling, поддержка SSL/TLS-протоколов (далее — протоколов), а также соответствующих им наборов шифров, и, наконец, наличие некоторых опасных уязвимостей. Невзирая на то, что для решения перечисленных задач хватит функциональности OpenSSL, я рекомендую Вам не игнорировать соответствующие возможности nmap и SSLScan, использование которых не требует специальной подготовки, а результаты работы предоставляются в более простой для восприятия форме.

Подготовка OpenSSL, nmap и SSLScan

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

Следует отметить, что выбор опции [X] ZLIB zlib compression support (добавление WITH=»ZLIB» в команду make install ) не является обязательным, но он будет полезен в том случае, если Вы планируете не только проверять параметры SSL/TLS-серверов, но и тестировать их на наличие уязвимостей.
После завершения установки OpenSSL нужно добавить в файл /etc/make.conf строку:

Теперь устанавливаемые порты будут использовать обновленный OpenSSL (порты, установленные до обновления OpenSSL, придется пересобрать).
Для установки nmap и SSLScan необходимо выполнить команды:

В связи с тем, что браузеры и другие SSL/TLS-клиенты используют корневые сертификаты из своих собственных хранилищ доверенных корневых сертификатов, поставщики сертификатов не рекомендуют устанавливать корневые сертификаты на серверы. Для избавления от проблем, связанных с отсутствием тех или иных корневых сертификатов, входящих в состав цепочек сертификации, достаточно установить порт security/ca_root_nss командами:

После завершения установки / переустановки перечисленных портов можно приступать к проверке параметров TLS/SSL-серверов.

Общий случай использования команды openssl s_client

Команда openssl s_client предназначена для установки соединения с удаленным SSL/TLS-сервером, передачи ему команд, приема результатов их выполнения и отображения информации об используемых параметрах SSL/TLS. Если команда не содержит ключ -connect host:port , выполняется подключение к серверу localhost:4433 . По умолчанию сведения о параметрах SSL/TLS имеют среднюю детальность (на мой взгляд, она устроит подавляющее большинство системных администраторов), если добавить ключ -brief — минимальную, ключи -debug и / или -tlsextdebug — повышенную. В общем случае для проверки параметров какого-либо SSL/TLS-сервера достаточно указать команду s_client и единственный ключ -connect host:port . Например, команда:

отобразит примерно такие сведения о HTTPS-сервере, на котором размещается мой персональный сайт (для сокращения размера данной заметки значительная часть содержимого сертификата сервера (Server certificate) и мандата сессии TLS (TLS session ticket) заменена точками):

Представленное сообщение содержит следующую информацию (для повышения удобства восприятия соответствующие группы строк выделены):
Строка 1 подтверждает факт установки соединения (CONNECTED);
Строки 2-8 содержат результат проверки цепочки сертификатов, использованной при установке соединения. Для каждого сертификата отображается глубина в цепочке сертификатов (depth), страна (C), организация (O), подразделение (OU), имя (CN) субъекта сертификации и результат проверки (verify return). Отсутствие части перечисленных сведений для бесплатного сертификата сервера связано с тем, что он не подтверждает принадлежность домена какой-либо организации;
Строки 9-14 отображают содержимое цепочки сертификатов, установленной на сервер (Certificate chain). Для каждого сертификата отображается назначение (s), содержащее, такие сведения, как страна (C), организация (O), подразделение (OU), имя (CN) субъекта сертификации и аналогичная информация об издателе (i). По описанной в предыдущем пункте причине для сертификата сервера отображаются только страна и имя субъекта сертификации;
Строки 15-23 содержат текст сертификата сервера в формате PEM, его назначение (subject) и информацию об издателе (issuer);
Строки 24-55 отображают подробную информацию как о параметрах сервера, так и о параметрах текущего соединения. В них можно увидеть, что используется современный (New) протокол TLSv1.2 и набор шифров (Cipher) ECDHE-RSA-AES256-GCM-SHA384 (такая аббревиатура обозначает, что для генерации сеансового ключа используется алгоритм Диффи-Хеллмана на эллиптических кривых, для аутентификации сервера — алгоритм RSA, для шифрования трафика — алгоритм AES с длиной ключа 256 бит в режиме GCM, для контроля целостности (MAC) — алгоритм SHA384), публичный ключ сервера (Server public key) имеет длину 2048 бит, сервер поддерживает возобновление TLS-сессии (Secure Renegotiation), не поддерживает сжатие (Compression) и т.д. и т.п.
В связи с тем, что даже минимальный вариант команды openssl s_client предоставляет внушительные объемы информации о параметрах SSL/TLS-серверов, имеет смысл внимательнее разобраться в том, какие сведения нам понадобятся, и как использовать их для решения наших задач.

Проверка сертификата сервера и цепочки сертификатов с помощью openssl s_client

Для проверки параметров и отсутствия ошибок установки сертификата сервера, а также корректности работы цепочки сертификатов, частью которой он является, подойдет все та же команда openssl s_client . В рассмотренном выше примере показан результат ее работы для случая, когда сертификат сервера установлен корректно, и цепочка сертификатов не содержит ошибок. Например, при подключении к SSL/TLS-серверу с просроченным самоподписным сертификатом будут отображены примерно такие сведения (сообщения об ошибках выделены, «лишние» данные заменены точками):

Для указания глубины верификации (или максимальной длины) цепочки сертификатов и включения проверки сертификата сервера необходимо добавить ключ -verify depth ( depth — глубина проверки). В настоящее время проверка продолжается при появлении сообщений об ошибках, что позволяет диагностировать все проблемы в цепочке сертификатов. При этом возникает побочный эффект, который заключается в том, что соединение не обрывается, даже если сертификат сервера признается некорректным.
Для прекращения проверки цепочки сертификатов при наличии критических ошибок следует указать ключ -verify_return_error . Например, его применение при проверке SSL/TLS-сервера с просроченным самоподписным сертификатом заметно сократит результат проверки цепочки сертификатов:

Для просмотра содержимого всех сертификатов цепочки сертификатов, а не только сертификата сервера нужно добавить ключ -showcerts .
Для проверки цепочки сертификатов, корневой сертификат которой отсутствует в хранилище доверенных корневых сертификатов, необходимо применить один из ключей -CApath или -CAfile . Первый ключ позволяет указать путь к папке, имеющей формат hash, с корневым сертификатом, второй — имя файла в формате PEM с корневым сертификатом. Описание формата hash и список ключей, позволяющих выполнять дополнительные проверки параметров сертификата сервера, можно найти в документе verify.

Проверка поддержки технологии Server Name Indication с помощью openssl s_client

Для проверки того, что SSL/TLS-сервер поддерживает технологию SNI (Server Name Indication) придется немного усложнить команду openssl s_client путем добавления ключей -servername (он включает TLS-расширение SNI путем изменения соответствующих полей сообщения ClientHello), а также -tlsextdebug (он включает отображение дампа TLS-расширений, полученных с сервера). В связи с тем, что из весьма внушительного объема предоставляемых данных нам будет нужна единственная строка с текстом server name, имеет смысл найти ее с помощью grep(1) и отправить все «лишние» сведения, отображаемые через stderr , в /dev/null (учтите, что перенаправлении данных в /dev/null может привести к перегреву центрального процессора �� ). С учетом сказанного для проверки поддержки SNI, например, на HTTPS-сервере google.com следует выполнить команду:

Если HTTPS-сервер поддерживает технологию SNI (google.com ее поддерживает), будет отображено примерно такое сообщение:

Илон Маск рекомендует:  Что такое код socket_sendmsg

Если SNI не поддерживается, Вы не увидите никаких сообщений.

Проверка поддержки технологии OCSP stapling с помощью openssl s_client


Для проверки того, что SSL/TLS-сервер поддерживает технологию OCSP stapling, придется добавить в команду openssl s_client ключ -status (он включает отправку запроса состояния OCSP stapling и отображение полученного ответа). В связи с тем, что интересующие нас данные начинаются со строки, содержащей текст OCSP response: и занимают 17 строк, последняя из которых в случае поддержки OCSP stapling включает текст Next Update:, можно найти и обрезать нужные сведения с помощью двух вызовов grep(1), а заодно отправить «лишнюю» информацию, отображаемую через stderr , в /dev/null . Из-за того, что необходимые нам данные отправляются сервером после закрытия соединения, следует сразу передать ему команду QUIT . С учетом сказанного для проверки поддержки OCSP stapling, например, на HTTPS-сервере yandex.ru придется выполнить команду:

Если HTTPS-сервер поддерживает технологию OCSP stapling (yandex.ru ее поддерживает), будет отображено примерно такое сообщение:

Если OCSP stapling не поддерживается, Вы не увидите никаких сообщений.
Остается добавить, что я не рекомендую Вам запоминать рассмотренную в этом разделе команду, по крайней мере, до знакомства с SSLScan, который позволяет выполнять аналогичные действия более простым способом.

Проверка поддержки протоколов и наборов шифров с помощью openssl s_client

Поддержка тех или иных протоколов и наборов шифров определяет безопасность сервера и список клиентов, которые могут его использовать. Для получения хотя бы примерного представления о данном вопросе, имеет смысл познакомиться с документом ciphers и почитать качественные статьи соответствующей тематики, такие как Выбор ciphersuites для TLS и уязвимость Logjam. Опыт Яндекса. После этого можно начинать проверку поддержки протоколов и наборов шифров.
По умолчанию команда openssl s_client использует максимальную версию протокола, одновременно поддерживаемую клиентом и сервером.
Для проверки того, что SSL/TLS-сервер поддерживает протокол SSLv2, SSLv3, TLSv1, TLSv1.1 или TLSv1.2, нужно указать один из ключей -ssl2 , -ssl3 , -tls1 , -tls1_1 или -tls1_2 , соответственно. Например, для проверки поддержки протокола SSLv2 на HTTPS-сервере этого сайта необходимо выполнить команду:

Она должна закрыть соединение с HTTPS-сервером примерно с таким сообщением об ошибке:

При аналогичной проверке поддержки протокола SSLv3 сообщения об ошибке изменится:

Если интересующий Вас протокол поддерживается, Вы не только увидите упомянутые в двух предыдущих разделах параметрах сервера и текущего соединения, но и сможете обмениваться командами и результатами их выполнения с сервером (соединение будет оставаться открытым, пока Вы его не закроете).
Для того чтобы отказаться от использования протокола SSLv2, SSLv3, TLSv1, TLSv1.1 и TLSv1.2 (или любой комбинации данных протоколов), следует добавить ключ (или любую комбинацию ключей) -no_ssl2 , -no_ssl3 , -no_tls1 , -no_tls1_1 и -no_tls1_2 , соответственно.
Для получения списка наборов шифров, которые поддерживает OpenSSL, нужно выполнить команду:

Для того чтобы сведения о наборах шифров стали более подробными, необходимо указать ключ -v
Для отображения наборов шифров, соответствующих протоколам SSLv3-TLSv1.2, следует добавить ключ -ssl3 (или -tls1 ), протоколу SSLv2 -ключ -ssl2 .
Для гибкого ограничения списка используемого набора шифров нужно дополнить команду необязательной строкой cipherlist , позволяющей задать один или несколько наборов шифров, разделенных двоеточиями (запятые и пробелы допустимы, но почти не используются). Например, строка ‘RC4-SHA’ определяет один набор шифров, строка ‘SHA1’ — наборы шифров, включающие алгоритм SHA1, строка ‘SSLv3’ — наборы шифров, которые связаны с протоколом SSLv3. Строки могут объединяться с помощью символа + , обозначающего логическую операцию AND . Например, строка ‘SHA1+DES’ задает наборы шифров, имеющие в составе алгоритмы SHA1 и DES. Каждая из строк может предваряться символами ! , — или + , при этом ! обеспечивает удаление наборов шифров, определенных в следующей за ним строке (удаление происходит даже в случае последующего явного включения соответствующие наборов шифров), — удаляет соответствующие наборы шифров, но позволяет включить их в дальнейшем, + не добавляет дополнительные наборы шифров, а перемещает существующие в конец списка. Когда строка не начинается с перечисленных символов, она интерпретируется как определение набора шифров, которое необходимо добавить в существующий список наборов шифров. Если строка включает уже добавленные наборы шифров, она будет проигнорирована — соответствующие наборы шифров не будут помещены в конец списка. Строка, определяющая набор шифров, может быть дополнена суффиксом @STRENGTH , который обеспечивает сортировку списка наборов шифров по убыванию длины ключей (стойкости). Еще один полезный суффикс @SECLEVEL=n , позволяет указать security level , равный n . Подробное описание других возможностей строки cipherlist имеется в документе ciphers, а для первого знакомства, будет достаточно того, что здесь написано. Для улучшения понимания полученных сведений имеет смысл рассмотреть несколько примеров cipherlist из документации OpenSSL:
‘ALL:eNULL’ задает все наборы шифров, кроме не обеспечивающих шифрование (они же eNULL ), отсортированные по убыванию стойкости;
‘ALL:!ADH:@STRENGTH’ включает все наборы шифров, кроме анонимных DH и выключенных по умолчанию eNULL , отсортированные аналогично;
‘ALL:!aNULL’ задает все наборы шифров, кроме не обеспечивающих аутентификацию (они же aNULL ) и выключенных по умолчанию eNULL ;
‘3DES:+RSA’ включает все наборы шифров, содержащие алгоритм 3DES, при этом наборы шифров с алгоритмом RSA перемещаются в конец списка;
‘RC4:!COMPLEMENTOFDEFAULT’ задает все наборы шифров, включающие алгоритм RC4, кроме наборов шифров без аутентификации ( COMPLEMENTOFDEFAULT обозначает все, что включено в ALL , но выключено по умолчанию. В настоящее время это все наборы шифров, содержащие алгоритм RC4, и анонимные наборы шифров. Учтите, что если Вы захотите включить eNULL , не входящий в состав ALL , придется заменить COMPLEMENTOFDEFAULT на COMPLEMENTOFALL );
‘RSA:!COMPLEMENTOFALL’ включает все наборы шифров, содержащие алгоритм RSA, кроме описанных выше COMPLEMENTOFALL ;
‘ALL:@SECLEVEL=2’ задает все наборы шифров, соответствующие security level , равному 2 .
После получения элементарного представления о наборах шифров можно вернуться к команде openssl s_client , позволяющей проверять их поддержку на SSL/TLS-серверах. Для выполнения такой проверки необходимо указать ключ -cipher , дополненный рассмотренной выше строкой cipherlist . Признаки того, что набор шифров поддерживается или не поддерживается, аналогичны рассмотренным при описании проверки поддержки протоколов. Следует отметить, что как и в случае с протоколами, при указании нескольких наборов шифров используется самый стойкий, одновременно поддерживаемый клиентом и сервером. В связи с этим для выявления поддержки всех наборов шифров на некотором SSL/TLS-сервере нужно выполнить приличное количество команд openssl s_client , либо автоматизировать эту процедуру с помощью примерно таких скриптов. На мой взгляд, указанные способы выявления списка поддерживаемых наборов шифров хороши для хакеров специалистов по безопасности, но слишком сложны для применения в повседневной жизни, поэтому (как и в случае с проверкой поддержки OCSP stapling) я не рекомендую Вам использовать их до знакомства с соответствующими возможностями nmap и SSLScan.

Проверка параметров SSL/TLS-серверов с помощью nmap

Одна из многочисленных возможностей nmap заключается в поддержке скриптов, написанных на языке Lua. Сегодня в комплект поставки nmap входит более 500 таких скриптов. Вы можете познакомиться с ними на NSEDoc Reference Portal или изучить содержимое папки /usr/local/share/nmap/scripts . В нашем случае понадобятся скрипты с именами ssl-. nse , предназначенные для проверки таких параметров SSL/TLS-серверов, как свойства их сертификатов, списки поддерживаемые протоколов и наборов шифров, а также наличие некоторых уязвимостей. Для запуска одного (или нескольких) скриптов необходимо указать его имя (или несколько имен, разделенных запятыми) в качестве аргумента ключа -script . В связи с тем, что по умолчанию nmap проверяет все порты, имеет смысл ограничить их количество с помощью ключа -p , аргументом которого должен быть номер нужного порта (или номера нескольких портов, разделенные запятыми).
На этом можно закончить «вступительную часть» и перейти к рассмотрению примеров проверки параметров SSL/TLS-серверов с помощью nmap.
Для получения информации о сертификате HTTPS-сервера данного сайта с необходимо выполнить команду:

В отличие от команды openssl s_client , она отобразит параметры сертификата сервера в достаточно лаконичном виде:

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

В отличие от команды openssl s_client , она предоставит сведения обо всех поддерживаемых протоколах и наборах шифров:

Представленное сообщение содержит следующую информацию о том, что HTTPS-сервер:
поддерживает протоколы TLSv1, TLSv1.1 и TLSv1.2;
поддерживает перечисленные наборы шифров, сгруппированные по протоколам, при этом большинство наборов шифров имеет стойкость A, и только шифры, включающие алгоритм 3DES, отвечают уровню C (менее стойкие наборы шифров включены для обеспечения поддержки браузера Microsoft Internet Explorer 8.0 для Microsoft Windows XP). Стойкость наборов шифров обозначается буквами от A (максимальная) до F (минимальная), при этом оценка зависит от используемых алгоритмов обмена ключами и шифрования трафика, но не зависит от алгоритма контроля целостности. Для получения дополнительных сведений о методологии ранжирования конфигураций SSL/TLS-серверов стоит познакомиться с документом SSL Server Rating Guide;
не поддерживает сжатие ни для одного из протоколов;
самостоятельно задает предпочтительный набор шифров;
поддерживает наборы шифров со стойкостью не ниже уровня C.
Для сравнения рассмотрим результат проверки «заброшенного» SMTPS-сервера:

В отличие от предыдущего примера, в этот раз можно увидеть, что SMTPS-сервер:
поддерживает единственный протокол TLSv1;
поддерживает наборы шифров с минимальной стойкость F;
не предлагает клиентам предпочтительный набор шифров;
Кроме перечисленных сведений, сообщение содержит три предупреждения (они выделены) о том, что:
используются наборы шифров, содержащие алгоритм RC4, запрещенный в документе RFC 7465;
используются наборы шифров, включающие алгоритм контроля целостности MD5;
сертификат сервера подписан с помощью небезопасного алгоритма MD5.
Как видите, разница между относительно нормальной и плохой конфигурациями заметна даже невооруженным взглядом.
Для проверки HTTPS-сервера данного сайта на наличие уязвимостей Heartbleed (CVE-2014-0160), MITM CCS injection (CVE-2014-0224), а также Logjam (CVE 2015-4000) (в связи с тем, что протоколы SSLv2 и SSLv3 выключены, не имеет смысла искать связанные с ними уязвимости) нужно выполнить команду:

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

Это все, что я хотел рассказать о соответствующей функциональности nmap. Остается добавить, что Вы должны рассматривать упомянутые и «забытые» скрипты для nmap как удобные дополнительные инструменты, но ни в коем случае не как самодостаточный комплекс для выявления уязвимостей SSL/TLS-серверов.

Проверка параметров SSL/TLS-серверов с помощью SSLScan

SSLScan позиционируется автором как простой и быстрый инструмент проверки параметров SSL/TLS-серверов. Собственно, таковым он и является. Как и оба уже рассмотренных инструмента, SSLScan позволяет проверять параметры сертификатов SSL/TLS-серверов, получать списки поддерживаемых протоколов и наборов шифров, а также выявлять наличие уязвимости Heartbleed (CVE-2014-0160). Кроме этого, SSLScan позволяет проверять поддержку технологии OCSP.
Особенность SSLScan заключается в отображении разноцветных сообщений, при этом соответствующие цвета сигнализируют о нормальных, посредственных или нуждающихся в исправлении значениях параметров:
Красный цвет фона, сильнее всего привлекающий внимание, выделяет наборы шифров, не обеспечивающие шифрование;
Красный цвет текста — устаревшие наборы шифров (≤40 бит), устаревшие протоколы SSLv2 / SSLv3 и устаревший алгоритм подписи сертификатов MD5;
Желтый цвет текста — слабые наборов шифров (≤56 бит), наборы шифров, содержащие алгоритм RC4, и слабый алгоритм подписи сертификатов SHA1;
Розовый цвет текста — наборы шифров, содержащие анонимные DH-алгоритмы ADH или AECDH;
Зеленый цвет текста — стойкие наборы шифров и алгоритмы подписи сертификатов.
В общем случае при запуске SSLScan достаточно указать в командной строке только имя хоста и номер порта (если номер порта не задан, используется значение 443), разделенные двоеточием. Например, для проверки параметров HTTPS-сервера этого сайта необходимо выполнить команду:

Она отобразит примерно такие сведения о параметрах HTTPS-сервера и его сертификата, а также о поддерживаемых протоколах и наборах шифров:

В связи с тем, что информация, представленная в сообщении, прокомментирована выше, я не буду повторяться. Обратите внимание на значительное количество зеленого, небольшое желтого, и, наконец, полное отсутствие розового и красного цветов. Такая «цветовая гамма» является признаком относительно приемлемой конфигурации HTTPS-сервера. Для сравнения следует рассмотреть результат проверки уже упоминавшегося «заброшенного» SMTPS-сервера:

В отличие от предыдущего примера, в этот раз можно увидеть присутствие красного цвета, привлекающего внимание к устаревшему алгоритму подписи, слабому ключу, недоверенному издателю, а также истекшему сроку действия сертификата (все перечисленное совершенно естественно для самоподписного сертификата, сгенерированного более 10 лет назад). Кроме красного, можно заметить приличное количество розового и желтого цветов. Такая «цветовая гамма» говорит о том, что конфигурация SMTPS-сервера давно требует напильника обновления (жаль, что не все владельцы подобных серверов способны это услышать).
Для отключения некоторых проверок SSLScan и соответствующего уменьшения объема отображаемых сведений следует воспользоваться ключом (или любой комбинацией ключей) —no-check-certificate , —no-ciphersuites , —no-renegotiation , —no-compression , —no-heartbleed . Первый из них отключает выявление устаревших алгоритмов подписи сертификатов MD5 или SHA-1 и коротких ( Для проверки только тех наборов шифров, которые связаны с протоколом SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2 или всеми протоколами TLS версии от 1.0 до 1.2, следует указать ключ —ssl2 , —ssl3 , —tls10 , —tls11 , —tls12 или —tlsall , соответственно.
Для сокрытия имен эллиптических кривых и длин ключей EDH/RSA необходимо добавить ключ —no-cipher-details (он работает только с OpenSSL ≥1.0.2).
Для превращения цветных сообщений в монохромные (не представляю, зачем это может понадобиться) следует указать ключ —no-colour .
Для добавления в отображаемое сообщение подробной информации о параметрах сертификата сервера нужно добавить ключ —show-certificate .
Для проверки поддержки технологии OCSP необходимо указать ключ —ocsp (вспомните соответствующий вариант команды openssl s_client �� ).
На этом можно закончить краткий рассказ про SSLScan. Я не могу сказать, что SSLScan способен заменить рассмотренные выше инструменты, однако он имеет полное право стать их дополнением. Невзирая на «заброшенное» состояние, в настоящее время SSLScan корректно выполняет свои функции. Будем надеяться, что его форк rbsec/sslscan продолжит развиваться и рано или поздно заменит своего родителя.

Проверка параметров SSL/TLS-серверов с поддержкой STARTTLS

Остается добавить, что команда openssl s_client и SSLScan позволяют проверять параметры SSL/TLS-серверов с поддержкой технологии STARTTLS.
Для проверки параметров FTP-, IMAP-, POP3 и SMTP-серверов, поддерживающих STARTTLS, с помощью команды openssl s_client следует указывать ключ -starttls с аргументом ftp , imap pop3 или smtp , соответственно.
Для проверки параметров FTP-, IRC-, IMAP-, POP3-, SMTP-, PostgreSQL- и XMPP-серверов, поддерживающих STARTTLS, с помощью SSLScan нужно добавлять один из ключей —starttls-ftp , —starttls-irc , —starttls-imap , —starttls-pop3 , —starttls-smtp (в случае зависания соединения с SMTP-сервером из-за использования протокола SSLv3 поверх соединения STARTTLS необходимо указать описанный в предыдущем разделе ключ —tlsall ), —starttls-psql и —starttls-xmpp , соответственно. Если добавление ключа —starttls-xmpp не помогает, можно попробовать заменить его на —xmpp-server (данный ключ предназначен для инициирования XMPP-соединения сервер-сервер).

Заключение

Я надеюсь, что собранные здесь рекомендации помогут Вам начать проверку параметров обслуживаемых SSL/TLS-серверов, а затем плавно перейти к внесению изменений в их конфигурации. Ни в коем случае не торопитесь, старательно изучайте соответствующую документацию, и через некоторое время Ваши серверы будут иметь практически идеальные параметры SSL/TLS. При появлении свободного времени я постараюсь помогать Вам в этом, а пока предлагаю поучаствовать в обсуждении статьи (конструктивная критика приветствуется) и благодарю за внимание!

Понравилась статья?

Поделитесь ссылкой в социальной сети или блоге:

Сертификат шифрования AES128-GCM-SHA256 с использованием openssl [duplicate]

Я добавляю поддержку https для встроенного Linux-устройства. Я попытался создать самозаверяющий сертификат с этими шагами:

Это работает, но я получаю некоторые ошибки, например, с помощью google chrome:

Возможно, это не тот сайт, который вы ищете! Сертификат безопасности сайта не доверен!

Я что-то упустил? Это правильный способ создания самозаверяющего сертификата?

12 ответов

Вы можете сделать это с помощью одной команды:

Вы также можете добавить -nodes , если вы не хотите защищать свой закрытый ключ парольной фразой, иначе он предложит вам » как минимум 4 символа «. Параметр days (365) можно заменить любым числом, чтобы повлиять на дату истечения срока действия. Затем он предложит вам такие вещи, как «Имя страны», но вы можете просто нажать «Ввести» и принять значения по умолчанию.

Добавить -subj ‘/CN=localhost’ , чтобы подавить вопросы о содержимом сертификата (замените localhost на желаемый domain)

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

Сгенерировать ключи

Я использую /etc/mysql для хранения сертификатов, потому что /etc/apparmor.d/usr.sbin.mysqld содержит /etc/mysql/*.pem r .

Добавить конфигурацию

В моей настройке сервер ubuntu зарегистрировался на: /var/log/mysql/error.log

Последующие примечания:

  • SSL error: Unable to get certificate from ‘. ‘ Mysql может быть отказано в доступе к чтению вашего файла сертификата, если он не находится в apparmors config . Как упоминалось в предыдущих шагах ^, сохраните все наши сертификаты в виде .pem файлов в каталоге /etc/mysql/ , которые по умолчанию одобрены apparmor (или измените ваш apparmor / SELinux, чтобы разрешить доступ туда, где вы их сохранили.)
  • SSL error: Unable to get private key Версия вашего сервера mysql может не поддерживать формат по умолчанию rsa:2048 . Covert сгенерировал rsa:2048 равным rsa с помощью:
  • Проверьте, поддерживает ли локальный сервер ssl :
  • Проверка соединения с db зашифрована ssl :

Проверка соединения

Альтернативная ссылка: Длительный учебник здесь http://www.madirish.net/214

Вот варианты, описанные в @ diegows’s answer , более подробно описанные в документации :

Запрос сертификата PKCS № 10 и утилита создания сертификатов.

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

этот параметр создает новый запрос сертификата и новый закрытый ключ. Аргумент принимает одну из нескольких форм. rsa: nbits, где nbits — количество бит, генерирует nbits ключа RSA в размере.

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

Указывает выходное имя файла для записи или стандартного вывода по умолчанию.

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

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

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

Это сценарий, который я использую в локальных блоках для установки SAN (subjectAltName) в самозаверяющих сертификатах.

Этот скрипт принимает имя домена (example.com) и генерирует SAN для * .example.com и example.com в том же сертификате. Прокомментированы следующие разделы. Назовите сценарий (например, generate-ssl.sh ) и предоставите ему права на выполнение. Файлы будут записаны в тот же каталог, что и скрипт.

Для Chrome 58 и далее требуется, чтобы SAN устанавливался в самозаверяющих сертификатах.

Этот скрипт также записывает info file, чтобы вы могли проверить новый сертификат и проверить правильность установки SAN.

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

Не забудьте перезапустить сервер Apache (или Nginx или IIS), чтобы новый сертификат вступил в силу.

2020 Один лайнер:

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

Я бы рекомендовал добавить параметр -sha256, чтобы использовать алгоритм хэша SHA-2, потому что основные браузеры рассматривают, чтобы показать «сертификаты SHA-1» как небезопасные.

То же командная строка из принятый ответ — @diegows с добавленным -sha256

openssl req -x509 -sha256 -newkey rsa: 2048 -keyout key.pem -out cert.pem -days XXX

Обновление до 2020 года. Как отмечалось в комментариях, использование SHA-2 не добавляет никакой безопасности для самоподписанного сертификата. Но я по-прежнему рекомендую использовать его как хорошую привычку не использовать устаревшие / небезопасные криптографические хэш-функции. Полное объяснение доступно в: https://security.stackexchange.com/questions/91913/why-is-it-fine-for-certificates-above-the-end-entity-certificate-to-be-sha1 -base

У вас правильная процедура. Синтаксис команды ниже.

Однако предупреждения отображаются, потому что браузер не смог проверить идентификацию, подтвердив сертификат с помощью известного центра сертификации (CA).

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

  1. Сгенерировать закрытый ключ
  2. Использовать этот закрытый ключ для создать файл CSR
  3. Отправить CSR в CA (Verisign или другие и т. д.)
  4. Установить полученный сертификат из CA на веб-сервере
  5. Добавить другие сертификаты в цепочку аутентификации в зависимости от на типе cert

Один вкладыш FTW. Мне нравится держать его простым. Почему бы не использовать одну команду, содержащую ВСЕ необходимые аргументы? Вот как мне это нравится: это создает сертификат x509 и это PEM-ключ:

Эта единственная команда содержит все ответы, которые вы обычно указали для деталей сертификата. Таким образом, вы можете установить параметры и запустить команду, получить свой результат — затем пойти на кофе.

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

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

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

Заменить «localhost» на любой домен, который вам нужен. Вам нужно будет выполнить первые две команды один за другим, так как openssl предложит кодовую фразу.

Чтобы объединить два файла в файл .pem:

Современные браузеры теперь вызывают ошибку безопасности для хорошо сформированных самозаверяющих сертификатов, если они не имеют SAN (Subject Alternate Name). OpenSSL не предоставляет способ командной строки для указания этого , поэтому многие обучающие программы и закладки разработчиков неожиданно устарели.

Самый быстрый способ снова запустить — это короткая, стоящая -alone conf file:

  1. Создать конфигурационный файл OpenSSL (пример: req.cnf )
  2. Создать сертификат, ссылающийся на этот файл конфигурации

создает сертификат для домена example.com , который

  • относительно силен (по состоянию на 2020 год) и
  • , действительный для 3650 дней (

Он создает следующие файлы:

  • Закрытый ключ: example.key
  • Сертификат: example.crt

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

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

В будущем вам может понадобиться больше, чем 4096 бит для ключа RSA и алгоритм хеширования, более сильный, чем sha256 , но с 2020 года это нормальные значения.

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

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

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

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

Отключить TLS_RSA_WITH_RC4_128_SHA и TLS_RSA_WITH_RC4_128_MD5 с помощью web.config?

Недавно я приобрел SSL certificate для своего website . Я провел несколько тестов с помощью sslLabs.com и он дал предупреждение о двух ciphers , которые включены: TLS_RSA_WITH_RC4_128_SHA и TLS_RSA_WITH_RC4_128_MD5 . Мой website находится на общем сервере, поэтому я не уверен, что они могут отключить их только для моего сайта. Мне было интересно, есть ли способ отключить ciphers с web.config file или похожим file котором хранятся свойства server ? Заранее спасибо! Если это помогает, я работаю на Windows Server используя ColdFusion .

В моем случае я отключил RC4 в Microsoft Azure Cloud.

В основном я отключил его на своем компьютере (реестр Windows), а затем экспортировал эту часть в файл.

Затем вы присоедините этот файл к своему проекту и установите для параметра «Копировать в выходной каталог» значение «Копировать всегда».

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

В конце и в моем случае просто нужно было добавить его в ServiceDefinition.csdef

Надеюсь, это помогло после столь долгого времени.

Что такое код asp serverconfigssl128

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

Что такое SSL и TLS

Secure Socket Layer или ssl это, технология, призванная сделать доступ к сайтам более надежным и безопасным. Сертификат шифрования позволяет, надежно защитить трафик, передаваемый между браузером пользователя и веб ресурсом (сервером), к которому браузер обращается, все это происходит за счет протокола https. Сделано, это все после того, как бурное развитие интернета привело к огромному количеству сайтов и ресурсов, которые требуют от пользователя ввод личных, персональных данных:

  • Пароли
  • Номера кредитных карт
  • Переписка

Именно эти данные и являются добычей для хакеров, сколько уже было громких дел, с кражей персональной информации и сколько еще будет, ssl сертификат шифрования, призван это минимизировать. Разработкой технологии SSL выступила компания Netscape Communications, позднее она представила Transport Layer Security или проще TLS, это протокол основанный по спецификации SSL 3.0. И Secure Socket Layer и Transport Layer Security призваны обеспечить передачу данных между двумя узлами по интернету.

SSL и TLS не имеют принципиальных различий в своей работе, могут даже быть использованы на одном сервере одновременно, делается это исключительно из соображений обеспечения работы новых устройств и браузеров, так и устаревших, где Transport Layer Security не поддерживается.

Для примера откройте сайт Яндекса, я это делаю в Google Chrome, там на против адресной строки есть значок замка, щелкаем по нему. Тут будет написано, что подключение к веб-сайту защищено и можно нажать подробнее.

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

В поле о сведениях о сертификате видим его предназначение:

  1. Обеспечивает получение идентификации от удаленного компьютера
  2. Подтверждает удаленному компьютеру идентификацию вашего компьютера
  3. 1.2.616.1.113527.2.5.1.10.2

История версий сертификатов шифрования

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

  • SSL 1.0 > данная версия в народ так и не попала, причины, возможно нашли его уязвимость
  • SSL 2.0 > эта версия ssl сертификата была представлена в 1995 году, на стыке тысячелетий, она так же была с кучей дыр безопасности, сподвигнувшие компанию Netscape Communications к работе над третье версией сертификата шифрования
  • SSL 3.0 > пришел на смену SSL 2.0 в 1996 году. Стало это чудо развиваться и в 1999 году крупные компании Master Card и Visa купили коммерческую лицензию на его использование. Из 3.0 версии появился TLS 1.0
  • TLS 1.0 > 99 год, выходит обновление SSL 3.0 под названием TLS 1.0, проходит еще семь лет, интернет развивается и хакеры не стоят на месте, выходит следующая версия.
  • TLS 1.1 > 04.2006 это его отправная точка, было исправлено несколько критичных ошибок обработки, а так же появилась защита от атак, где делался режим сцепления блоков шифротекста
  • TLS 1.2 > появился в августе 2008
  • TLS 1.3 > появится в конце 2020 года

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

Давайте разбираться как работает протоколы SSL и TLS. Начнем с основ, все сетевые устройства имеют четко прописанный алгоритм общения друг с другом, называется он OSI, который порезан на 7 уровней. В ней есть транспортный уровень отвечающий за доставку данных, но так как модель OSI это некая утопия, то сейчас все работаю по упрощенной модели TCP/IP, из 4 уровней. Стек TCP/IP, сейчас стандарт передачи данных в компьютерных сетях и он включает в себя, большое количество известных вам протоколов прикладного уровня:

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

Ну и схема стека SSL/TLS, для наглядности.

Теперь все тоже самое простым языком, так как не всем понятны эти схемы и принцип работы ssl и tls не понятен. Когда вы открываете например мой блог pyatilistnik.org, то вы обращаетесь по прикладному протоколу http, при обращении сервер видит вас и передает на ваш компьютер данные. Если это представить схематично, то это будет простая матрешка, прикладной протокол http, кладется в стек tcp-ip.

Если бы на Pyatilistnik.org стоял бы сертификат шифрования TLS, то матрешка протоколов была бы посложнее и выглядела бы вот так. Тут прикладной протокол http, кладется в SSL/TLS, который в свою очередь кладется в стек TCP/IP. Все тоже самое, но уже зашифровано, и если хакер перехватит эти данные по пути их передачи, то получит всего навсего цифровой мусор, а вот расшифровать данные может только та машина, которая устанавливала соединение с сайтом.

Этапы установки соединения SSL/TLS

  1. Клиент обращается к серверу, устанавливая с ним соединение, далее запрашивается защищенное подключение, тут два варианта, если вы изначально обращаетесь на порт 443, который предназначен для TLS/SSL соединения, или после того как вы установили обычное подключение, клиент делает дополнительный запрос на защищенное соединение.
  2. Когда идет установка соединения, клиент говорит серверу, какие алгоритмы шифрования ему известны, сервер сравнивает его со своим списком алгоритмов шифрования и находит тот, который поддерживается обоими сторонами. Далее он говорит клиенту, что будет использоваться именно этот метод защиты. По умолчанию сервер будет стараться использовать самый современный алгоритм (SSLv3, TLSv1, TLSv1.1, TLSv1.2)
  3. После того, как определились с алгоритмами шифрования, сервер передает клиенту свой цифровой сертификат, который подписан вышестоящим, мировым центром сертификации и открытый ключ сервера.
  4. Клиент проверяет ликвидность полученного сертификата от сервера, для этого он обращается к центру сертификации, который его выдавал, и спрашивает есть ли у тебя такой сертификат, если все нормально, можно продолжать. Тут главное, чтобы сертификат не был отозван и вы доверяли корневому центру сертификации, выдавшим его, по умолчанию в операционной системе Windows, уже есть большое количество корневых сертификатов, которым вы доверяете, и они обновляются при установке новых обновлений в систему.
  5. Следующим этапом, после получения клиентом нужных ключей, начинается генерация сеансового ключа для защищенного соединения по принципу: Клиентом происходит генерация случайной цифровой последовательности, которую он шифрует с помощью открытого ключа полученного от сервера и отсылает результат шифрования на сервер. Полученный сеансовый ключ расшифровывается сервером с помощью его закрытого ключа, в виду того, что используется асимметричный алгоритм шифрования, то расшифровать последовательность полученную от клиента, может только сервер. Об алгоритмах шифрования мы еще поговорим ниже.
  6. Все защищенный канал настроен и будет работать до тех пор, пока не будет разорвано соединение.

Вот еще одна красивая и наглядная схема создания защищенного канала.

Установка соединения SSL/TLS на уровне сетевых пакетов

Ну и подробно про каждый этап обмена сетевых сообщений протоколов SSL/TLS.

  • 1. ClientHello > пакет ClientHello делает предложение со списком поддерживаемых версий протоколов, поддерживаемые наборы шифров в порядке предпочтения и список алгоритмов сжатия (обычно NULL). Еще от клиента приходит случайное значение 32 байта, его содержимое указывает отметку текущего времени, его позже будут использовать для симметричного ключа и идентификатора сессии, который будет иметь значение ноль, при условии, что не было предыдущих сессий.
  • 2.ServerHello > пакет ServerHello, отсылается сервером, в данном сообщении идет выбранный вариант, алгоритма шифрования и сжатия. Тут так же будет случайное значение 32 байта (отметка текущего времени), его также используют для симметричных ключей. Если ID текущей сессии в ServerHello имеет значение ноль, то создаст и вернёт идентификатор сессии. Если в сообщении ClientHello был предложен идентификатор предыдущей сессии, известный данному серверу, то протокол рукопожатия будет проведён по упрощённой схеме. Если клиент предложил неизвестный серверу идентификатор сессии, сервер возвращает новый идентификатор сессии и протокол рукопожатия проводится по полной схеме.
  • 3.Certificate (3) > в данном пакете сервер отправляет клиенту свой открытый ключ (сертификат X.509), он совпадает с алгоритмом обмена ключами в выбранном наборе шифров. Вообще можно сказать в протоколе, запроси открытый ключ в DNS, запись типа KEY/TLSA RR. Как я писал выше этим ключом будет шифроваться сообщение.
  • 4. ServerHelloDone > Сервер говорит, что сессия установилось нормально.
  • 5. ClientKeyExchange > Следующим шагом идет отсылка клиентом ключа pre-master key, используя случайные числа (или отметки текущего времени) сервера и клиента. Данный ключ (pre-master key) как раз и шифруется открытым ключом сервера. Данное сообщение может расшифровать только сервер, с помощью закрытого ключа. Теперь оба участника вычисляют общий секретный ключ master key из ключа pre-master.
  • 6. ChangeCipherSpec — клиент > смысл пакета, указать на то, что теперь весь трафик, который идет от клиента, будет шифроваться, с помощью выбранного алгоритма шифрования объёмных данных и будет содержать MAC, вычисленный по выбранному алгоритму.
  • 7. Finished — клиент > Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и хэшируется с помощью алгоритма MAC, о которых договорились стороны. Если сервер может расшифровать и верифицировать это сообщение (содержащее все предыдущие сообщения), используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, на этом месте сервер прерывает сессию и отправляет сообщение Alert с некоторой (возможно, неконкретной) информацией об ошибке
  • 8. ChangeCipherSpec — сервер > пакет, говорит, что теперь весь исходящий трафик с данного сервера, будет шифроваться.
  • 9.Finished — сервер > Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished
  • 10. Record Protocol (протокол записи) > теперь все сообщения шифруются ssl сертификатом безопасности

Как получить ssl сертификат безопасности

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

Бесплатный способ получить tls сертификат безопасности

Этот способ, подразумевает использование самоподписного сертификата (self-signed), его можно сгенерировать на любом веб-сервере с ролью IIS или Apache. Если рассматривать современные хостинги, то в панелях управления, таких как:

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

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

Давайте смотреть как можно получить ssl сертификат безопасности, для этого формируется запрос на выпуск сертификата, называется он CSR запрос (Certificate Signing Request). Делается это чаще всего у специальной компании в веб форме, которая спросит вас несколько вопросов, про ваш домен и вашу компанию. Как только вы все внесете, сервер сделает два ключа, приватный (закрытый) и публичный (открытый). Напоминаю открытый ключ не является конфиденциальным, поэтому вставляется в CSR запрос. Вот пример Certificate Signing Request запроса.

Все эти не понятные данные легко можно интерпретировать специальными CSR Decoder сайтами.

Состав CSR запроса

  • Common Name: доменное имя, которое мы защищаем таким сертификатом
  • Organization: название организации
  • Organization Unit: подразделение организации
  • Locality: город, где находится офис организации
  • State: область или штат
  • Country:двухбуквенный код, страны офиса
  • Email: контактный email технического администратора или службы поддержки

Как только Certificate Signing Request сгенерирован, можно начинать оформлять заявку на выпуск сертификата шифрования. Центр сертификации будет производить проверку, всех данных указанных вами в CSR запросе, и если все хорошо, вы получите свой ssl сертификат безопасности и вы его сможете использовать для https. Теперь ваш сервер, автоматом сопоставит выпущенный сертификат, со сгенерированным приватным ключом, все вы можете шифровать трафик подключения клиента к серверу.

Что такое центр сертификации

Что такое CA — Certification Authority или центр сертификации, читайте по ссылке слева, я подробно рассказал об этом там.

Какие данные содержит в себе SSL сертификат

В сертификате хранится следующая информация:

  • полное (уникальное) имя владельца сертификата
  • открытый ключ владельца
  • дата выдачи ssl сертификата
  • дата окончания сертификата
  • полное (уникальное) имя центра сертификации
  • цифровая подпись издателя

Какие существуют виды SSL сертификатов шифрования

Основных видов сертификатов безопасности три:

  • Domain Validation — DV > Это сертификат шифрования, который только подтверждает доменное имя ресурса
  • Organization Validation — OV > Это сертификат шифрования, который подтверждает организацию и домен
  • Extendet Validation — EV > Это сертификат шифрования, который имеет расширенную проверку

Назначение Domain Validation — DV

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

approver email так же имеет требования, логично, что если вы заказываете сертификаты шифрования для домена, то и электронный ящик должен быть из него, а не mail или rambler, либо он должен быть указан в whois домена и еще одно требование название approver email, должно быть по такому шаблону:

  • webmaster@ваш домен
  • postmaster@ваш домен
  • hostmaster@ваш домен
  • administrator@ваш домен
  • admin@

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

Назначение Organization Validation — OV

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

Назначение Extendet Validation — EV

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

  • Могут посмотреть есть ли организация международных желтых страницах, кто не знает, что это такое, то это телефонные справочники в Америке. Проверяют так не все CA.
  • Смотрят whois домена у вашей организации, делают это все центры сертификации, если в whois нет ни слова о вашей организации, то с вас будут требовать гарантийное письмо, что домен ваш.
  • Свидетельство о государственной регистрации ЕГРИП или ЕГРЮЛ
  • Могут проверить ваш номер телефона, запросив счет у вашей телефонной компании, в котором будет фигурировать номер.
  • Могут позвонить и проверить наличие компании по этому номеру, попросят к телефону человека указанного администратором в заказе, так что смотрите, чтобы человек знал английский.

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

К расширенным сертификатам шифрования (extendet Validation — EV) самое большое доверие, это и логично вы сразу видите, что компания существует и прошла жесткие требования к выдаче сертификата. SSL cертификаты extendet Validatio делаются CA, только при выполнении двух требований, что организация владеет нужным доменом и, что она сама существует в природе. При выпуске EV SSL сертификатов, существует строгий регламент, в котором описаны требования перед выпуском EV сертификата

  • Должен проверить правовую, физическую и операционную деятельности субъекта
  • Проверка организации и ее документов
  • Право владения доменом, организации
  • Проверить, что организация полностью авторизована для выпуска EV сертификата

Типы SSL сертификатов шифрования

Следующим важным вопросом, будет какие типы SSL — TLS сертификатов шифрования существуют, и их отличия и стоимость.

  • Обычные SSL сертификаты > это самые распространенные сертификаты, делаются автоматически, для подтверждения только домена. Стоят в среднем 18-22 доллара.
  • SGC сертификаты > это SSL — TLS сертификаты с поддержкой, более высокого уровня шифрования. Они в основном идут для старперных браузеров, у которых есть поддержка только 40-56 битное шифрование. SGC принудительно повышает уровень шифрования , до 128 бит, что в несколько раз выше. Так как XP доживает свои последние годы, скоро SGC сертификаты шифрования не будут нужны. Стоит это чудо около 300-ста баксов за год.
  • Wildcard сертификаты > Требуются, для субдоменов вашего основного домена. Простой пример мой блог pyatilistnik.org, если я покупаю Wildcard, то имею возможно его вешать на все домены 4 уровня у себя, *.pyatilistnik.org. Стоимость Wildcard сертификатов шифрования варьируется от количества поддоменов, от 190 баксов.
  • SAN сертификаты > Допустим у вас есть один сервер, но на нем хостятся много разных доменов, вот SAN сертификат можно повесить на сервер и все домены будут использовать его, стоит от 400 баксов в год.
  • EV сертификаты > про расширенные мы уже все обсудили выше, стоят от 250 баксов в год.
  • Сертификаты c поддержкой IDN доменов

список сертификатов, у которых есть такая поддержка, IDN доменов:

  • Thawte SSL123 Certificate
  • Thawte SSL Web Server
  • Symantec Secure Site
  • Thawte SGC SuperCerts
  • Thawte SSL Web Server Wildcard
  • Thawte SSL Web Server with EV
  • Symantec Secure Site Pro
  • Symantec Secure Site with EV
  • Symantec Secure Site Pro with EV

Полезные утилиты:

  1. OpenSSL — самая распространенная утилита для генерации открытого ключа (запроса на сертификат) и закрытого ключа.
    http://www.openssl.org/
  2. CSR Decoder — утилита для проверки CSR и данных, которые в нем содержаться, рекомендую использовать перед заказом сертификата.
    http://www.sslshopper.com/csr-decoder.html или http://certlogik.com/decoder/
  3. DigiCert Certificate Tester — утилита для проверки корректно самого сертификата
    http://www.digicert.com/help/?r > http://www.sslshopper.com/ssl-checker.html

В будущих статьях, мы еще сами по настраиваем CA и будем на практике использовать SSL/TLS сертификаты шифрования.

Илон Маск рекомендует:  Random - Функция Delphi
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL