如何通过 Visual Studio 2019、2017 和 2015 为 Windows 10 UWP 应用程序创建有效的可信和/或自签名证书 [英] How to create a working trusted and or self-signed certificate for a Windows 10 UWP application via Visual Studio 2019, 2017 and 2015

问题描述

根据本文档:

https://docs.microsoft.com/en-我们/windows-hardware/drivers/devtest/makecert

以下命令描述了如何创建 windows cer 文件(即来自受信任提供商的证书.)

问题在于，在 Visual Studio 2017 中构建应用程序时，它只允许通过 package.windows10.appxmanifest 生成 pfx 文件.更新此命令行参考时，它不会生成 pvk 文件，因此需要添加

MakeCert -r -pe -ss PrivateCertStore -n "CN=Contoso.com(Test)" testcert.cer

额外的命令行选项，例如/sv SubjectKeyFile，它将生成生成的 pvk 文件.

但是，即使使用此命令行参考:

MakeCert -r -pe -ss PrivateCertStore -n "CN=Contoso.com(Test)" -sv testcert.pvk testcert.cer

将生成的证书文件植入到 Visual Studio 中产生此错误:

<块引用>

清单设计器无法导入证书.

您选择的证书不能用于签名，因为它已过期或有其他问题.有关更多信息，请参阅http://go.microsoft.com/fwlink/?LinkID=241478>

我转到链接，但没有任何内容真正解释发生了什么.一个人评论创建一个临时的有效但它是仅持续一年的非特定测试证书.

有没有更好的方法来使用 makecert 创建脚本?我怎么知道证书最终是否正确构建?其他文档会有所帮助，但我还没有找到其他任何东西.

解决方案

@nico 提供的答案有正确的陈述，但让我意识到问题比我最初描述的要多.所以我清理了问题标题和问题，以提供更好的问题和后续答案.

在网上搜索我在很多不同的地方找到了很多这样的答案，例如问题、评论中的答案、youtube 等...我决定将它们全部放在一个漂亮整洁的地方，以便每个人都可以提供资源和学习.

首先，人们必须问自己他们使用该应用程序的目的是什么?应用程序是要上传到 Microsoft Store 还是仅供内部使用.

无论哪种方式，您都希望调试和开发应用程序.调试不需要安装证书，所以从这个意义上说我们是安全的.

如果您在组织内部或仅在本地计算机上使用该应用程序，那么您将需要一个受信任的证书.

此证书可以存在于几种不同的场景中.

1. 您是否需要自签名证书或
2. 您是否需要 CA 证书颁发机构(即您的企业或组织)颁发的证书?

我将讨论这两种情况.无论哪种情况，都不推荐使用 makecert 协议 makecert 弃用说明

场景 1:如果您需要自签名证书，您将如何进行

1. 转到 powershell 并使用 New-SelfSignedCertificate pkiclient cmdlet...这将为您提供 .cer 和相应的私钥 + 公共证书组合 = .pfx(如果您为证书 + 私钥构建)的创建...而且您必须有一个私钥，即 .pfx，以便将您的应用程序与 Visual Studio 捆绑和打包，并将其安装到本地 Windows 应用程序商店(不要与 Microsoft 商店混淆.)

以下是要遵循的链接***请务必在创建证书之前先阅读 1A:

创建证书包签名
New-SelfSignedCertificate

1A.*** 创建 New-SelfSignedCertificate 时，您必须了解必须以非常特定的方式创建证书.这是用于自签名或 CA 颁发的证书.

具体来说，证书必须具备2个属性

a).必须有一个基本约束扩展设置为主题类型=结束实体.简单来说，这就是说...当此证书颁发给您时，您不能让该证书成为能够颁发更多证书的进一步后续证书颁发机构.换句话说......这是行证书的结束.

您可以在此处阅读有关约束的更多信息:https://blogs.technet.microsoft.com/pki/2014/03/05/constraints-what-they-and-how-theyre-used/

