Для чего нужны сертификаты в windows

Добавил(а) microsin
  

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

В мире компьютеров существуют цифровые сертификаты, назначение которых примерно то же самое — они четко идентифицируют принадлежность к какому-то лицу, чаще юридическому. Сертификатами часто снабжаются программы или драйверы, чтобы удостоверить их подлинность — тот факт, что они были выпущены определенным, доверенным производителем программного обеспечения. Выдают сертификаты и подтверждают их подлинность специальные международные центры сертификации (Certificate Authority или CA), которые берут деньги за выдачу сертификатов. Все безусловно доверяют этим CA как независимому арбитру. Сам сертификат представляет из себя публичный ключ — специальным образом сгенерированную псевдослучайную, уникальную последовательность данных. Например, сертификатом может быт такой текстовый файл (формат Base-64 X.509):
——BEGIN CERTIFICATE——
MIIE6jCCA9KgAwIBAgIQdB7KfpVPv65NIapf4sT0FjANBgkqhkiG9w0BAQUFADBi
Y2UwHhcNMDYwMTE2MTYzNDMwWhcNMTEwMTE2MTY0MjE1WjBiMRMwEQYKCZImiZPy
 …
Y/DDITB1tiiW19A8wNCc/LnScOmn8XZUJYI8AUTOasKK2SGvhQpcZBy+RPD2QUDO
Yy5XK/kWKQE4jtOVkRA=
——END CERTIFICATE——

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

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

Время на прочтение8 мин

Количество просмотров2.2K

Картинка с сайта: habr.com

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

Так было не всегда. Когда .NET был еще совсем молод, большинство приложений работали в рамках одного домена Windows. Обычно в файле web.config не нужно было хранить пароли; права доступа к базе данных предоставлялись непосредственно учетной записи пользователя, под которой работало приложение.

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

Представленная здесь техника не нова; Йоуни Хейкниеми (Jouni Heikniemi) рассказывал о ней еще в 2013 году, как и команда SQL Azure за три года до этого. Но с годами некоторые шаги перестали работать из-за устаревших инструментов и изменения пользовательских интерфейсов. Тем не менее, первоначальная концепция по-прежнему актуальна.

Дополнительная защита

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

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

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

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

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

Создание цифрового сертификата

Цифровые сертификаты состоят из публичного и приватного ключа. Они аналогичны сертификатам SSL/TLS, но являются самоподписанными, поскольку им не нужно удостоверять, кто создал зашифрованный файл. Раньше Windows-разработчики использовали makecert.exe, но этот инструмент уже устарел. (Его все еще можно найти в Windows SDK.)

В наши дни правильным инструментом для создания сертификатов на компьютерах с Windows считается PowerShell. Чтобы создать сертификат, используйте следующие команды: 

ПРЕДУПРЕЖДЕНИЕ: Возможно, вам придется запускать PowerShell-команды от имени администратора.

$cert = New-SelfSignedCertificate -Type DocumentEncryptionCert -Subject "CN=DevConfig" -KeyExportPolicy Exportable -KeySpec KeyExchange

Export-Certificate -Cert $cert -FilePath ".\DevConfig.cer"

$mypwd = ConvertTo-SecureString -String "1234" -Force -AsPlainText

Export-PfxCertificate -Cert $cert -FilePath ".\DevConfig.pfx" -Password $mypwd

$cert

Как вы могли догадаться сами из ее названия, команда New-SelfSignedCertificate создает сертификат. В этом примере он называется “DevConfig”, но вы можете назвать его как хотите.

Затем мы экспортируем сертификат шифрования в “.cer”-файл с помощью команды Export-Certificate. Это публичный ключ, используемый для создания зашифрованных файлов конфигурации.

Следующие две строки позволяют нам экспортировать сертификат расшифровки в виде “.pfx”-файла с помощью Export-PfxCertificate. Крайне важно, чтобы этот файл хранился в безопасном оффлайновом месте отдельно от пароля, который вы определили с помощью ConvertTo-SecureString. (И, конечно, вам следует заменить “1234” более безопасным паролем.)

Для последующих шаговам вам потребуется узнать thumbprint сертификата. Последняя строка, “$cert”, сама по себе будет отображать thumbprint на экране. Thumbprint больше не считается секретом.

Импорт сертификата шифрования в Windows

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

Import-Certificate -Filepath ".\DevConfig.cer" -CertStoreLocation cert:\LocalMachine\My

В разделе Import-Certificate вы найдете больше информации.

Импорт сертификата расшифровки в Windows

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

$mypwd = ConvertTo-SecureString -String "1234" -Force -AsPlainText
Import-PfxCertificate -FilePath ".\DevConfig.pfx" -CertStoreLocation Cert:\LocalMachine\My -Password $mypwd

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

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

