Exception: System.Security.Cryptography.CryptographicException: An internal error occurred. Error: Error loading certificate. Is password specified using ApplicationCertificatePassword?

You can enable Request-Response Tracing to see what is going on exactly when you run your application in IIS.

There are two ways that a HealthVault application can access its certificate in Windows 7 and Windows Server 2008. One is using the Application ID and getting a certificate with matching subject from the certificate store, and the other is directly retrieving the certificate from a file.  The approach of using the Windows certificate store allows the HealthVault application to take advantage of manageability and security features that are built-in the Windows certificate store. The approach of using an application certificate file can be useful for applications that do not wish to deal with the deployment of certificates to the certificate store and wish to deal with the certificate as a plain file.

 Using the Windows certificate store:

The below steps will resolve this issue by exporting the certificate that was generated by the HealthVault Application Manager tool, importing it back to computer store and grant required access to that application ID:

1.    Open HeathVault Application Manager

a.     Go to start menu ->All Programs->Microsoft HealthVault->SDK->HealthVault Application Manager or HealthVault SDK installation location.

b.    Right click on HealthVault ApplicationManager.exe and select Run as administrator.

2.    Export the Public and Private keys (.pfx) for the certificate you have created.

a.     Right click on the certificate which you have created and select Export the Public and Private keys (.pfx).

b.    Save the certificate (.pfx) file in your local computer.

3.    Copy the certificate which is saved in the prior step and paste into the machine where the application is hosted.

4.    Delete the certificate from HeathVault Application Manager. Make sure that you have copied the certificate prior to this step.

a.     Right click on the Certificate which you have created in HeathVault Application Manager and click on Delete Certificate.

5.    Close the HealthVault Application Manager.

6.    Run ComputerCertificates.msc to open the certificate application. ComputerCertificates.msc will come with HealthVault SDK installation.

a.     Open the “tools” folder under the standard HealthVault SDK installation location (e.g. C:\Program Files\Microsoft HealthVault\SDK\tools) and right click on ComputerCertificates.msc, then click on Run as administrator.

7.    Import the certificate into Personal folder in the local computer certificate store.

a.     Right click on the Certificates folder under Personal and select All Tasks then Click on Import.

b.    Click on Next

c.     Click on the Browse button to load the certificate which was saved in step 3, and click on Next.

d.    Make sure that you check the “Mark this key as exportable” check box and click on Next.

e.    Click on Next.

f.      Click on Finish to complete the certificate import process.

8.    Open HeathVault Application Manager using the instructions from Step 1 and you should be able to see the certificate which you have imported in the previous step in HealthVault Application Manager.

a.    Right click on the previously imported Certificate in HeathVault Application Manager.

b.    Click Grant Access to IIS process.

9.    Optionally, grant access to other users.

In some cases, your HealthVault web application might not be running under the Network Service account.  For example, applications hosted in IIS 7 on Windows Server 2008 SP2 and later are by default configured to run under their own unique accounts.  IIS 7 creates a new account for each web application.  This is referred to as ApplicationPoolIdentity.

You can either reconfigure your web application in IIS 7 to run under the Network Service account, or grant the account which your web application is run under read access to your application certificate’s private key.

To grant any user access to your application certificate private key in the Certificates MMC snap-in (ComputerCertificates.msc):

a.     Right click your application certificate.

b.    Select All tasks -> Manage private keys

c.     Add the desired account and check the “Read” box under the “Allow” column

 Using application certificate file:

If you would like to use an application’s certificate (.pfx) file from the file store instead of from the certificate store, you can use the procedure below.

The ApplicationCertificateFileName and ApplicationCertificatePassword are the settings in the HealthVault application’s configuration (e.g. in web.config file under the appSettings section) that are used to configure a HealthVault application to load the application certificate from a file.  The ApplicationCertificateFileName setting can be used for specifying the certificate (.pfx) file path and the ApplicationCertificatePassword setting can be used for specifying the certificate (.pfx) file password. Make sure that the HealthVault application has read access to the certificate (.pfx) file location.

