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.
- Are you needing a self-signed certificate or
- 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
- 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.
- 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:\LocalMachine\My\<Certificate Thumbprint>" -FilePath <FilePath>.pfx -Password $pwd
- 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
- 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
- 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.