Импорт сертификата расшифровки в Windows Azure 

Сертификат расшифровки недоступна в бесплатной версии Azure App Services. На момент написания этой статьи вам нужен как минимум уровень B1, который разрешает SSL-подключения.

На портале Azure вам нужно найти вкладку “SSL Settings”. Затем нажмите кнопку “Upload Certificate” , чтобы указать сертификат. Затем вы должны увидеть его в нижней части экра:

Картинка с сайта: habr.com

Далее вам нужно предоставить приложению ваши сертификаты. Это делается путем добавления ключа WEBSITE_LOAD_CERTIFICATES на вкладку “Application Settings”. Вы можете использовать несколько значений thumbprint’ов, разделенных запятыми, или можете установить это значение на “*”, чтобы предоставить все ваши сертификаты вашему веб-приложению.

Картинка с сайта: habr.com

Защищенный поставщик конфигурации

Шифрование и дешифрование обрабатывается ProtectedConfigurationProvider. Тот, который  мы используем в этой статье, называется Pkcs12ProtectedConfigurationProvider. Первоначально он был создан корпорацией Microsoft, но в него были внесены незначительные изменения для совместимости со службами приложений Azure.

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

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

Подготовка файла web.config к шифрованию

После добавления в проект класса Pkcs12ProtectedConfigurationProvider вам потребуется подготовить файл web.config для шифрования.   

1. Добавьте этот раздел в свой файл web.config.

<configuration>
  [...]
  <configProtectedData>
    <providers>
      <add name="Pkcs12Provider" thumbprint="1234123412341234123412341234123412341234" type="WebConfigEncrypter.Pkcs12ProtectedConfigurationProvider, WebConfigEncrypter" storeLocation="LocalMachine"/>
    </providers>
  </configProtectedData>

2. Измените атрибут thumbprint, чтобы он соответствовал вашему сертификату.

3. Если вы не используете NuGet-пакет, обновите атрибут type, чтобы он соответствовал полностью квантийицированному классу и имени сборки DLL-библиотеки вашего ProtectedConfigurationProvider.

Шифрование строк подключения в файле web.config

Прежде чем начать это делать, убедитесь, что у вас есть резервная копия файла web.config.

В командной строке Visual Studio введите “where aspnet_regiis”. Затем скопируйте в эту папку следующие файлы. Это позволит инструментам командной строки aspnet использовать ваш класс ProtectedConfigurationProvider:

• WebConfigEncrypter.dll 

• System.Configuration.ConfigurationManager.dll

• System.Security.Cryptography.Xml.dll

Затем запустите эту команду из той же папки, что и файл web.config:

aspnet_regiis -pef "connectionStrings" "." -prov "Pkcs12Provider"

Ваш раздел зашифрованной конфигурации должен выглядеть примерно так:

<connectionStrings configProtectionProvider="Pkcs12Provider">
    <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
      xmlns="http://www.w3.org/2001/04/xmlenc#">
      <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes192-cbc" />
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
          <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
          <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
            <KeyName>rsaKey</KeyName>
          </KeyInfo>
          <CipherData>
            <CipherValue>Moy/a2XO2zvnn/HZW53DyC8aAJWo16+0KmnpC4SCSmuQZU0RT+HNFEA33pAGCzve+m6MTaRzhx6jVVRoAvpSNzfYG1bU1z7a1YnbW4OGxrmYYfdWW6cZQZ57dZnL6YSAlkJ5WlqPDGUPJa6FV/hTic3x4fJYy5vdSucmO6X3opuo1998LWNkL6fIS4WkjkG/SOFbI2Qx3HHogdN670jDHKNDON1z7bFHhLNyVj7RTO3xuQN9kF4PqbFtvwm1bYXTbZpdNxu/fcXZKONSAu8HN3QX5vTRyP/I4BG+NK7TUig3gxD4tq9GR7aSSGKJyt02PiCEO0JpyyIbHZ9xbck9kw==</CipherValue>
          </CipherData>
        </EncryptedKey>
      </KeyInfo>
      <CipherData>
        <CipherValue>TeV0yJaFlEhpyZUlQoG7M3O7sfQ7uG3ndgmhxipOrwoEsrI+Zvt1NI7arefOFWGNW4CEaoLo4mKy2Kwr4ZgK+6rAwOmx1IRyheWtF7z/8+CiGOqSRXLyGEkDQBEVOWKU0Y6TaWtPu0ZM3bp5pvKaztBnthgGnrGYmigaufu5rZW1GWPtHyL2iWdAkU9iaf+AOpA/GSvoVtZmnfJ1rwy6U8PTO0h0Ws/PdkcOKuXGkx31t/Y32ivFoy7xYPnPt/Z/aNMiHvbO7faQAwuJ/NsG9G1FFRRHCqc73TUsRdKHVuf17BEp526RG6RBZtM3F3V3o0d8/sLmyrNI9tFfksB4qcWiN4P+BRtGr0iacmBfBOvAFSozfUYxjMpx+BYPOpD1pf4fMFoKxxKeJYY31XqZoQLp75RgmWhWYm8URHq4Cjs=</CipherValue>
      </CipherData>
    </EncryptedData>
  </connectionStrings>