b).增强型密钥使用 (EKU) 扩展的值设置为代码签名.这样做是为了防止证书被用于其预期目的以外的任何其他用途......确保软件来自软件发行商&&&&&&&&&保护软件在发布后不被更改.
在证书的详细信息中，信息将如下所示:

代码签名(1.3.6..1.5.5.7.3.3)<<<<<这是用于对 1.3.6... 编号进行代码签名的增强型密钥使用 OID

此信息是非常随机地发现的，并且没有按照流动文档的任何特定顺序，在这里:

为Windows 应用商店应用

1B.因此，最终通过 powershell 使用 New-SelfSignedCertifcate cmdlet 将运行如下命令:

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) -FriendlyNamefriendlyName2

上述命令满足代码签名证书的两个标准(尽管您可以选择具有相应代码签名类型的密钥使用扩展 oid 代替 -type 属性，即代码签名 oid= 1.3.6.1.5.5.7.3.3)

如果您在 powershell 中运行上述命令，您将创建 2 个现在可以导出的东西...

A.) 公共证书B.) 包含在 .pfx 文件格式中的私钥 + 公共证书.

既然我们能够导出 .pfx，这就是您创建密码和导出私钥 + 证书 .pfx 文件的方法.

2. 使用您将在 powershell Export-PfxCertificate 中运行 cmdlet 的命令:

这是导出 pfx 文档:

https://docs.microsoft.com/en-us/powershell/module/pkiclient/export-pfxcertificate?view=win10-ps

 $pwd = ConvertTo-SecureString -String <您的密码>-Force -AsPlainTextExport-PfxCertificate -cert "Cert:LocalMachineMy"-FilePath <FilePath>.pfx -Password $pwd

3. 此时您有一个可用于 Visual Studio 的密钥，您现在可以打包您的应用程序并生成一个 .appx 文件或 appxbundle 文件，这些文件将能够部署到本地计算机 Windows 商店.

可在此处找到详细说明:

https://docs.microsoft.com/en-us/windows/uwp/packaging/packaging-uwp-apps

场景 2:如果您需要来自组织证书颁发机构的可信证书

此处您必须记住的是，上述部分是相关的，但您需要了解自签名证书与受信任的根证书 CA 和/或后续 CA 之间的区别.

好吧，这是理解它的一种方式.最初的根证书是自签名证书.但是，它有能力向其他人颁发各种证书.即服务器授权或代码签名......想想基本约束无限制.它还可以颁发其他证书颁发机构，这些颁发机构可以出于各种原因向其他人颁发证书.

这被称为证书链.记住上面的内容，我们想要的证书是这个链的末端...... Basic Constraints = LIMITED to 0 or false，这意味着它必须被签名为 End-endtity 或 Certificate Authroity = false... 其他换句话说，您不能出于任何原因从颁发的此证书中颁发更多证书.

因为这是一个只需要安装和使用的应用程序.这是有道理的.

再次阅读此链接:https://blogs.technet.microsoft.com/pki/2014/03/05/constraints-what-they-and-how-theyre-used/

因此，对于下一部分，我将解释通过证书请求从您的证书颁发机构请求证书的步骤.在通过 openssl 的 linux 世界中，这被称为 .csr ... 在 powershell 世界中，这被称为 .req

当你把参数设置得恰到好处......最终结果是一个可以被openssl或证书验证网站读取的文件，扩展名为.req或.csr

Powershell 能够通过名为 CertReq 的 cmdlet 来创建它

1. 您只需使用此命令并传入一个 .inf 文件即可创建您的 .req 证书请求

certreq -new TestReqConfig.inf MyRequest.req

2. .inf 文件将包含密钥参数和证书信息，就像根据上述信息创建新的自签名证书时一样.

.inf 文件如下所示:

[NewRequest]主题 = "C=US,ST=Florida,L=City,O=Your Company Information,OU=City信息,CN=certname.com"请求类型 = PKCS10可导出 = TRUE哈希算法 = md5密钥算法 = RSA密钥长度 = 2048KeyUsage = CERT_DIGITAL_SIGNATURE_KEY_USAGEFriendlyName = "FriendlyName CERT"[扩展]2.5.29.19 = "{text}false"2.5.29.37 = "{文本}1.3.6.1.5.5.7.3.3"

Requesttype = PKCS10 允许它与 openssl csr 解码器一起使用......其他所有内容都通过这些网站进行了解释:

解码器的工作原理是打开创建文件并获取中间创建的信息

-----开始新的证书请求-------结束新的证书请求-----

CertReq 文档

req/csr 解码器

我希望这些信息可以帮助人们了解证书以及它们如何用于打包和创建 Windows 商店应用程序.

Per this documentation:

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/makecert

The following command describes creating a windows cer-file (i.e. a certificate from a trusted provider.)

The issue with this is that when building an application in visual studio 2017 it only allows, via the package.windows10.appxmanifest, a pfx file. when updating the this command line reference it doesn't produce a pvk file so one needs to add

MakeCert -r -pe -ss PrivateCertStore -n "CN=Contoso.com(Test)" testcert.cer

additional command line options such as /sv SubjectKeyFile which will produce the resulting pvk file.

However even using this command line reference:

MakeCert -r -pe -ss PrivateCertStore -n "CN=Contoso.com(Test)" -sv testcert.pvk testcert.cer

The resulting cert file implantation into visual studio produces this error:

The manifest designer could not import the certificate.

The certificate you selected is not valid for signing because it is either expired or has another issue. For more information, see http://go.microsoft.com/fwlink/?LinkID=241478

I go to the link and nothing explains really what is going on. One person comments to create a temporary one that works but it is a nonspecific test cert that lasts only a year.

Is there a better way to create the script with makecert? How do I know if the cert is ultimately building correctly or not? Additional documentation would be helpful but I have not found anything else.

解决方案

The answer provided by @nico has correct statements but made me realize there was more to the issue than I was initially describing. So I cleaned up the question title and question to provide a better question and subsequent answer.

Scouring the web I found many of these answers in so many different places, e.g. questions, answers in comments, youtube, etc... I have decided to put it here all in a nice neat place so everyone can resource and learn.

First, one must ask themselves what are they using the application for? Is the application going to be uploaded to the Microsoft Store or it is only to be used internally.

Either way you are going to want to debug and develop the application. Debugging does not require a certificate to be installed so in that sense we are safe.

If you are using the application internally for your organization or simply on your on local machine then you will need a trusted certificate.

This certificate can exist in a couple of different scenarios.

1. Are you needing a self-signed certificate or
2. Are you needing an issued certificate from a CA certificate authority i.e. your enterprise or organization?

I will go over both scenarios. In either case the makecert protocol is deprecated makecert deprecation notes

Scenario 1: If you are needing a self-signed certificate this how you would proceed

1. Go to powershell and utilize the New-SelfSignedCertificate pkiclient cmdlet... what this will do is provide you the creation of a .cer and corresponding private key + public certificate combination = .pfx if you build for the cert + private key... And you have to have a private key, i.e. .pfx, in order to bundle and package your application with Visual Studio and install it into the local windows applications store (not to be confused with the Microsoft store.)

Here are the links to follow ***Be sure to read 1A first before creating your certificate:

Create Certificate Package Signing
New-SelfSignedCertificate

1A. *** When you create the New-SelfSignedCertificate you must understand that the certificate has to be created in a very specific way. This is for self-signed or a CA'd issued certificate.

Specifically, the certificate has to possess 2 properties

a). There has to be a Basic Constraints extension set to Subject Type=End Entity. What this is saying in simple terms is this... When this certificate is issued to you you cannot have the certificate be a further subsequent Certificate Authority with the ability to issue out more certificates. In other words... This is an end of the line certificate.

