Gene published this to the SoftGrid Team Blog while i was out on Annual Leave (I went to Ireland to enjoy the Black Gold!)..... For all you faithful readers here it is!
Hi Everyone! My name is Gene Ferioli and I am a Senior Program Manager on the SoftGr...... Errrr.. I mean Microsoft Application Virtualization Product Team. We, the Engineering team, are VERY proud to have released the 4.5 beta which is the official first Microsoft "branded" version of the Application Virtualization product since the acquisition of Softricity back in July 2006.
Going forward, we're hoping you'll find this blog useful as our goal is to communicate information on the new features/functions we've added in the 4.5 release.
Today, I'm going to blog on how to setup a Application Virtualization server in "Secure Mode". Essentially, "Secure Mode" is enabling the Transport Layer Security (TLS) feature so clients connecting to the AppVirt Servers do so in a "secure" manner. We've made some changes in the 4.5 release as we've ripped out our old TLS implementation and are now using Microsoft's SChannel. This means you can use standard X.509 V3 certificates!!!!
Certificate provisioning is a good lead in on discussing the prerequisites which need to occur before setting up an Application Virtualization server in "Secure Mode". Those of you familiar with Public Key Infrastructure (PKI) understand the need for process around certificate provisioning. I’m not going to get into the nuances of PKI deployments, but rather discuss the Application Virtualization Server PKI requirements.
In the 4.5 release, we support Server authentication only (not mutual auth). This means when the client connects to the AppVirt Server, the server must authenticate itself to the client or the connection will fail. The following certificate attributes are evaluated by the client during the server authentication phase. You should also use the attributes below when working with your PKI team to let them know the certificate requirements for your AppVirt Server:
Certificate must be valid. If the certificate is not valid, the client ends the connection
Certificate must contain the correct Enhanced Key Usage (EKU) - Server Authentication (OID 18.104.22.168.22.214.171.124.1). If the certificate does not contain this EKU, the client ends the connection
Certificate FQDN must match the server on which it’s installed. This means if the client is calling RTSPS://Myserver.mycompany.com/content/MyApp.sft AND the certificate “Issued To” field is set to “Fooserver1.mycompany.com”, the client will not connect to the server and the session will end. The user will be notified of the failure and why.
Client (and server) needs to trust root CA – The CA issuing the certificate to the AppVirt Server must by trusted by the client connecting to the server. If not trusted, the client ends the connection.
So, we’ve discussed the requirements for installing a certificate on the AppVirt server in order for clients to successfully connect (securely) to an AppVirt server, now let’s discuss the process of what needs to occur to setup the server in “Secure Mode”.
ACL’ing the Certificate Private with the AppVirt Service Account
In the 4.5 release, we no longer run under the system context. The Appvirt server operates on a principle of "least privileges” so the server is granted the minimum rights needed in order to function properly. By default, the server runs under the Network Service account. However, you can create a service account in Active Directory and replace the Network Service account with the AD account if you wish. I’ve worked with some customers whose security policy mandates creating service accounts rather than using built-in accounts.
What security context the server runs under is important to understand as the next part of the discussion covers acl’ing the private key so the AppVirt server can access it.
As discussed above, AppVirt service runs under the Network Service by default. The Network Service must have READ permissions on the certificate private key. By default, when you generate a PKCS#10 (Certificate Signing Request) on your AppVirt server, the Windows Crypto Service Provider is called and a private key is generated. By default, the private key is acl’d with System and Administrators accounts only. If we don’t ACL the private key with the service account the AppVirt server runs under, ALL TLS communication will fail when SChannel attempts to access the key during a TLS transaction.
Hint: If you see this error in your AppVirt System event log, you need to acl the private key with the AppVirt service account.
System Event Error
A fatal error occurred when attempting to access the SSL server credential private key. the error code returned from the cryptographic modlule is 0x80090016
The following steps should be followed on the server you plan to install the Application Virtualization software. These steps ensure the AppVirt service will have access to the private key BEFORE installing the AppVirt server. The steps below assume a valid certificate has been provisioned to your App Virt Server.
Please note, you can setup an App Virt server in "non-secure mode" and later go back and configure the server to be in "Secure mode". We'll talk about how to do this in later postings.
1. On the App Virt Server, open the certificates snap-in for the MACHINE store and find the Thumbprint for your X.509 certificate:
2. Download the FindPrivateKey tool from MSDN.: http://msdn2.microsoft.com/en-us/library/ms732026.aspx
3. Using the FindPrivateKey utility, execute the following command to determine the correct private key associated to the certificate provisioned to your AppVirt Server.
C:\> FindPrivateKey.exe My LocalMachine -t "14 5a 5e af 17 de b9 3b 4d 4f 74 dd cb a0 4d 77 d4 a2 47 be"
Private key directory:
C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
Private key file name:
4. Open C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys and find that file:
5. Right click on the file and select Properties and click on the Security tab. Change the ACL of that file to allow NETWORK SERVICE (or the designated service account) read access:
That’s it! You’re done and now ready to install your Application Virtualization server in "Secure Mode". We’ll cover this process in my next blog. Stay tuned!!
You mentioned, Quote:
"Certificate FQDN must match the server on which it’s installed. This means if the client is calling RTSPS://Myserver.mycompany.com/content/MyApp.sft AND the certificate “Issued To” field is set to “Fooserver1.mycompany.com”, the client will not connect to the server and the session will end. The user will be notified of the failure and why."
How does this affect VAS installations that use Windows NLB, and are therefore calling a DNS name rather than a Hostname?