Вот и все (для Windows IIS). Ключ configProtectionProvider сообщит вашему приложению, какой класс дешифрования и сертификат использовать. Если это не сработает, повторно запустите описанную выше команду Import-PfxCertificate.

Шифрование пользовательских разделов конфигурации

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

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

 <configSections>
    <section name="protectedSettings" type="MyConfigSectionHandler.MyHandler, WebApplication1" />
  </configSections>

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

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

aspnet_regiis -pef "protectedSettings" "." -prov "Pkcs12Provider"

Особые рекомендации для Azure App Services

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

  <add name=“Pkcs12Provider” thumbprint=“1234123412341234123412341234123412341234" type=“WebConfigEncrypter.Pkcs12ProtectedConfigurationProvider, WebConfigEncrypter” storeLocation=“CurrentUser”/>

Перевод статьи подготовлен в преддверии старта курса C# ASP.NET Core разработчик. Приглашаем всех на бесплатный урок курса, в рамках которого познакомимся с видами баз данных. Разберем как работать с реляционными и нереляционными базами данных — напрямую и через ORM. Регистрация доступна по ссылке.

• Зарегистрироваться на бесплатный урок

Данный материал является переводом оригинальной статьи «ATA Learning : Michael Soule : Manage Certs with Windows Certificate Manager and PowerShell».

Работа с сертификатами обычно является одной из тех дополнительных задач, которые вынужден брать на себя системный администратор Windows. Диспетчер Сертификатов Windows (Windows Certificate Manager) — это один из основных инструментов, который позволяет выполнять эту работу.

В этой статье мы рассмотрим работу с сертификатами применительно к операционной системе Windows. Если же вы хотите узнать больше о том, как работают сертификаты в целом, ознакомьтесь с сопутствующей статьей «Your Guide to X509 Certificates».

Понимание хранилищ сертификатов

В диспетчере сертификатов Windows все сертификаты находятся в логических хранилищах, называемых «хранилищами сертификатов». Хранилища сертификатов – это «корзины», в которых Windows хранит все сертификаты, которые в настоящее время установлены, и сертификат может находиться более чем в одном хранилище.

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

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

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

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

Сертификаты пользователей

Если вы хотите, чтобы сертификат использовался одним пользователем, то идеальным вариантом будет хранилище пользовательских сертификатов внутри Диспетчера сертификатов Windows. Это общий вариант использования процессов аутентификации на основе сертификатов, таких как проводной IEEE 802.1x.

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

Компьютерные сертификаты

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

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

Сертификаты компьютера находятся в кусте реестра локального компьютера и в подкаталогах \ProgramData. Сертификаты пользователя находятся в кусте реестра текущего пользователя и в подкаталогах \AppData. Ниже вы можете увидеть, где каждый тип хранилища находится в реестре и файловой системе.

Предварительные требования

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

• Windows Vista, Windows Server 2008 или более новая операционная система. В показанных примерах используется Windows 10 Корпоративная версии 1903.
• Знакомство с PowerShell. Хотя это и не обязательно, этот язык будет использоваться для ссылки на сертификаты, где это необходимо. Все показанные примеры были созданы с помощью Windows PowerShell 5.1.
• Вам не потребуется устанавливать какие-либо специальные сертификаты, но использование самозаверяющего сертификата полезно.

Управление сертификатами в Windows

В Windows есть три основных способа управления сертификатами:

• Оснастка консоли управления Microsoft (MMC) сертификатов (certmgr.msc)
• PowerShell
• Инструмент командной строки certutil

В этой статье вы узнаете, как управлять сертификатами с помощью оснастки Certificates MMC и PowerShell. Если вы хотите узнать больше о том, как использовать certutil, ознакомьтесь с документацией Microsoft.

PowerShell против диспетчера сертификатов Windows

Поскольку в Windows можно управлять сертификатами несколькими способами, встаёт вопрос выбора, что лучше использовать — GUI (MMC) или командную строку с PowerShell.

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

Давайте сначала посмотрим, как обнаружить сертификаты, установленные в Windows, с помощью диспетчера сертификатов и PowerShell.

Использование диспетчера сертификатов Windows (certmgr.msc)

