Certificates (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 ]

Digital certificates are used in public key cryptography to bind a public key to a person, computer, or organization. The bound identities are most often used to authenticate one entity to another. For example, certificates are often used to authenticate a web server to a user and a user to a web server. You can create certificate requests and install or import issued certificates. You can also enroll a certificate in a certificate hierarchy.

X.509 certificates

Public key cryptography relies on a public and private key pair to encrypt and decrypt content. The keys are mathematically related, and content encrypted by using one of the keys can only be decrypted by using the other. The private key is kept secret. The public key is typically embedded in a binary certificate, and the certificate is published to a database that can be reached by all authorized users.

The X.509 public key infrastructure (PKI) standard identifies the requirements for robust public key certificates. A certificate is a signed data structure that binds a public key to a person, computer, or organization. Certificates are typically issued by certification authorities (CAs). All who are party to secure communications that make use of a public key rely on the CA to adequately verify the identities of the individuals, systems, or entities to which it issues certificates. The level of verification typically depends on the level of security required for the transaction. If the CA can suitably verify the identity of the requester, it signs (encrypts) and issues the certificate.

Certificates are typically issued by CAs but they do not need to be. If, for example, you have created a web service and an app client and you want them to be able to communicate over HTTPS, the server must be able to authenticate to the client. Your app does not need to go to a CA to obtain a server certificate. Instead, you can use the manifest to specify that you want the certificate installed with the client.

You can use the Windows.Security.Cryptography.Certificates namespace to create certificate requests and install or import an issued certificate.

Certificate fields

The X.509 public key certificate standard has been revised over time. Each successive version of the data structure has retained the fields that existed in the previous versions and added more, as shown in the following illustration.

Some of these fields and extensions can be specified directly when you use the CertificateRequestProperties class to create a certificate request. Most cannot. These fields can be filled by the issuing authority or they can be left blank. For more information about the fields, see the following sections:

Version 1 fields

Version 2 fields

An X.509 version 2 certificate contains the basic fields defined in version 1 and adds the following fields.

Version 3 extensions

An X.509 version 3 certificate contains the fields defined in version 1 and version 2 and adds certificate extensions.

Shared certificate stores

Windows Server 2012 and Windows 8 include a new isolation model, a new application model, and a new development model.

• The new isolation model enables an application to run in a low-level operating system construct, called an app container, that prohibits the application from accessing resources or files outside of itself unless explicitly permitted to do so.
• The new application model defines a Windows Store app. Windows Store apps run inside of an app container, have declared capabilities, and are easy to install, run, and remove without affecting the overall system.
• The new development model includes an Windows Software Development Kit (SDK) for Windows 8 that has been designed to provide simplified access to Windows Server 2012 and Windows 8 functionality. If you are creating a Windows Store app, you can use only the types made available through the Windows SDK for Windows 8.

These new models, particularly the isolation model, have public key infrastructure (PKI) implications that are discussed in the following sections.

Certificate storage per app container

Certificates that are intended for use in a specific app container are stored in per user, per app container locations. An app running in an app container has write access to only its own certificate storage. If the application adds certificates to any of its stores, these certificates cannot be read by other apps. If an app is uninstalled, any certificates specific to it are also removed. An app also has read access to local machine certificate stores other than the MY and REQUEST store.

Cache

Each app container has an isolated cache in which it can store issuer certificates needed for validation, certificate revocation lists (CRL), and online certificate status protocol (OCSP) responses.

Shared certificates and keys

When a smart card is inserted into a reader, the certificates and keys contained on the card are propagated to the user MY store where they can be shared by any full-trust application the user is running. By default, however, app containers do not have access to the per user MY store.

To address this issue and enable groups of principals to access groups of resources, the app container isolation model supports the capabilities concept. A capability allows an app container process to access a specific resource. The sharedUserCertificates capability grants an app container read access to the certificates and keys contained in the user MY store and the Smart Card Trusted Roots store. The capability does not grant read access to the user REQUEST store.

You specify the sharedUserCertificates capability in the manifest as shown in the following example.

<Capabilities>
    <Capability Name="sharedUserCertificates" />
</Capabilities>

Related topics

Cryptography and PKI