1.    Export the certificate (.pfx) file using ComputerCertificates.msc

a.     ComputerCertificates.msc will come with HealthVault SDK installation.

b.    Open the “tools” folder under the standard HealthVault SDK installation location (e.g. C:\Program Files\Microsoft HealthVault\SDK\tools) and right click on ComputerCertificates.msc, then click on Run as administrator.

c.     Right click on the certificate which you want to export from the Certificates folder under Personal and click on All Tasks and then click on Export. 

d.     Click on Next in the Certificate Export Wizard.

e.     Click on Yes, to export the private key and click on Next.

f.      Verify the default selection of Personal Information Exchange-PKCS and click on Next.

g.    Enter the password that you would like to use for your certificate in both Password text box and confirm password text box. Click on Next

h.    Click on the Browse button to browse to the folder where you would like to store the certificate (.pfx) file in the file system and give the name of the certificate (.pfx). Click Save and click on Next. Note: Makes sure that you have full permissions to this path to read the Certificate file from your HealthVault application.

i.      Click on Finish and click on Ok. This completes the certificate export process.                     

Note: The generated pfx file should be kept in private location where it is not visible on your web site.  Don't put it inside your web application path but in a secure file   path not exposed to the public.

2.    Configure your HealthVault application to load the certificate from file using the ApplicationCertificateFileName and ApplicationCertificatePassword settings.  You can do this in your web application by modifying the web.config file to include the following under the <appSettings> section:

<add key="ApplicationCertificateFileName" value="“<full path to certificate file>”.pfx" /> 

<add key="ApplicationCertificatePassword" value="Certificate Password" /> 

Your web application must have read access to the certificate file.  This can usually be done by granting the Network Service account read access to the file.

In some cases, your HealthVault web application might not be running under the Network Service account.  For example, applications hosted in IIS 7 on Windows Server 2008 SP2 and later are by default configured to run under their own unique accounts.  IIS 7 creates a new account for each web application.  This is referred to as ApplicationPoolIdentity.

You can either reconfigure your web application in IIS 7 to run under the Network Service account, or grant the account which your web application is run under read access to your application certificate.

Scenario

Consider a situation where a user has uploaded all their data, either through a device or through another application (including the HealthVault Shell), into his or her HealthVault record. The user now wants to consult a physician based on information that they’ve uploaded, and wants to provide all the necessary and relevant data at their consultation.

How can we achieve this using HealthVault?

1. Accessing data by building a HealthVault application

The last section will show you clearly that the Shell was not designed for sharing a patient’s HealthVault record with doctors. How is an application a better method to exchange information? Let’s consider both the online and offline application architectures. The online applications require the user to be present when the physician’s system accesses their HealthVault record. An online application also requires the user to sign in to HealthVault each time the physician system needs fresh access to the data. These two reasons make the online scenario unacceptable for a patient who wants to give their doctor ongoing access. If we consider the offline architecture, both of these requirements are removed. The user can grant the data permissions to the application just once, and then the application can directly handle the data without any user interaction. This makes it easy for the physician to retrieve the data whenever they want once the access is authorized with the application.  Thus, the offline architecture is the best option for an application to allow the patient to provide their data in this scenario.

A sample workflow for this scenario looks like this: The hospital has a HealthVault-integrated offline application in which registered patients can log in and allow exchange of health information with HealthVault. The application will also have a login window where physicians can log in to access patient data. After registering at the hospital, the patient will go to the application and log in using the credentials they acquired during registration. The patient then links their HealthVault record to the hospital application through an authorization process. When a physician wants to see data for a particular patient, they log into the application and then choose the particular patient using a unique patient ID. The application will pull the data from the corresponding HealthVault record and render it to the physician. The application can manage which data types are shown to the logged-in physician, the level of access, and how to show the data; for example by plotting it as a graph or just showing the raw data.

Advantages and Disadvantages

