Ответ 1
Ответ, предоставленный @nico, имеет правильные утверждения, но заставил меня осознать, что в этом было нечто большее, чем я первоначально описывал. Поэтому я очистил заголовок вопроса и вопрос, чтобы обеспечить лучший вопрос и последующий ответ.
Исследуя сеть, я нашел много таких ответов в самых разных местах, например, вопросы, ответы в комментариях, YouTube и т.д. Я решил поместить все это в удобное и аккуратное место, чтобы каждый мог найти и изучить.
Во-первых, нужно спросить себя, для чего они используют приложение? Будет ли приложение загружено в Microsoft Store или предназначено только для внутреннего использования.
В любом случае вы захотите отладить и разработать приложение. Отладка не требует установки сертификата, поэтому в этом смысле мы в безопасности.
Если вы используете приложение для своей организации или просто на локальном компьютере, вам понадобится доверенный сертификат.
Этот сертификат может существовать в нескольких различных сценариях.
- Вам нужен самозаверяющий сертификат или
- Вам нужен выданный сертификат от центра сертификации CA, т.е. вашего предприятия или организации?
Я пойду по обоим сценариям. В любом случае протокол makecert устарел Заметки об устаревании makecert
Сценарий 1. Если вам нужен самозаверяющий сертификат, выполните следующие действия.
- Перейдите на powershell и используйте командлет New-SelfSignedCertificate pkiclient... что позволит вам создать комбинацию .cer и соответствующий закрытый ключ + открытый сертификат =.pfx, если вы создадите для сертификата + закрытый ключ... И вам нужно иметь закрытый ключ, т.е..pfx, чтобы связать и упаковать ваше приложение с Visual Studio и установить его в локальное хранилище приложений Windows (не путать с магазином Microsoft.)
Вот ссылки, по которым нужно следовать *** Прежде чем создавать сертификат, обязательно прочитайте 1А:
Создание подписи пакета сертификатов
New-самозаверенный сертификат
1А. *** Когда вы создаете New-SelfSignedCertificate, вы должны понимать, что сертификат должен быть создан очень специфическим способом. Это для самоподписанного или выданного СА сертификата.
В частности, сертификат должен обладать 2 свойствами
а). Должно быть расширение Basic Constraints, установленное в Subject Type = End Entity. Простыми словами это говорит о том, что... Когда этот сертификат выдается вам, вы не можете сделать так, чтобы сертификат был последующим центром сертификации с возможностью выдавать больше сертификатов. Другими словами... Это конец строки сертификата.
Вы можете прочитать больше об ограничениях здесь: https://blogs.technet.microsoft.com/pki/2014/03/05/constraints-what-they-are-and-how-theyre-used/
б). Значение расширения Enhanced Key Usage (EKU) установлено на подпись кода. Это предотвращает использование сертификата для каких-либо целей, кроме его предназначения... Что означает, что программное обеспечение было получено от издателя программного обеспечения && Защищает программное обеспечение от изменения после публикации.
В деталях сертификата информация будет выглядеть следующим образом:
Подпись кода (1.3.6..1.5.5.7.3.3) & lt; & lt; & lt; & lt; Это OID расширенного использования ключа для подписи кода 1.3.6... число
Эта информация была найдена очень случайно и не в каком-либо конкретном порядке текущей документации:
Создание сертификатов для приложений Магазина Windows
1В. Таким образом, в конечном итоге для использования командлета New-SelfSignedCertifcate через powershell нужно было выполнить команду следующим образом:
New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=YourCompany CA, 0=Your Corporation, C=US" -TextExtension @("2.5.29.19={text}false") -KeyUsage DigitalSignature -KeyLength 2048 -NotAfter (Get-Date).AddMonths(33) -FriendlyName friendlyName2
Приведенная выше команда соответствует обоим критериям сертификата для подписи кода (хотя вместо использования свойства -type можно было бы выбрать oid расширения использования ключа с соответствующим типом подписи кода, т.е. oid подписи кода = 1.3.6.1. 5.5.7.3.3)
Если вы запустите указанную выше команду в powershell, вы создадите 2 вещи, которые теперь можно экспортировать...
А) публичный сертификат B.) закрытый ключ + открытый сертификат, содержащийся в формате файла .pfx.
Теперь, когда у нас есть возможность экспортировать .pfx, вы можете создать пароль и экспортировать файл с закрытым ключом + сертификат .pfx.
- Используя команду, вы запустите командлет в powershell Export-PfxCertificate:
Вот документация Экспорт pfx:
https://docs.microsoft.com/en-us/powershell/module/pkiclient/export-pfxcertificate?view=win10-ps
$pwd = ConvertTo-SecureString -String <Your Password> -Force -AsPlainText
Export-PfxCertificate -cert "Cert:\LocalMachine\My\<Certificate Thumbprint>" -FilePath <FilePath>.pfx -Password $pwd
- На этом этапе у вас есть ключ, который работает с Visual Studio, и теперь вы можете упаковать свое приложение и создать файл .appx или файл appxbundle, который можно будет развернуть в хранилище Windows на локальных машинах.
Подробные инструкции можно найти здесь:
https://docs.microsoft.com/en-us/windows/uwp/packaging/packaging-uwp-apps
Сценарий 2. Если вам нужен доверенный сертификат от центра сертификации вашей организации
Здесь вы должны иметь в виду, что приведенный выше раздел важен, но вам нужно будет оценить разницу между самозаверяющим сертификатом и доверенным корневым сертификатом CA и/или последующим CA.
Ну, вот один из способов понять это. Корневым сертификатом при его создании был сертификат SelfSigned. Тем не менее, он имеет возможность выдавать сертификаты другим для различных вещей. то есть авторизация на сервере или подпись кода... Подумайте, основные ограничения НЕОГРАНИЧЕННЫЕ. И он также может выдавать другие центры сертификации, которые могут выдавать сертификаты другим по ряду причин.
Это называется цепочкой сертификатов. Помните, что сертификат, который мы хотим для наших целей, является концом этой цепочки... Basic Constraints = LIMITED до 0 или false, что означает, что он должен быть подписан как End-endtity или Certificate Authroity = false... в другом слова, которые вы не можете выдать дальнейшие сертификаты по любой причине из этого сертификата, который был выпущен.
Так как это для приложения, которое просто необходимо установить и использовать. Это имеет смысл.
Опять же, прочитайте эту ссылку: https://blogs.technet.microsoft.com/pki/2014/03/05/constraints-what-they-are-and-how-theyre-used/
Итак, для следующего сегмента я собираюсь объяснить шаги для запроса сертификата у вашего центра сертификации через запрос сертификата. В мире Linux через openssl это называется .csr... В мире powershell это называется .req
Если вы правильно установите параметры... конечный результат - это файл, который может быть прочитан веб-сайтом проверки openssl или сертификатом со сменным расширением .req или .csr
Powershell может создавать это с помощью командлета CertReq
- .Вы просто используете эту команду вместе с передачей файла .inf, который создаст ваш запрос сертификата .req
certreq -new TestReqConfig.inf MyRequest.req
- Файл .inf будет содержать параметры для ключа и информацию о сертификате, как при создании сертификата new-selfsigned на основе приведенной выше информации.
INF файл будет выглядеть так:
[NewRequest]
Subject = "C=US,ST=Florida,L=City,O=Your Company Information,OU=City
Information,CN=certname.com"
Requesttype = PKCS10
Exportable = TRUE
HashAlgorithm = md5
KeyAlgorithm = RSA
KeyLength = 2048
KeyUsage = CERT_DIGITAL_SIGNATURE_KEY_USAGE
FriendlyName = "FriendlyName CERT"
[Extensions]
2.5.29.19 = "{text}false"
2.5.29.37 = "{text}1.3.6.1.5.5.7.3.3"
Requesttype = PKCS10 позволяет работать с декодером openssl csr... и все остальное объясняется через эти сайты:
Декодер работает, открывая файл создания и получая промежуточную информацию
-----BEGIN NEW CERTIFICATE REQUEST-----
-----END NEW CERTIFICATE REQUEST-----
Я надеюсь, что эта информация поможет кому-то узнать о сертификатах и о том, как они используются при упаковке и создании приложений для магазина Windows.