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.
.png)
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
| Field | Description |
|---|---|
Version |
Specifies the version number of the encoded certificate. Currently, the possible values of this field are 0, 1, or 2. |
Serial Number |
Contains a positive, unique integer assigned by the certification authority (CA) to the certificate. |
Signature Algorithm |
Contains an object identifier (OID) that specifies the algorithm used by the CA to sign the certificate. For example, 1.2.840.113549.1.1.5 specifies a SHA-1 hashing algorithm combined with the RSA encryption algorithm from RSA Laboratories. |
Issuer |
Contains the X.500 distinguished name (DN) of the CA that created and signed the certificate. |
Validity |
Specifies the time interval during which the certificate is valid. Dates through the end of 2049 use the Coordinated Universal Time (Greenwich Mean Time) format (yymmddhhmmssz). Dates beginning with January 1st, 2050 use the generalized time format (yyyymmddhhmmssz). |
Subject |
Contains an X.500 distinguished name of the entity associated with the public key contained in the certificate. |
Public Key |
Contains the public key and associated algorithm information. |
Version 2 fields
An X.509 version 2 certificate contains the basic fields defined in version 1 and adds the following fields.
| Field | Description |
|---|---|
Issuer Unique Identifier |
Contains a unique value that can be used to make the X.500 name of the CA unambiguous when reused by different entities over time. |
Subject Unique Identifier |
Contains a unique value that can be used to make the X.500 name of the certificate subject unambiguous when reused by different entities over time. |
Version 3 extensions
An X.509 version 3 certificate contains the fields defined in version 1 and version 2 and adds certificate extensions.
| Field | Description |
|---|---|
Authority Key Identifier |
Identifies the certification authority (CA) public key that corresponds to the CA private key used to sign the certificate. |
Basic Constraints |
Specifies whether the entity can be used as a CA and, if so, the number of subordinate CAs that can exist beneath it in the certificate chain. |
Certificate Policies |
Specifies the policies under which the certificate has been issued and the purposes for which it can be used. |
CRL Distribution Points |
Contains the URI of the base certificate revocation list (CRL). |
Enhanced Key Usage |
Specifies the manner in which the public key contained in the certificate can be used. |
Issuer Alternative Name |
Specifies one or more alternative name forms for the issuer of the certificate request. |
Key Usage |
Specifies restrictions on the operations that can be performed by the public key contained in the certificate. |
Name Constraints |
Specifies the namespace within which all subject names in a certificate hierarchy must be located. The extension is used only in a CA certificate. |
Policy Constraints |
Constrains path validation by prohibiting policy mapping or by requiring that each certificate in the hierarchy contain an acceptable policy identifier. The extension is used only in a CA certificate. |
Policy Mappings |
Specifies the policies in a subordinate CA that correspond to policies in the issuing CA. |
Private Key Usage Period |
Specifies a different validity period for the private key than for the certificate with which the private key is associated. |
Subject Alternative Name |
Specifies one or more alternative name forms for the subject of the certificate request. Example alternative forms include email addresses, DNS names, IP addresses, and URIs. |
Subject Directory Attributes |
Conveys identification attributes such as the nationality of the certificate subject. The extension value is a sequence of OID-value pairs. |
Subject Key Identifier |
Differentiates between multiple public keys held by the certificate subject. The extension value is typically a SHA-1 hash of the key. |
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>