The physician’s login and access rights can be created when they join the hospital. The application can be designed to present any forms desired for patient notice or consent. And the physician can easily choose whose data to view in the application. As the application renders the data in the expected way, the physician can better focus on data analysis rather than data formatting.

Now, let’s look at this scenario from the patient’s perspective. A user authorizes access by the application broadly. This is acceptable for most scenarios, but what if the user wants more control over their data? What if they want to share this information with only a specific physician, or they want to share only a specific set of relevant data? These scenarios cannot be addressed in this solution.

As the application is using the offline architecture, both the Person ID and Record ID of the user need to be stored in a secured local database. This adds an additional overhead. In addition, the application must implement a method to let the physician log in to the system and link their own login information to the patient’s information.

2. Accessing filtered data through a HealthVault application

This application flow mimics the one above for most of this scenario. The difference arises when the user logs in to the application. The user will be shown a list of physicians from which they can select the names of those they’d like to share their data with. Users will have been given the physician’s name during the registration process itself, or by contacting the hospital prior to their appointment. Similar scenarios occur for the physician login. Instead of being shown all available patients, the physician’s access can be limited to only those patients who have given them permission to see their data. A sophisticated system can let the user choose a date range and a set of data types to be accessed. Please note that this flow is different only in the way an application uses the data and it is not related to the HealthVault platform in any way. The Privacy and Term of Use statements of the application should specify these conditions appropriately.

Advantages and Disadvantages

Allowing users to choose how their data will be exposed by the application may be the best option in many cases. This puts users at ease when working with the application, as they know that the application only provides access to those they have selected.

Like the second scenario, this method requires the storage of the user’s login information in a database and the implementation of a login mechanism for physicians. Additionally, this method adds extra complexity to the application logic by which the physician’s information is linked to the patient’s information. When the user logs in and chooses doctors they want to access their data, a mapping of the user’s data with the physician’s information should be created by the application. One way to do this is to use another column to store the mapping information in the DB table in which the user’s information is stored. When a doctor chooses a user, the application should first validate this request with the already-created user mapping information. If the request is valid, i.e., the user has given the physician permission to view the patient data, then a dynamic linking of the physician’s information with the user’s data will occur. This adds an additional complexity to the application design.

Now let us compare the above two approaches.

Can we use the Shell Sharing feature?

As shown above, the Shell provides a method for a user to share their record with another person. However, HealthVault accounts are not offered for professional or non-personal use. This is a very good way to let relatives or friends help manage health information, for example a family member who needs to control the health information of a child or aging parent. When sharing the data, the user can specify the access level, which includes read access, the ability to view and modify, and full access as a custodian.  Additionally, a user can control which data types will be shared, and whether there is an expiration date on the shared access. The sharing feature does not prevent the user from sending a sharing invitation to anyone they choose, including their doctor. Once the doctor receives the sharing invitation, they would have the ability to accept it, open a personal account, and see the user’s shared data in their own HealthVault account. Though this satisfies the basic data sharing function, it violates HealthVault’s service terms, and this shouldn’t be used as a solution for this scenario. Let us discuss the reasons in the next section.

Problems

Sharing data directly through the HealthVault Shell addresses certain security and privacy concerns for account-holders, as the Shell includes access control features described above.

A deeper look, however, reveals a number of concerns with this method. First, this scenario requires the physician to have a HealthVault account and Live ID of their own and use this account as part of healthcare service. This use case does not fall within HealthVault’s terms of service and is not acceptable for any HealthVault integration. In addition, most healthcare organizations would have other requirements for their information management systems. For example, as a personal service for consumers, Microsoft doesn’t act as a business associate under HIPAA in connection with HealthVault records, and doesn’t include the kind of data management features that a healthcare practice would want to help control its operation.

           Figure 1: Information Tab in HealthVault Application Configuration Center 

If an ActionURL is not specified for SODA and PatientConnect applications, then both Privacy and Terms of Use statements in the Application Configuration Center must be specified. Suppose you have implemented both ActionURL targets for Privacy/Terms of Use and statements in the Application Configuration Center than the hardcoded statements from the Application Configuration Center will override the derived ActionURL targets.

