Buy and integrate extern certificates for UWP app - visual-studio

Im just a little overwhelmed by all the certificates and I hope I can find some help here.
So basically I have an sideloaded UWP app (that I created with Visual Studio) where the certificate is running out in the next few days. I was able to extend the certificate by creating a new one which also can stay alive for 1 year. But I wondered if it is possible to extend it from 1 year to like 5 years or so. The "solutions" I found are either to buy a certificate or to create one myself.
Well about buying one: I´ve been looking trough the internet but could not tell what I am actually looking for. There are a few different certificates and I don´t know which I need for an UWP app. Does anyone know what I have to look at? Buying one is expensive and I would rather not buy the wrong one.
Now about creating one myself. There are a few suggestions on how to do it but after reading trough some of the suggestions it felt like the "guides" were incomplete. Some ways were deprecated. Some other have not give me enough information for me to do it myself. Does anyone have a good guide on how to create an own certificate with a longer lifecycle for sideloaded UWP apps?
(Also an not so important question for now but later it propably will be important. How would you integrate a bought/self-created certificate?)
edit
Alright so far I have created a certificate for package signing like this: I opened the Power Shell and wrote this in it:
$notAfter = [datetime]::Today.AddYears(5)
$thumb = (New-SelfSignedCertificate -Type Custom -Subject "CN=myCN" -KeyUsage DigitalSignature -FriendlyName iTest -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter $notAfter).Thumbprint
$pwd = ConvertTo-SecureString -String t -Force -AsPlainText
Export-PfxCertificate -cert "Cert:\LocalMachine\My\$thumb" -FilePath C:\MyTest.pfx -Password $pwd
Then I installed this certificate like this:
From the Windows RT PC, either map the network share or connect the
USB drive where you can access the AppPackages folder that contains
the app package to install. Use Windows Explorer to open that folder.
Double-tap the certificate file in the folder and then tap Install
Certificate. This displays the Certificate Import Wizard.
In the Store Location group, tap the radio button to change the selected option to Local Machine.
Click Next. Tap OK to confirm the UAC dialog.
In the
next screen of the Certificate Import Wizard, change the selected
option to Place all certificates in the following store.
Tap the
Browse button. In the Select Certificate Store pop-up window, scroll
down and select Trusted People, and then tap OK.
Tap the Next button;
a new screen appears. Tap the Finish button.
A confirmation dialog
should appear; if so, click OK. (If a different dialog indicates that
there is some problem with the certificate, you may need to do some
certificate troubleshooting. However, describing what to do in that
case is beyond the scope of this topic.)
Then in Visual Studio I go into the properties of my Package.appxmanifest
-> Choose Certificate -> Select from file
I pick my file and get this Error message:
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.
But this does not help me. I guess Im missing alot of steps. What else do I need to do?
edit2
I tried to use the signtool with windows powershell:
signtool sign /fd sha256 /a /f C:\MyTest.pfx /p t C:\path\to\Package.appxmanifest
This did not work. Error message (free translation from german to english):
signtool : The name "signtool" has not been identified as a name of an Cmdlet, a function, a scriptfile or as an executable file. Check the correct name or the path for it and try again.
My signtool.exe is here: C:\Program Files (x86)\Windows Kits\10\bin\x86

When you create a self-signed certificate using the New-SelfSignedCertificate PowerShell cmdlet, you could use the NotAfter parameter to specify the date and time when the certificate expires. Please see the docs for an example.
The certificate must then be installed on the device where you intend to sideload the app. Please refer to the docs and this answer for more information about how to sideload an app on Windows 10. You basically need to turn on sideloading and import the certificate.
If the app is signed with a certificate that chains to a trusted root authority on the client machine, you don't need to import the certificate. Most certificates that you buy from a certificate authority (CA) is.

Related

Issues with Code Signing Certificate