You can read more about constraints here: https://blogs.technet.microsoft.com/pki/2014/03/05/constraints-what-they-are-and-how-theyre-used/

b). The value of the Enhanced Key Usage (EKU) extension is set to Code Signing. What this does is prevent the cert being used for anything other than it's intended purpose... Which is Ensures software came from software publisher &&& Protects software from alteration after publication.
In the details of the certificate the information will look like this:

Code Signing (1.3.6..1.5.5.7.3.3) <<<< This is the Enhanced Key Usage OID for code signing the 1.3.6... number

This information was found, very randomly and not in any particular order of flowing documentation, here:

Generating Certificates for the Windows Store Apps

1B. So in final for using the New-SelfSignedCertifcate cmdlet via powershell one would run a command as such:

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

The above command meets both criteria of a code signing certificate (although you could have instead of using the -type property you could have chosen an Key Usage Extention oid with corresponding code signing type i.e. Code Signing oid= 1.3.6.1.5.5.7.3.3)

If you run the above command in powershell you will create 2 things that can now be exported...

A.) a public certificate B.) a private key + public certificate contained in a .pfx file format.

Now that we have the ability to export the .pfx this is how you would go about creating a password and exporting the private key + certificate .pfx file.

2. Using the command you would run the cmdlet in powershell Export-PfxCertificate:

Here is the Exporting pfx documentation:

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:LocalMachineMy<Certificate Thumbprint>" -FilePath <FilePath>.pfx -Password $pwd

3. At this point you have a key that works with visual studio and you can now package your application and produce a .appx file or an appxbundle file that will be able to be deployed to the local machines windows store.

Detailed instructions can be found here:

https://docs.microsoft.com/en-us/windows/uwp/packaging/packaging-uwp-apps

Scenario 2: If you are needing a trusted certificate from your organizations certificate authority

What you have to keep in mind here is that the section above is relevant but you will need to appreciate the differences between a self-signedcertificate and a trusted root certificate CA and or subsequent CA.

Well here is one way to understand it. A root certificate at it's inception was a SelfSigned certificate. However, it has the ability to issue out certificates to others for a variety things. i.e. server authorization or code signing... Think Basic Constraints UNLIMITED. And it can also issue out other Certificate Authorities that are able to issue out certificates to others for a variety of reasons.

This is referred to as the cert chain. Remember from above, the cert we want for our purposes is the end of this chain... Basic Constraints = LIMITED to 0 or false, meaning that it must be signed as an End-endtity or Certificate Authroity = false... in other words you can't issue out further certificates for any reason from this cert that was issued.

Since this is for an application that simply needs to be installed and used. This makes sense.

Again, read this link: https://blogs.technet.microsoft.com/pki/2014/03/05/constraints-what-they-are-and-how-theyre-used/

So for this next segment I am going to explain the steps to request a certificate from your Certificate Authority through a certificate request. In the linux world via openssl this is referred to as a .csr ... In the powershell world this is referred to as a .req

When you put the parameters just right... the end result is a file that can be read by openssl or cert verification website with an interchangeable extension of .req or .csr

Powershell has the ability to create this through a cmdlet called CertReq

1. You would simply use this command along with passing in an .inf file that will create your .req certificate request

certreq -new TestReqConfig.inf MyRequest.req

2. The .inf file would contain parameters for a key and certificate information much like when creating a new-selfsignedcertificate from the information above.

an .inf file would look like this:

[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"

the Requesttype = PKCS10 allows this to work with the openssl csr decoder... and everything else is explained via these sites:

The decoder works by opening the creating file and getting the information that is creating in-between

-----BEGIN NEW CERTIFICATE REQUEST-----
-----END NEW CERTIFICATE REQUEST-----

CertReq documentation

req / csr decoder

I hope this information helps someone learn about certs and how they are used in the packaging and creation of Windows store applications.

这篇关于如何通过 Visual Studio 2019、2017 和 2015 为 Windows 10 UWP 应用程序创建有效的可信和/或自签名证书的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！