Table 1: Summary of TOU and Privacy statements use for different types of applications

Note: If the organization is covered under the HIPAA or Clinical Trial, then it is not required for the application to derive the privacy page. 

Privacy and Terms of Use statements in the Application Configuration Center are useful for web applications when the ActionURL is behind a firewall. This allows for HealthVault to serve up the Privacy and Terms of Use statements to users directly without requiring an ActionURL to redirect the user to the Privacy or Terms of Use statements. Also note that the Application Configuration Center now accepts only plain text for the Privacy or the Terms of Use statements, which still allows you to use the ActionURL if you are using HTML in either of your statements. 

The basic steps to achieve this functionality:

By default, the DropOffUrl in ApplicationManager.exe.config file is set to https://config.healthvault-ppe.com .  We need to modify the DropOffUrl of ApplicationManager.exe.config file so that the partners from UK can also create Application ID from HeathVault Application Manager.  ApplicationManager config file is available in HealthVault standard installation location C:\Program Files\Microsoft HealthVault\SDK\Tools\ApplicationManager.exe.config.

1.  Open the ApplicationManager.exe.config. The existing appSettings tag is shown below:

 <appSettings> 

       <add key="DropOffUrl" value="https://config.healthvault-ppe.com/RegisterNewApplicationDropoff.aspx" /> 

   <add key="TurnOnUpload" value="true" />

</appSettings>

2.       Change the DropOffUrl value as shown below and save the ApplicationManager.exe.config file.

<appSettings> 

       <add key="DropOffUrl" value="https://config.healthvault-ppe.co.uk/RegisterNewApplicationDropoff.aspx" /> 

   <add key="TurnOnUpload" value="true" />

</appSettings>

3.       Run the HealthVault Application Manager as Administrator.

4.       Click on Create New Application and give the Application Name.

5.       Uncheck “Automatically Create Visual Studio Website for this Application” and then click on “Create and Register Application”.

6.       Copy the Application ID from HealthVault Application Manager by right clicking on the Application and clicking on Copy to Clipboard. Then paste the Application ID in your web.config file and run the application.

All systems are back up and running.

Considering the wide acceptance, ease of use and large user base, mobile application development is getting more and more popular. As the device always stays close to the user, HealthVault integrated applications on mobile platforms make sense in a variety of scenarios. In this discussion we will consider the different possible architectures that a mobile application can utilize for HealthVault integration.

Below are the main areas that we will have to focus when dealing with a mobile phone application in HealthVault space.

1. Authentication

2. HealthVault API interaction

3. Discovering the application

Let the Mobile App talk to Web Service

Architecture

We have some of our partners like SCP, Withings etc. following this architecture.

The application will have its own server which exposes a set of web service APIs to let the mobile application communicate with HealthVault. Thus the mobile application will not have any direct communication with the HealthVault platform, since the server does that on behalf of the application. The server communicates with HealthVault by creating an application connection object. For this architecture you will have to use the Offline connection for all HealthVault interactions.

This is the recommended architecture for mobile phone applications in HealthVault. We are consistently exploring ways to improve the mobile phone application development easier, so please feel free to give us your feedback. Let us look into a typical scenario which implements this architecture.

1. Authentication

In this scenario the application certificate will be installed in the server which is hosting the Web Service. So no distribution of certificate is needed. But how will the user authorization and authentication happens here? Yes this is one big concern. There are many ways the user authentication can happen. Among them the easiest way is to have a web page hosted for the application through which users can do the authorization. Let us call it registration process.

The user goes to the above page and login (with his HealthVault account for Online + Offline applications or through the PatientConnect way). Here the application should have enough Offline permissions set because after the registration all the HealthVault data upload and retrieval will happen through Offline Connection. Once the authorization is done the site will store the Person ID and the Record ID in a data store accessible to the Web Service. Then the site will give the user a confirmation ID which will be used to find out the corresponding Person ID and Record ID from the data store in future.