Чтобы просмотреть сертификаты с помощью MMC, откройте Диспетчер сертификатов: откройте меню «Пуск» и введите certmgr.msc. Это вызовет Windows Certificates MMC. Это начальное представление предоставит обзор всех логических хранилищ, отображаемых в левом окне.

На снимке экрана ниже видно, что выбрано логическое хранилище доверенных корневых центров сертификации

Картинка с сайта: blog.it-kb.ru

Просмотр физических хранилищ

По умолчанию Диспетчер сертификатов Windows не отображает физические хранилища. Чтобы показать их, в верхнем меню оснастки выбирайте «View» > «Options«. Затем вы увидите варианты отображения физических хранилищ сертификатов. Включение этого параметра упрощает определение конкретных путей в Windows.

Теперь вы можете видеть, что дополнительные контейнеры показаны в примере логического хранилища доверенных корневых центров сертификации, показанном ранее. Сертификаты по-прежнему сгруппированы относительно их логических хранилищ, но теперь вы можете увидеть физическое хранилище «Реестр».

Картинка с сайта: blog.it-kb.ru

Проверка атрибутов в диспетчере сертификатов Windows

Есть много атрибутов сертификата, которые вы можете увидеть при просмотре их с помощью MMC. Например, вы, вероятно, захотите выбрать определенные сертификаты по их атрибутам. Самый простой способ сделать это — указать Serial Number сертификата или значение Thumbprint. Если сертификат был подписан центром сертификации (CA), при выдаче он будет иметь серийный номер. Thumbprint вычисляется каждый раз при просмотре сертификата.

Вы можете увидеть некоторые атрибуты сертификата, открыв его в MMC, как показано ниже.

Картинка с сайта: blog.it-kb.ru

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

Чтобы быстро отличать сертификаты с соответствующим закрытым ключом и без него, посмотрите на значок сертификата. В Диспетчере сертификатов Windows, если значок просто выглядит как лист бумаги с лентой, соответствующий закрытый ключ отсутствует. Если у сертификата есть закрытый ключ, вы увидите ключ на значке MMC, и ключ в нижней части вкладки «Общие» при открытии сертификата

Картинка с сайта: blog.it-kb.ru

Использование PowerShell по физическому хранилищу

Как и в случае с MMC, вы можете просматривать сертификаты и управлять ими с помощью PowerShell. Давайте сначала проверим сертификаты в их физических хранилищах (реестр и файловая система).

Используя PowerShell командлет Get-ChildItem, вы можете перечислить все ключи и значения внутри родительского пути в реестре. Приведенная ниже команда перечислит все сертификаты вошедшего в систему пользователя в логическом хранилище промежуточных центров сертификации.

Get-ChildItem -Path 'HKCU:\Software\Microsoft\SystemCertificates\CA\Certificates'

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

Картинка с сайта: blog.it-kb.ru

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

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

Get-ChildItem -Path $env:APPDATA\Microsoft\SystemCertificates\My\Certificates\

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

Get-ChildItem -Path $env:APPDATA\Microsoft\SystemCertificates\My\Keys\

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

Get-ChildItem -Path $env:APPDATA\Microsoft\Crypto\Keys

Использование PowerShell по логическому хранилищу

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

PowerShell может получить доступ к логическим хранилищам Windows с помощью PSDrive-объекта «Cert:\«, который сопоставляет сертификаты с физическими хранилищами так же, как это делает MMC.

К сожалению, MMC и «Cert:» не маркируют логические хранилища одинаково. Ниже вы можете увидеть сравнительную таблицу общих хранилищ и их названий как в MMC, так и в «Cert:» PSDrive.

Выбор сертификатов

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

Для следующих примеров вам нужно начать с перечисления всех установленных сертификатов в хранилище корневого ЦС.

Get-ChildItem -Path 'Cert:\CurrentUser\Root\'

Возвращенные объекты будут объектами сертификатов, которые вы можете использовать в следующих примерах.

Общие расширения уже доступны как свойства объектов сертификата. В приведенном ниже примере вы используете Get-Member для вывода списка всех свойств возвращаемых объектов.

Get-ChildItem -Path 'Cert:\CurrentUser\Root\' | Get-Member -MemberType Properties

Картинка с сайта: blog.it-kb.ru

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

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

Покажем пример взаимодействия с свойствами типа ScriptProperty. В приведенной ниже команде вы извлекаете Key Usages.

