Common security scenarios (Windows Runtime apps)
[ This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation ]
There are a number of common scenarios targeted by the security namespaces.
Creating a private key on the client and enrolling
You can make an app that creates a certificate request, submits the request to a specific certification authority (CA), and installs the certificate response to the app container certificate store. The CreateRequestAsync method generates a private key and stores it in the app specific store.
Note There is no enrollment method in the CertificateEnrollmentManager class. To submit the request and obtain the issued certificate, you must use one of the following:
- XMLHttpRequest (JavaScript)
- HttpWebRequest (C#)
- IXMLHttpRequest (C++)
Your app can enroll for certificates on a smart card in a similar manner.
Creating a private key on the server
A website may require the use of client certificates for strong user authentication. The website can generate a private key and certificate on the server and then send them to the client for installation. Your app can require the user to authenticate by using a one time password upon first use. Then your app can obtain the certificate and key from the server and install them into the app container. The user can subsequently authenticate to the site by using the certificate without a password. If the user moves to a different computer or loses the certificate and key, your app can provide the client a copy from the server.
SSL server authentication using system trusted roots
An app can establish an HTTPS connection to a secure web service and verify that the server certificate chains up through a system trusted root. By default, an app can read system trust stores, except for the user MY and REQUEST stores. For more information, see Shared certificate stores.
SSL server authentication using application-specific trusted roots
You can write an app that uses its own trust anchor rather than inheriting from system trust. When your app is installed, you can use the manifest to specify that the root certificate also be installed in a private store, and the app can use the root certificate to establish a secure HTTPS connection to the web server. The root need not be trusted through the Microsoft root program. The root is trusted only for your app and does not affect trust for other applications on the system. For more information about specifying exclusive trust in your application manifest, see the Extensions topic.
SSl client authentication using smart cards
Some financial institutions require that their customers use smart cards to authenticate to a secure server before performing financial transactions online. The institution creates an app that requires the certificate selected for user authentication be hardware-based. For more information about using the manifest to specify certificate selection criteria, see the Extensions topic.
SSL client authentication using application specific software-based certificates and keys
Some financial institutions issue account holders software-based certificates rather than smart card-based certificates. Apps from such institutions enrolls for the certificate from the institution's web server and installs the certificate and private key to a per-app specific store. The certificate authenticates a user to the financial institution web server. For more information about using the manifest to specify certificate stores, see the Extensions topic.