While the user is using the application for the first time user will be prompted to enter the confirmation ID, along with the right help if the user doesn’t have a confirmation ID yet. This confirmation ID will be stored in the mobile device’s persistent storage to avoid the user entering it again.

2. HealthVault API interaction

All the HealthVault API interactions happen here from the Web Service and none from the mobile application. For any data that the mobile application needs to deal with will be passed to or read from the Web Service using the APIs exposed by the Web Service. Here the Web Service will have to expose some wrapper classes for the HealthVault data types and some interfaces for the mobile application.

With each request send from the mobile application the encrypted confirmation ID will have to be passed to the Web Service. Web Service will use this confirmation ID to look up the Person ID and the Record ID and create an OfflineWebApplicationConnection using it.

3. Discovering the application

Yes, the application is built to be discovered! Once the Go-Live process is completed for the application we will help you to get the application listed in our Application Directory. Another good place to showcase the application will be to have them listed in the corresponding mobile application stores. We will be happy to help you in case if you have any concerns on this.

4. Analysis

Scenario	Advantage	Disadvantage
Authentication	As all the HealthVault authorization and authentication process is done outside the mobile application and the whole HealthVault interaction code is inside the web services the mobile application will be lighter than any other architecture. Mobile application developer can concentrate more on the business logic.	As the authentication cannot be done directly in the mobile application this requires an additional step and user facing site (mostly a registration site) where users will be registering to use the application. As the architecture requires an Offline access scenario the Record ID and the Person ID will be retrieved in this step and then stored on the server for later use. The retrieved Record ID and Person IDs will have to be stored and maintained in a secure location.
Deployment	Deployment of the application becomes easy as the application does not have to be concerned about the platform changes to HealthVault.	The communication between the server and the mobile application requires a secure way for data transfer as the data being transferred is sensitive, adding to the maintenance and the longer execution time.
Certificate Handling	In this architecture there is no need for distributing or maintaining the certificate with the application since it will be always kept inside the server.	This architecture adds additional overhead for maintaining the web services in the server.
SDK support	The HealthVault interaction code, as it is developed outside the mobile platform, can utilize the existing HealthVault SDKs (.Net SDK, Java SDK, PHP SDK or Ruby SDK). Additionally the mobile application can use any program language that is allowed on the mobile device.	As the application does not directly communicate with the HealthVault platform each of the HealthVault interactions takes more time than is necessary.

 

Let’s try the Rich Client (SODA) architecture

Architecture

Software on Device Authentication (SODA) architecture is the relatively new architecture for HealthVault which helps you to develop rich client applications on any platform or any application architecture (Console application, Form application, etc.).

This architecture was developed to support rich client application running on Windows platforms to talk directly to HealthVault. A good example of the same is HealthVault Connection Center. Interesting parts of this approach could be used in mobile context.

In this architecture the application will also directly communicate with the HealthVault platform without requiring any extra web services. SODA allows each instance of the application to have its own application certificate, allowing each instance to be sandboxed from all other instances. This significantly lessens the risk if an application certificate becomes compromised.

In the application, a GUID will be used to identify the application instance thus differentiating it from any other existing installations of the application. The HealthVault .Net SDK's SODA APIs that are used to create the Child application automatically create a new public and private key and add it to the current user’s certificate store without requiring the user to understand this process. The user can then authorize the Child application to communicate with the platform using an Offline connection. In this MSDN post the complete steps of creating a SODA application using the HealthVault .Net SDK is listed.

1. Authentication

From an end user perspective the authorization process will look the same as any other HealthVault application. The only difference will be, as the application lacks an Action URL the user will not be directly taken back to the application after the authorization. Application will have to implement some polling mechanism or track the URLs to see whether the record authorization is done.

2. HealthVault API interaction

SODA clients use OfflineWebApplicationConnection to communicate with HealthVault. The interaction happens directly from the mobile device using the certificate created by the application itself.

3. Discovering the application

The story of application discoverability goes the same for this also. The HealthVault Application Directory and the mobile application stores will be the best place to showcase the application.

4. Analysis