My boss recently purchased a code signing certificate from Comodo. I now have the task of making it work in VS2013 using Strong Name Key signing and perhaps as a post-build event, too. He did the whole purchasing process on the same machine (Windows 8.1 64-bit laptop) and using the same browser (Firefox 59.0.1 64-bit). I have gone to the Menu > Options > Privacy & Security > View Certificates > Your Certificates screen in Firefox, and selected the cert that was just purchased. I then clicked the "Backup" button, named it something generic, like companyCert.p12 (I don't get any other choice or settings but .p12), clicked the "Save" button, and entered a 16-character alphanumeric (caps and lowercase) password, and clicked the "OK" button. I got the popup saying that the export was successful.
When I try to import that .p12, or the extension-renamed .pfx, file into the local user's Personal or Trusted Publishers certificate store through mmc (even tried certmgr.msc just for kicks), I get:
The password you entered is incorrect.
When I try to build my assemblies in VS using the .p12 file to Strong Name Key sign them, I get:
The key file 'absolute\path\to\cert\companyCert.p12' does not contain a public/private key pair.
When I try to do the same thing but renaming the extension to .pfx, I am prompted for the password, so I input that, and I get:
An error occurred during encode or decode operation.
So I then tried to import the .p12/.pfx using the command prompt (running as administrator) and CertUtil using the following line:
certutil -importPFX -user "absolute\path\to\cert\companyCert.p12" AT_SIGNATURE
and I was prompted for the password, which I input, and got:
CertUtil: -importPFX command FAILED: 0x80092002 (-2146885630 CRYPT_E_BAD_ENCODE)
CertUtil: An error occurred during encode or decode operation.
for both .p12 and .pfx.
I've tried all of these several times just in case I did something wrong with the password or something. I've tried going back into the Firefox certificates and instead of clicking on the "Backup"
button in the Your Certificates screen, clicking on the code signing certificate, and clicking "View..." That takes me to the Certificate Viewer window, where I click on the Details tab and click the
"Export" button. There, I am given the choice of X.509 Certificates:
PEM (.crt/.pem, both with or without chain)
DER (.der without chain)
and PKCS#7 (.p7c with or without chain)
I did all but .der when trying to do the code signing, but to no avail. I was able to import some of them into the local user's Personal and Trusted Publisher stores, but I was unable to get any of
them to work in VS for Strong Name Key signing.
As I understand it, I need to be able to get the private/public key certificate in the local store on the OS level, not just Firefox's browser level, and then I should be able to export how I need to. Is that correct? If it's not, please, someone tell me what I can do to get this to work.
In my case I could successfully import the .pfx file in my Desktop running Windows 10, but when I tried to import the certificate in the server running Windows Server 2016 I received the error "The password you entered is incorrect".
To solve the problem:
Remove the certificate from my windows (using Management Console / Certificates)
Import the original .pfx certificate to my Desktop Computer
Export the certificate (using Management Console / Certificates)
The trick is:
When exporting the certificate, select the encryption "TripleDES-SHA1".
I downloaded - DigiCertUtil - and manually installed the certificate with this tool, and it worked perfectly!
https://www.digicert.com/util/
I managed to re-export the file and use the certUtil.exe with -importPFX.
Initially i used the digicert utility to install the certificate on one machine and add it to the store.
Then i exported it from the google chrome browser to a new .pfx file. (Settings > manage certificates > export)
And voila all of sudden the file was no longer corrupted and could be used with the certUtil.exe
I saw a post where the Comodo Support Team blamed Firefox for the issue, which made me wonder if chrome could export after the use of DigiCertUtil.

"Unknown publisher" while starting properly signed installer

I have properly signed .msi that user can download from a web server.
When the user runs it Windows gives her a warning about "Unknown Publisher".
However if she looks at file properties ("Digital signatures") proper signature and certificate are in place.
Cert path is VeriSign -> VeriSign Class 3 Code Signing 2010 CA -> My Company.
We expect the user to see correct "My Company" name instead of "Unknown Publisher" in that dialog box. What is the reason for unexpected behavior?
I solved this problem by using the /ac switch for signtool. This switch takes a path to a certificate file, and allows you to add an additional certificate to the signature block of the signed file. I used "/ac AddTrustExternalCARoot.crt" to add Comodo's Root Code Signing (SHA-2) certificate to my msi file. I tested this on Windows 7 where I was having the problem.
The /ac switch is intended for signing kernel code, but it is also necessary to fix this issue. You'll still need to use /f or one of the other switches to use your code signing certificate.

Does code signing help avoid the red SmartScreen banner in IE 9/10?

We've released a new application but we're getting reports that when users try and download it in Internet Explorer, they get a red error message after they choose to save or run the EXE file:
What we want to know is, how can we stop this red version of the banner appearing for IE users? Will code signing persuade IE to instead show the yellow banner which gives the users the option to run or save the file? And if so, is it possible to get a temporarily/trial certificate (not self signed) to test this with? Self signing doesn't seem to help.
Edit:
I've also noticed Google Chrome has a similar banner and effectively the same problem that the users will be scared off installing the file.
This behavior is entirely controlled by SmartScreen Filter from IE. You cannot control it when creating the setup packages, not matter the tool you use to author them. Here are more details:
http://windows.microsoft.com/en-US/windows7/SmartScreen-Filter-frequently-asked-questions-IE9
http://windows.microsoft.com/en-US/windows7/When-to-trust-a-software-publisher-IE9
What I can recommend is to use the same name of the setup file for future versions, i.e. do not change it for every version and digitally sign the package using a code signing certificate. When more users will download the package the browsers will gather statistics and start trusting your file.

Application always asks for permission to access keychain

I have an application that stores username and password in the keychain. Everything was working fine when working on Xcode 3, I recently moved to Xcode 4 and now when I run the application, I get a prompt:
Application wants to use your confidential information stored in keychain" in your keychain.
After hitting always allow I see the application added to access control list of the keychain item, but I get every time I run the app.
Also after hitting Always allow again, I see that the access control has two instances of the same app. Seems like OS thinks this is a new application.
Any ideas appreciated.
I believe the problem is that your signature's designated requirement causes it to not accept itself as "the same app" as itself (for Keychain purposes).
One common cause for this—and I think it's yours—is using a Developer ID Application cert, with no designated requirement, and without the intermediate cert installed.
A standard Developer ID requirement looks like this:
designated => anchor apple generic and
identifier \"com.example.appName\" and
((cert leaf[field.1.2.840.113635.100.6.1.9] exists) or
(certificate 1[field.1.2.840.113635.100.6.2.6] exists and
certificate leaf[field.1.2.840.113635.100.6.1.13] exists and
certificate leaf[subject.OU] = \"1AZBYCXDW9V\" ))
If you want to construct this yourself, you have to replace the identifier with your bundle identifier and the subject.OU with the value from your cert. (If you double-click it in Keychain Access, it should be listed as the Organizational Unit.) Then you can add to "Other Code Signing Flags":
--requirements "=designated ..." (the whole mess from above)
However, a much better way to do this is to use Xcode 4.3.2 or later. If it recognizes that you're using a Developer ID Application cert, and can see the intermediate cert in the keychain, it will generate this by default.
Also, if you use the Archive Organizer in Xcode to "Export Developer ID-signed Application", instead of just using the build from your target directory, it will make sure to sign your app and any other enclosed signables, and it will test that everything is setup properly. (The failures are pretty cryptic—e.g., your "Choose a Developer ID to sign with" step may just have no choices, with a message in the syslog that has no useful information—but at least the fact that it failed or succeeded narrows down where your problem is.)
Either way, you need to download and install (on your build machine) the intermediate cert, called "Developer ID Certification Authority", from the "Developer ID Intermediate Certificate" link at the Developer Certificate Utility site.
One last thing: Even if this solves your problem running on your build machine, you really want to test on the oldest OS version you support. For example, the requirements compiled by Lion's codesign sometimes can't be parsed on Leopard, or sometimes even on Snow Leopard. If that happens… see Gatekeeper vs. Leopard: an ongoing tale.

What do I need to do to get Internet Explorer 8 to accept a self signed certificate?

We use self signed certificates on our intranet. What do I need to do to get Internet Explorer 8 to accept them without showing an error message to the user? What we did for Internet Explorer 7 apparently isn't working.
EDIT: Internet Explorer 7 wouldn't show any errors if I put the certificate into trusted root certification authorities. Internet Explorer 8 seems to show errors even with the certificate there.
How to make IE8 trust a self-signed certificate in 20 irritating steps
Browse to the site whose certificate you want to trust.
When told “There is a problem with this website's security certificate.”, choose “Continue to this website (not recommended).”
Select Tools➞Internet Options.
Select Security➞Trusted sites➞Sites.
Confirm the URL matches, and click “Add” then “Close”.
Close the “Internet Options” dialog box with either “OK” or “Cancel”.
Refresh the current page.
When told “There is a problem with this website's security certificate.”, choose “Continue to this website (not recommended).”
Click on “Certificate Error” at the right of the address bar and select “View certificates”.
Click on “Install Certificate...”, then in the wizard, click “Next”.
On the next page select “Place all certificates in the following store”.
Click “Browse”, select “Trusted Root Certification Authorities”, and click “OK”.
Back in the wizard, click “Next”, then “Finish”.
If you get a “Security Warning” message box, click “Yes”.
Dismiss the message box with “OK”.
Select Tools➞Internet Options.
Select Security➞Trusted sites➞Sites.
Select the URL you just added, click “Remove”, then “Close”.
Now shut down all running instances of IE, and start up IE again.
The site’s certificate should now be trusted.
I got it working like this
Start Internet Explorer running as a user with administrative privileges.
Browse to server computer using the
computer name (ignore certificate
warnings)
Click the ”Certificate Error” text
in the top of the screen and select
”View certificates”
In the Certificate dialog, click
Install Certificate -> Next
Select Place all certificates in the
following store -> Browse
Check Show Physical Stores check box
Select Trusted Root Certificate
Authorities – Local Computer
Click OK – Next – Finish – OK
Restart Internet Explorer
I have tried lots and lots of steps from different people posted on different websites.
But none of them mention that I should add the certificate into the Trusted People keystore.
That's right, placing it under trusted CA is not enough for my case, I have to put the certs inside the Trusted People also.
That's:
Run MMC
Add Certificate Snap-in choose Local Computer
Expand Certificates(Local Computer) -> Trusted People -> Certificates
Right click All Task -> Import
Finish the wizard
To export the certificate:
Run IE as admin (right click, run as admin)
When prompted invalid cert, go ahead visit the website anyway
Click the certificate error near the address, click view certificate
Go to Details tab, click Copy To file
Save as *.cer file.
I'm on IE9, Windows 7
Make sure that your self-signed certificate matches your site URL. If it does not, you will continue to get a certificate error even after explicitly trusting the certificate in Internet Explorer 8 (I don't have Internet Explorer 7, but Firefox will trust the certificate regardless of a URL mismatch).
If this is the problem, the red "Certificate Error" box in Internet Explorer 8 will show "Mismatched Address" as the error after you add your certificate. Also, "View Certificates" has an Issued to: label which shows what URL the certificate is valid against.
If you're getting an address mismatch error, just allow address mismatches:
Tools and select Internet Options
select the Advanced tab
Scroll down and uncheck Warn about certificate address mismatch
Man, today I've spent a few hours fighting this problem. No matter what I did in the IE 8, the problem remained. The certificate installed by the IE appears in the Trusted Root Certification Authorities of the client PC, however the IE still complains no matter what.
Here's the solution I've discovered:
On the web server:
Win+R, MMC, Enter.
File, Add-Remove snap-in, Certificates, Add, Manage certificates for: my user account,
Finish, OK.
Navigate to "Certificates - current user / Trusted Root Certification Authorities / Certificates".
Find your certificate, right-click, All tasks / Export.
"No, don't export the private key"
"DER Encoded binary X.509 (.CER)"
Save the file somewhere.
Transfer the newly created .CER file to the client PC.
On the client machine:
Win+R, MMC, Enter.
File, Add-Remove snap-in, Certificates, Add, Manage certificates for: my user account,
Finish, OK.
Navigate to "Certificates - current user / Trusted Root Certification Authorities / Certificates".
Right-click on Certificates container, All tasks / Import
Choose your .CER file you've transferred from the server machine.
On the next screen, choose "Place all certificates in the following store", click "Browse", check "Show physical stores", then choose "Trusted Root Certification Authorities / Local Computer".
Press "Finish" finally.
In Internet Explorer: Tools - Delete browsing History,
In Internet Explorer: Tools - Internet options - "Content" tab - Clear SSL state button.
Here is how I got it to work in IE8:
Go to the website in question, https://xxx.yyy.com, for instance,
Click through until you get to the Certificate error in the browser status line.
View the cert, then from the Details tab, select Copy to File.
Save to the desktop as xxx.cer, for example,
Start, Run, MMC.
File, Add/Remove Snap-In,
Select Certificates, Click Add, My User Account, then Finish, then OK,
Dig down to Trust Root Certification Authorities, Certificates,
Right-Click Certificate, Select All Tasks, Import,
Select the Save Cert from the Desktop
Select Place all Certificates in the following Store, Click Browse,
Check the Box that says Show Physical Stores, Expand out Trusted Root Certification Authorities, and select Local Computer there, click OK, Complete the Import,
Check the list to make sure it shows up. You will probably need to Refresh before you see it. Exit MMC,
Open Browser, select Tools, Delete Browsing History
Select all but Inprivate Filtering Data, complete,
Go to Internet Options, Content Tab, Clear SSL State,
Close browser and reopen and test.
You should install your certificate as a trusted authority on your computer.
There are numerous way to do that, for exampe you could use mmc (start/run/mmc), add the Certificates Snap-In, and from there you can install your self-signed certificate.
There's no way around that because the whole point of certificates is to warn the user if the website he's visiting has not been certified by a trusted authority.
It's not enough to install the certificate itself, instead you need to install the root certificate of your certification authority. Say if you use Win Server's Certificate Services, its root certificate which was created when CS was installed on that server is the one to be installed. It must be installed to the "Trusted Root Certification Authorities" as described earlier.
This may help someone I am on IE11 windows 7 and what I did In addition to install the certificate is Going to internet options ==> advance tab == > security ==> "remove the check " from warn about certificate address mismatch in addition to below - dont forget to close All IE instances and restart- after finishing :
1-Start Internet Explorer running .
2-Browse to server computer using the computer name (ignore certificate warnings)
3-Click the ”Certificate Error” text in the top of the screen and select ”View certificates”
4-In the Certificate dialog, click Install Certificate -> Next
5-Select Place all certificates in the following store -> Browse
6-Install to the trusted root Certification ..
then restart .
Hope this help someone .
You can use GPO to use the certificate within the domain.
But my problem is with Internet Explorer 8, that even with the certificate in the trusted root certification store... it still won't say it's a trusted site.
With this and the driver signing that needs to be done now... I'm starting to wonder who owns my computer!
Unfortunately none of the solutions worked for me. I used Internet Explorer 8 on Windows 7. When I was looking for a solution, I found the settings about login information in the control panel. So I added a new entry under the certificate based information with the address of my server and I chose my prefered certificate.
After a clear of the SSL cache in Internet Explorer 8 I just refreshed the site and the right certificate was sent to the server.
This isn't the solution which I wanted, but it works.
As everyone else has mentioned, the first task is to add the certificate to the Trusted Root Authority.
There is a custom exe (selfssl.exe) which will create a certificate and allow you to specify the Issued to: value (the URL).
This means Internet explorer will validate the issued to url with the custom intranet url.
Make sure you restart Internet Explorer to refresh changes.
It doesn't look like it's possible to not have the certificate error any more. I'm on Windows XP with IE 8. Group Policy had installed a self-signed certificate as a trusted root certificate for access to an internal site. When I look at MMC with the certificate snap-in I can see the certificate there OK.
When I look at:
Internet Options => Content => certificates
It isn't there!
This behaviour in IE started since our admins let loose with the last lot of Patch-Tuesday updates which installed on my machine on 10th Dec 2009. Prior to that it was quite happy to accept the certificate as valid.
I had the same issue while working with web services. Here Microsoft has a (long) walk-thru showing you how to install stuff on the client to basically say that your self-signed cert is ok. In the end, I just spent the $30 and bought a full certificate from Godaddy.com.
P.S. I know that you can code around the error message but we didn't want to do that for testing reasons.
What were you doing before? For self-signed certificates, I would normally install the certificate locally on the client system.
You may be able to use Group Policy to push a certificate to every system.
You need to make sure that the Self Signed Certificate uses the correct common name for the domain you are setting up. If you are going to use the same certificate for multiple domains you need to either have a unique certificate for each domain, or if all of your ssl sites are subdomains of a common domain, then you can generate a certificate with a wildcard domain like *.domainname.tld.
If you don't set up your common name correctly in your self signed certificate then Chrome and Firefox may work, but IE might not be able to find the certificate when you load the site each time. In IE it will appear like you have added the site's cert but in fact on page load it will never be found.
how to set up SSL for Apache for a Mac so I can test Cross Domain iFrame on IE8
How to install the CA Root Cert, and not the Website Cert: (IE8, Win7)
When you bring up the certificate details you are looking at the website cert, and not the CA cert. The General tab will say, "This certificate cannot be verified..." You need to select the CA by clicking on the Certification Path tab, and selecting the top most cert in the path. It should have a red X icon, and should say, "This CA Root certificate is not trusted because..." Click the View Certificate button, and on this new General tab you should see, "This CA Root is not trusted..." This is the certificate that you want to import into the Trusted Root Certificate Authority.
Once you have imported the CA, you do not need to import the regular website cert. That cert will get matched up to the CA you just imported, and IE will treat everything as working normally. You do not need to run IE as Admin, and you do not need to add the site to trusted sites first. You do need to restart IE after the import.
I tried all mentioned solutions but none of them worked. Using Internet Explorer 11 (11.0.9600.17914), there was no way of accepting invalid certificates as the error looked exactly as an 404.
What helped was the following:
- add host to trusted sites (as mentioned a couple of times here)
- disable TLS 1.2 and enable SSL 1.0 & SSL 2.0
The last step is something you should ONLY DO if you know what you're doing. We need to use a pretty strange setup here at work, thus we couldn't find another way of getting access to the system. Usually, downgrading security like that should not be done.
If you are doing some local testing and that you add some alias in the hosts files say
127.0.0.1 www.mysite.com
and try to use any of the above procedures you will fail. The reason is that you will import a certificate for localhost. The certificate URL won't match.
In that situation you will have to generate a self-signed certificate and THEN import it as described above.
If you are using Xampp the generation of the correct certificate can be done easily using
c:\xampp\apache\makecert.bat
You can use CertMgr to add a certificate as a trusted publisher or if it is self-signed, as a root certificate
CertMgr.exe /add CertificateFileName.cer /s /r localMachine root
See Microsoft's documentation here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/using-certmgr-to-install-test-certificates-on-a-test-computer

Resources