((Get-ChildItem -Path 'Cert:\CurrentUser\Root\' | Select -First 1).Extensions | Where-Object {$_.Oid.FriendlyName -eq 'Key Usage'}).format($true)

Новая часть, которую мы вводим в приведенной выше команде, — это метод форматирования, который выполняет декодирование ASN.1. Вы передаете ему логическое значение (например, $true), чтобы определить, хотим ли мы, чтобы возвращаемый объект был однострочным или многострочным.

Попробуем использовать значение Thumbprint из сертификата в приведенной ниже команде. Значение Thumbprint устанавливается как переменная PowerShell и используется для выбора конкретного сертификата в приведенных ниже командах.

$thumb = "cdd4eeae6000ac7f40c3802c171e30148030c072"
Get-ChildItem -Path 'Cert:\CurrentUser\Root\' | Where-Object {$_.Thumbprint -eq $thumb}

Создание самозаверяющих (self-signed) сертификатов с помощью PowerShell

PowerShell может создавать самозаверяющие (self-signed) сертификаты с помощью командлета New-SelfSignedCertificate. Самозаверяющие сертификаты полезны для тестирования, поскольку они позволяют генерировать пару открытого и закрытого ключей без использования центра сертификации.

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

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

New-SelfSignedCertificate -Subject 'User-Test' -CertStoreLocation 'Cert:\CurrentUser\My'
New-SelfSignedCertificate -Subject 'Computer-Test' -CertStoreLocation 'Cert:\LocalMachine\My'

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

Импорт и экспорт сертификатов в MMC

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

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

Экспорт сертификатов из MMC относительно прост. Чтобы экспортировать сертификат без закрытого ключа, щелкните сертификат в MMC, выберите меню «Все задачи», а затем «Экспорт».

Во время экспорта вам будет предложено указать формат файла, как показано ниже. Наиболее распространены варианты кодирования — DER или Base-64

Картинка с сайта: blog.it-kb.ru

Экспорт закрытых ключей

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

• Вошедшая в систему учетная запись должна иметь разрешение на закрытый ключ (только для сертификатов компьютеров);
• Закрытый ключ должен быть помечен как экспортируемый.

Чтобы проверить разрешения для закрытых ключей локального компьютера, вы можете выбрать сертификат с закрытым ключом, выбрать «Все задачи» и «Управление закрытыми ключами» в MMC «Сертификаты». В открывшемся диалоговом окне отображаются записи управления доступом для закрытых ключей.

Когда выше обозначенные условия выполнены, вы можете выбрать сертификат, щелкнуть «Все задачи», а затем «Экспорт», как если бы вы использовали сертификат только с открытым ключом. При экспорте теперь у вас должна присутствовать возможность выбора экспорта закрытого ключа («Yes, export the private key»), как показано ниже.

Картинка с сайта: blog.it-kb.ru

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

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

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

Функция импорта одинакова для всех поддерживаемых типов файлов сертификатов. Единственная разница в том, что если файл содержит закрытый ключ, вы можете «Отметить этот ключ как экспортируемый», о чем вы узнаете подробнее ниже. Windows будет использовать мастер импорта сертификатов.

Картинка с сайта: blog.it-kb.ru

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

Сертификаты для подписи кода PowerShell — хороший вариант использования надежной защиты закрытого ключа.

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

Импорт и экспорт сертификатов в PowerShell

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

$certificate = Get-Item (Get-ChildItem -Path 'Cert:\CurrentUser\My\' | Where-Object {$_.Subject -eq $_.Issuer}).PSPath

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

Export-Certificate -FilePath $env:USERPROFILE\Desktop\certificate.cer -Cert $certificate

Теперь давайте посмотрим на экспорт закрытого ключа. Ниже вы проверяете, что у выбранного сертификата есть закрытый ключ. Если он не возвращает True, то команда Get-Item, скорее всего, выбрала неправильный сертификат.

$certificate.HasPrivateKey

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

$pfxPassword = "ComplexPassword!" | ConvertTo-SecureString -AsPlainText -Force
Export-PfxCertificate -FilePath $env:USERPROFILE\Desktop\certificate.pfx -Password $pfxPassword -Cert $certificate

В случае, если необходимо выполнить импорт, как и при экспорте, есть две команды. Одна команда для импорта сертификатов и одна для импорта файлов PFX.

Ниже команда Import-Certificate импортирует файл в формате DER, который вы экспортировали ранее, в личное хранилище текущего пользователя.

Import-Certificate -FilePath $env:USERPROFILE\Desktop\certificate.cer -CertStoreLocation 'Cert:\CurrentUser\My'

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

$pfxPassword = "ComplexPassword!" | ConvertTo-SecureString -AsPlainText -Force
Import-PfxCertificate -Exportable -Password $pfxPassword -CertStoreLocation 'Cert:\CurrentUser\My' -FilePath $env:USERPROFILE\Desktop\certificate.pfx

Имейте в виду, что пароль должен быть защищенной строкой. Кроме того, если вы импортируете в хранилище локального компьютера (например, «Cert:\LocalMachine«), вам нужно будет запустить команду из командной строки администратора с повышенными привилегиями.

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

Удаление сертификатов с помощью PowerShell

При удалении сертификатов помните, что понятие «Корзина Windows» в этом случае отсутствует. Как только вы удалите сертификат, он исчезнет! Это означает, что очень важно подтвердить, что вы удаляете правильный сертификат, путем проверки уникального идентификатора, такого как серийный номер или значение расширения Thumbprint.

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

$certificate = Get-Item (Get-ChildItem -Path 'Cert:\CurrentUser\My\' | Where-Object {$_.Subject -eq $_.Issuer}).PSPath

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

$certificate.Thumbprint
$certificate.SerialNumber
$certificate.Subject

Убедитесь, что вы выбрали правильный сертификат, который собираетесь удалить.

Приведенная ниже команда удаляет все выбранные объекты сертификата, используйте с осторожностью! Передав объект $certificate через конвейер в командлет Remove-Item в приведенной ниже команде, вы удалите все содержимое сертификата без каких-либо запросов на проверку.

$certificate | Remove-Item

Резюме

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

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

Немного теории

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

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

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

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

Для чего это нужно?

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

• PWA-приложения,
• приложения, использующие WebRTC.

Есть два способа выполнить эту задачу:

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

Подготовка

Нам понадобится OpenSSL. Инсталляторы-бинарники для Windows.

Файл конфигурации openssl.cfg

			[ req_distinguished_name ]
countryName         = CO
stateOrProvinceName = ST
localityName        = ST
organizationName    = O

####################################################################
# Extensions for when we sign normal certs (specified as default)
[ usr_cert ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
subjectAltName = email:move

####################################################################
# Same as above, but cert req already has SubjectAltName
[ usr_cert_has_san ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer

####################################################################
# Extensions to use when signing a CA
[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true
subjectAltName=email:move

####################################################################
# Same as above, but CA req already has SubjectAltName
[ v3_ca_has_san ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
basicConstraints = CA:true

[ req ]
prompt             = no
default_bits       = 4096
distinguished_name = req_distinguished_name
req_extensions = req_ext

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.0 = example.com
DNS.1 = *.example.com
		

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

1. Генерируем приватный ключ:

			mkdir example.com
openssl genrsa -out example.com/example.com.key
		

Результат:

			Generating RSA private key, 2048 bit long modulus (2 primes)
........................+++++
..........................................................+++++
e is 65537 (0x010001)
		

2. Создаем запрос на сертификат:

			openssl req -new -key example.com/example.com.key -out
example.com/example.com.csr -config openssl.cfg -subj
"/CN=example.com certificate"
		

3. В файле конфигурации openssl.cfg нужно прописать доменное имя или несколько имен в блоке [alt_names].Раньше поддерживалось только одно имя, которое задавалось в поле CN, но сейчас можно указать несколько имен, а также сделать wildcard-сертификат на все поддомены.

			[ alt_names ]
DNS.0 = example.com
DNS.1 = *.example.com
		

4. Генерируем сертификат:

			openssl x509 -req -in example.com/example.com.csr -extensions
req_ext -extfile openssl.cfg -signkey
example.com/example.com.key  -out example.com/example.com.crt
-days 1825
		

5. Проверяем результат:

			openssl x509 -in example.com/example.com.crt -text
		

Результат:

			Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            0f:63:6b:b8:76:27:71:d1:e9:f3:53:01:11:11:7c:52:d6:c7:ea:c6
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = example.com certificate
        Validity
            Not Before: Sep 27 05:08:48 2022 GMT
            Not After : Sep 26 05:08:48 2027 GMT
        Subject: CN = example.com certificate
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:c9:...:3b:24:
                    26:0f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:*.example.com
    Signature Algorithm: sha256WithRSAEncryption
         20:a9:...:fe:fd:
         5f:30:e8:4a
-----BEGIN CERTIFICATE-----
MIIC+zCCAeO…8w6Eo=
-----END CERTIFICATE-----
		

Теперь у вас есть сам сертификат example.com.crt и файл ключа example.com.key, которые можно использовать в ваших приложениях.

Генерируем корневой сертификат + сертификат сервера

1. Генерируем приватный ключ корневого сертификата:

			mkdir ca
openssl genrsa -out ca/ca.key
		

Результат:

			Generating RSA private key, 2048 bit long modulus (2 primes)
...........................................+++++
...................................+++++
e is 65537 (0x010001)
		

2. Создаем сертификат:

			openssl req -x509 -new -key ca/ca.key -days 1825 -out ca/ca.crt
-extensions v3_ca_has_san -config openssl.cfg -subj "/CN=Root CA
		

3. Повторяем шаги 1-5 инструкции про самоподписанный сертификат.

4. Генерируем сертификат, подписанный нашим корневым сертификатом:

			openssl x509 -req -in example.com/example.com.csr -CA ca/ca.crt
-CAkey ca/ca.key -CAcreateserial -extensions req_ext -extfile
openssl.cfg -out example.com/example.com.ca.crt -days 1825
		

5. Проверяем результат:

			openssl x509 -in example.com/example.com.ca.crt -text
		

Результат:

			Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            27:f4:ec:08:a8:36:b8:38:81:53:d9:8f:b5:fe:91:13:79:f0:9e:dc
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Root CA
        Validity
            Not Before: Sep 27 05:46:19 2022 GMT
            Not After : Sep 26 05:46:19 2027 GMT
        Subject: CN = example.com certificate
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:c9:...:26:0f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:*.example.com
    Signature Algorithm: sha256WithRSAEncryption
         9e:72:...:57:17
-----BEGIN CERTIFICATE-----
MIIC…JXFw==
-----END CERTIFICATE-----
		

Теперь у вас есть сертификат сервера example.com.crt в комплекте с ключом example.com.key, а также корневой сертификат ca.crt в комплекте с ключом ca.key. Если добавить корневой сертификат в хранилище корневых сертификатов в вашей системе или браузере, то это сделает валидными все сертификаты, подписанные им.

Браузер Chrome использует системное хранилище сертификатов:

Картинка с сайта: tproger.ru

Добавляем корневой сертификат в браузере Mozilla

Картинка с сайта: tproger.ru

Картинка с сайта: tproger.ru

Возможно, придется отключить DNS over HTTPS, чтобы браузер использовал системный DNS, который, в свою очередь, использует файл hosts.

Картинка с сайта: tproger.ru

Картинка с сайта: tproger.ru

Использование на примере create-react-app

1. Добавляем в .env следующие переменные:

			HTTPS=true
SSL_CRT_FILE=certs/example.com.crt
SSL_KEY_FILE=certs/example.com.key
HOST=example.com
		

2. Добавляем в файл host (C:WindowsSystem32Driversetchosts для Windows, /etc/hosts для Ubuntu) строку:

			192.168.2.116 example.com
		

чтобы example.com резолвился на локальный адрес компьютера (свой можно посмотреть в свойствах подключения).

3. Запускаем приложение и видим, что соединение защищено и сертификат валидный:

Картинка с сайта: tproger.ru

Как установить сертификат на мобильное устройство Android?

1. Поместить телефон и ПК в одну локальную сеть.

2. Использовать create-react-app.

3. Положить в папку public ca.crt.

4. Прописать в .env адрес компьютера в локальной сети:

5. Запустить create-react-app без https.

6. Открыть на телефоне http://192.168.2.116:3000/ca.crt и установить сертификат:

Картинка с сайта: tproger.ru

Как прописать домен на Android устройстве?

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

1. Имея root-доступ на смартфоне, отредактировать файл hosts.

2. Если прав root нет, то есть более элегантное решение — воспользоваться приложением Postern. Это VPN-сервер, запускаемый на вашем устройстве и способный модифицировать трафик, в том числе перехватывать DNS-запросы и отвечать на них. Через него можно установить соответствие доменного имени example.com ip-адресу вашего компьютера в локальной сети, где запущен webpack-dev-server:

Картинка с сайта: tproger.ru

То, что Postern запущен, можно понять по иконке замка в статус-баре (VPN включен, все запросы идут через него).

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

Картинка с сайта: tproger.ru

Готово! Теперь вы не только знаете в теории, что такое SSL-сертификат, но и умеете с ним работать на практике.

Начало:
1. Криптография: простейшие термины этой науки
2. Система шифрования с открытым ключом
3. Зачем нужны центры сертификации при асимметричном шифровании
4. Зачем нужны самозаверенные сертификаты открытого ключа

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

В операционных системах «Windows» (у меня установлена «Windows 10», так что речь в основном пойдет про нее) сертификаты хранятся на логическом уровне в так называемых «хранилищах» (по-английски «store» или «storage»).

Под «сертификатами» в этом посте имеются в виду файлы цифровых сертификатов открытого ключа (см. подробнее об этом предыдущие посты).

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

На компьютере под управлением операционной системы «Windows 10» существует два главных хранилища сертификатов:

– хранилище компьютера (локальной машины);
– хранилище текущего пользователя.

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

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

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

Подхранилища

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

– Личное;
– Доверенные корневые центры сертификации.

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

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

– стандартный способ через графический (оконный) интерфейс;
– из командной строки в программе-оболочке «PowerShell»;
– различные программы командной строки вроде «certmgr.exe» или «certutil.exe»;
– можно написать программу для работы с сертификатами самому и так далее.

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

Консоль управления Microsoft (MMC)

Операционные системы «Windows» включают очень старый компонент (программу), который называется по-английски «Microsoft Management Console», сокращенно «MMC» (по-русски «Консоль управления Microsoft»). Первая версия этой программы была выпущена в 1998 году, но она до сих пор в строю и ее можно использовать для решения различных административных задач в рамках операционной системы. Насколько я понимаю, актуальная версия этой программы 3.0. Эта версия появилась в составе пакета обновлений SP3 для «Windows XP» (2007-2008 годы) и с тех пор в нее не вносилось заметных изменений. В нашем случае ее можно использовать для работы с хранилищами сертификатов.

Исполняемый файл этой программы — «mmc.exe». Ее можно вызвать с помощью команды «mmc» из любого местоположения, так как она хранится в системной папке %windir%\System32\. Я обычно набираю команду «mmc» в строке поиска «Windows 10» возле кнопки «Пуск», поиск находит эту программу и выдает ссылку «Открыть» для ее запуска.

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

Этих модулей довольно много, их можно добавить в консоль через меню «Файл – Добавить или удалить оснастку…». По-английски такой модуль называют «snap-in». Почему выбрано такое название — не знаю, обычно такие модули по-английски называют «plug-in» (по-русски «плагин»). Думаю, эти слова можно считать синонимами. Слово «snap-in» на русский язык почему-то перевели как «оснастка». По-моему, такой перевод — это вообще пальцем в небо. У меня слово «оснастка» ассоциируется с морскими кораблями, парусниками. Но такой перевод сложился уже давно и все к нему привыкли. Хотя по слову «оснастка» нелегко сообразить, что в английском это «snap-in».

После составления своей «площадки» (консоли) с оснастками эту площадку можно сохранить в файл с расширением «.msc» (аббревиатура «MSC» расшифровывается как «Microsoft Saved Console», по-русски «сохраненная консоль Microsoft»). В дальнейшем этот файл можно поместить на рабочий стол и запускать именно его. Файлы с расширением «.msc» по умолчанию привязаны к программе «mmc.exe» и передаются ей в качестве входного параметра.

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

Раньше нужно было создавать свою консоль для оснасток, предназначенных для работы с хранилищами сертификатов. Но в операционной системе «Windows 10» есть встроенные сохраненные консоли с нужными оснастками для работы с хранилищами сертификатов. Поэтому напрямую вызывать программу «mmc.exe» и работать с нею теперь не требуется (если нужно выполнить только манипуляции с сертификатами в хранилищах сертификатов).

Для запуска встроенной в операционную систему сохраненной консоли для работы с хранилищем сертфикатов данного компьютера (локальной машины) можно в строке поиска операционной системы (рядом с кнопкой «Пуск») набрать фразу «Управление сертификатами компьютеров» (у меня операционная система «Windows 10» с русскоязычным интерфейсом; в англоязычном интерфейсе, естественно, нужно будет искать на английском). Поиск найдет ссылку «Открыть» для этой сохраненной консоли, по которой и следует перейти. (Напомню, для работы с хранилищем сертификатов компьютера требуются права администратора.) Вот как окно этой сохраненной консоли выглядит у меня:

Картинка с сайта: ilyachalov.livejournal.com

Очевидно, что это окно программы «mmc.exe» с загруженной в него сохраненной консолью из файла «certlm.msc». Обратите внимание на заголовок окна с названием файла: certlm (расширение не указано, но оно есть, просто в заголовке окна оно опущено). Окончание «lm» в этом слове расшифровывается как «local machine» (по-русски в этом случае можно перевести как «данный компьютер»). Файл «certlm.msc» расположен в той же папке %windir%\System32\, что и файл «mmc.exe», поэтому его тоже можно вызвать из любого местоположения из командной строки командой «certlm».

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

Картинка с сайта: ilyachalov.livejournal.com

Опять же, это окно программы «mmc.exe» с загруженной в него сохраненной консолью из файла «certmgr.msc». Название «certmgr» расшифровывается как «Certificate Manager» (по-русски «Менеджер сертификатов» или «Диспетчер сертификатов»). Для работы с этой сохраненной консолью не требуется прав администратора операционной системы, достаточно прав текущего пользователя. Опять же, файл «certmgr.msc» хранится в той же папке %windir%\System32\, о которой уже дважды было упомянуто ранее. Его можно запустить из любого местоположения из командной строки с помощью команды «certmgr».

Важно отметить, что сохраненная консоль «certmgr.msc» и программа командной строки «certmgr.exe» — это разные вещи. Не следует их путать.

Ссылки по теме:

https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/working-with-certificates

https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-view-certificates-with-the-mmc-snap-in