Scenario	Advantage	Disadvantage
Authentication	Authorization steps are done on the mobile device itself so that user does not have to leave the application for it.	During authorization the user will be directly taken to the HealthVault authorization page which is not highly friendly for a mobile device, especially those which doesn’t have a zoom option, so you will have to make sure that this is in line with your user interface requirements. This is definitely an area where we are looking to improve ourselves soon. The HealthVault application authorization workflow in the HealthVault shell provides a redirect interface that can send the user to a web app after authorization, but getting this to work cleanly for a thick client app requires a few tricks. Look at a blog post entitled “Rich Client Options” in the HealthVault FAQ blog for more information. The current address of this post is: https://blogs.msdn.com/b/healthvaultfaq/archive/2010/02/24/rich-client-options.
Deployment	As each client application or application instance will have its own unique client ID each application instance is treated as a separate application by the platform. Directly communicating with the HealthVault platform improves the response time and stability of the application.	This approach may have technical difficulties on most of the mobile platforms and some intermediate web services might be needed to make this work.
Certificate Handling	This avoids the requirement of distributing the certificates as the application will create the certificate and store in the local certificate store.	Mobile device should have the support for the certificate handling
SDK support		No mobile HealthVault SDK is available so far.

This issue is caused by the IIS Worker Process which runs under a Windows Identity account that doesn’t have enough Code Access Security to call the security APIs. This is due to the DefaultAppPool setting that is used in IIS 7.5, which is the default, running under the ‘ApplicationPoolIdentity’ account. Switching this account to the 'NetworkService' account allows you to run the HealthVault application in IIS without installing the certificate in certificate store. You can find detailed steps on how to switch a Windows Identity account here, https://learn.iis.net/page.aspx/624/application-pool-identities/.

We highly recommend using the certificate store because keeping the private key of an application intact and private is very important due to security reasons. If your configuration doesn't allow using a certificate store and you must use the file based certificate store then please ensure that a password is set for the certificate and keep it in a non-web accessible directory.

Fig 1. HealthVault Developer Center

In this upgrade of HealthVault Developer Center in addition to new look and feel, we have added following features -

• Ability to add samples for data types

Developers can now add sample data to their development account directly through HealthVault DataType explorer.

Fig 2. Ability to add samples for HealthVault data types

• Ability to edit samples

We adding controls to edit the existing sample data. Most of these controls are auto-generated and the individual fields are also hooked up to auto-complete if the schema recommends a preferred vocabulary for the field.

Fig 3. Show-casing Allergy Episode Sample

Fig 4. Control enabling editing of Allergy Episode Sample.

• Rich and Brows-able documentation for each data-type

We have added rich brows-able documentation for each data-type.

Fig 5. Brows-able documentation for Medication Type

• Each type now shows the version associated with it

Fig 6. Type Versions for Medication Type in HealthVault DataType Explorer.

• Ability to look at the content of GetServiceDefinition

Developers can now directly read the HealthVault Service Definition through the Methods Browser.

Tell us what you think..

Please feel free to comment on features you would like or report on bugs in this tool. We are planning to do a bug-fix update shortly.

There are three ways for an application to get onto your list:

• Create AppId in Application Manager client: when Application Manager uploads your ApplicationId information to the HealthVault-PPE platform, you will be prompted to login to the Application Configuration Center.  The account with which you login will become the admin account for this AppId.
• Create AppId in Application Configuration Center: there is a “Create a new application” link in the screenshot above.  If you use that link to create an AppId then the currently-logged-in account will be the admin for that AppId.
• Submit a request: if you don’t remember which account is your admin account, if you lost credentials to an admin account or if your ApplicationId was created before the existence of the Application Configuration Center then you can “reclaim” admin rights to your AppId by clicking the “submit a request” link on this page.  You will see the dialog box below.  Enter the AppId that you want to reclaim and the email address where you would like to receive the reclaim invitation.  A Microsoft person will review your request and verify that it is coming from a company that is associated with the application, then they will send the invitation mail to the specified email address.