如何通过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

查看:214
本文介绍了如何通过Visual Studio 2019、2017和2015为Windows 10 UWP应用程序创建有效的受信任和/或自签名证书的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

根据此文档:

https://docs.microsoft.com/zh-cn/windows-hardware/drivers/devtest/makecert

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

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

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

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

其他命令行选项例如/ sv SubjectKeyFile,它将生成生成的pvk文件。

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

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

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


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

The manifest designer could not import the certificate.

所选证书无效,因为该证书已过期或存在其他问题。有关更多信息,请参见
http://go.microsoft.com/fwlink/? LinkID = 241478

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.

是否有更好的方法通过makecert创建脚本?我怎么知道证书最终是否正确构建?其他文档会有所帮助,但我没有发现其他任何内容。

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.

推荐答案

@nico提供的答案具有正确的陈述,但使我意识到这个问题比我最初描述的更多。因此,我清理了问题标题和问题,以提供一个更好的问题和后续答案。

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.

在网上清理时,我在很多不同的地方找到了很多答案,例如问题,评论中的答案,youtube等...我决定将其放在一个整洁的地方,以便每个人都可以获取资源和学习。

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.

首先,必须问自己使用应用程序的目的是什么?该应用程序是要上传到Microsoft Store还是仅在内部使用。

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. 您是否需要自签名证书?

  2. 您是否需要从CA证书颁发机构,即您的企业或组织?

我将介绍两种情况。在这两种情况下,都不推荐使用makecert协议 makecert弃用说明

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

方案1:如果您需要自签名证书,该怎么做


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

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

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

创建证书包签名

New-SelfSignedCertificate

1A。 ***创建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.

具体来说,该证书必须具有2个属性

Specifically, the certificate has to possess 2 properties

a)。必须将基本约束扩展设置为主题类型=最终实体。简单来说,这就是...向您颁发此证书时,您将不能再拥有后续证书颁发机构(可以颁发更多证书)的资格。换句话说...这是线路证书的结尾。

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.

您可以在此处了解有关约束的更多信息:
https://blogs.technet.microsoft.com/pki/2014/03/05/constraints-what-they -以及如何使用/

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)。增强密钥用法(EKU)扩展名的值设置为代码签名。这样做是为了防止将证书用于其预定目的以外的其他用途...这可以确保该软件来自软件发行商&&&

在证书的详细信息中,信息如下所示:

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:

代码签名(1.3.6 .. 1.5.5.7.3.3)<<<这是用于代码签名1.3.6 ...的增强型密钥用法OID。数字

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:

为Windows应用商店应用生成证书

1B。因此,最终通过powershell使用New-SelfSignedCertifcate cmdlet时,将运行以下命令:

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

以上命令同时满足代码签名证书的两个条件(尽管您可以使用使用-type属性,您可以选择具有相应代码签名类型的Key Usage Extension oid,即Code Signing oid = 1.3.6.1.5.5.7.3.3)

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)

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

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

A。)公开证书
B.)私有.pfx文件格式包含的密钥+公共证书。

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

现在我们可以导出.pfx了,这就是您创建密码并导出私钥+证书.pfx文件的方法。

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.


  1. 使用命令将在Powershell Export-PfxCertificate中运行cmdlet:

以下是导出pfx文档:

Here is the Exporting pfx documentation:

https://docs.microsoft.com/zh-cn/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




  1. 这时,您拥有了一个与Visual Studio一起使用的密钥,现在您可以打包应用程序并生成一个.appx文件或一个appxbundle文件,这些文件将可以部署到Windows本地存储中。

详细说明可在此处找到:

Detailed instructions can be found here:

https://docs.microsoft.com/zh-CN/windows/uwp/ Packaging / packaging-uwp-apps

方案2:如果您需要组织证书颁发机构提供的受信任证书

在此必须牢记的是,以上部分是相关的,但您需要了解自签名证书和受信任的根证书CA与后续证书之间的区别。 CA。

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.

这称为证书链。从上面记住,我们想要的证书是该链的末端...基本约束= LIMITED等于0或false,这意味着必须将其签名为End-endtity或Certificate Authroity = false ...否则字样,无论出于何种原因,您都不能从已颁发的此证书中发出进一步的证书。

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.

再次阅读此链接:
> https://blogs.technet.microsoft.com/pki/2014/03/05/constraints-what-they-are -以及如何使用/

因此,在下一部分中,我将解释通过以下方式从证书颁发机构请求证书的步骤证书申请。在Linux世界中,通过openssl将其称为.csr ...在powershell世界中,将其称为.req

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

正确...最终结果是可以由openssl或证书验证网站读取的文件,该文件具有.req或.csr的可互换扩展名

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具有通过名为CertReq的cmdlet创建此功能的能力


  1. 您只需使用此命令并传递.inf文件会创建您的.req证书请求

certreq -new TestReqConfig.inf MyRequest.req

certreq -new TestReqConfig.inf MyRequest.req


  1. .inf文件将包含密钥和证书信息的参数,就像从上述信息创建新的自签名证书时一样。

.inf文件应如下所示:

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"

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

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文档

req / csr解码器

我希望这些信息可以帮助某人了解证书以及如何在Windows应用商店包装和创建中使用证书。

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屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