The following error message appears while configuring secure ICA connections in XenApp and XenDesktop 7.6L

"Unable to access the Private Key of the Certificate or one of its fields".

Following the steps to configure end-to-end security should have resolved the issue however there were problems with SSL certificate trusts.

1. Ensure that SSL certificates used for end-to-end security have private keys and that they are exported with the private keys.

2. Ensure that the parent certificate from the issuing CA is installed where required (client machine and VDA).

There are 2 types of VDAs that we need to consider:

• Dedicated/persistent Desktop and Server OS VDAs.
• Pooled Desktop and Server OS VDAs.

Since a dedicated VDA will always have the same hostname, the machine can always use its own certificate.

Pooled Desktop VDAs and Server OS VDAs will spawn a new machine name each time so these machines will need to Auto-enroll for a certificate – for their own machine name.  (Remember that the instructions warn us that there is a problem with certificate Auto-enrolment with pooled Server OS VDAs:  “…the ICA listener is brought up too early during the boot process, before certificates can be automatically provisioned.”

Host Certificates

We only need DDC and VDA certificates.  We don’t need client machine certificates.  But the client machines do need to trust the certificate being offered by the VDA.

Self-Signed

You can create a self-signed certificate for testing purposes, but as we discovered, self-signed certificates only work for Server OS. You can most easily create a self-signed certificate using the IIS console.  If IIS is not installed (usually on a DDC that has no StoreFront installed), you can use the New-SelfSignedCertificate PowerShell script to create one.

For a Desktop OS VDA, self-signed certificates fail when running the Enable-VdaSsl.ps1 PowerShell script.

Certificates from commercial CA or Active Directory Certificate Services (AD CS)

In a production environment, self-signed certificates will be completely impractical. Since all of the VDAs (and DDCs) have AD Domain membership, it is advisable to use AD CS for distributing and managing certificates.  If you have external users whose machines do not have domain membership, then you will need to export the AD CS’s root CA certificate (the issuing certificate) and import it on to non-domain machines.  (Even if your machines are members of the AD Domain, you will still need to check that the AD CS’s root CA certificate is present on the client endpoint machine under Certificates (Local computer) > Trusted Root Certification Authority > Certificates.)

If configured as such, dedicated Desktop OS and Server OS VDAs will automatically receive its machine certificate from the AD CS (Certification Authority).
If you’ve deleted the VDA’s certificate, you can obtain a new one using web-enrolment at:  https://<servername>/certsrv

The use of commercial CA providers is not the cheapest option but at least any issuing CA’s root and intermediate certificates should already be installed on the client endpoint machine.

Trusting the Host Certificate

When a client connects to the VDA, the VDA offers its certificate to the client.  It is crucial that the client can check the VDA’s certificate against the issuing CA’s root, and intermediate (if present) certificate. If the issuing CA’s root and/or intermediate certificate is not present on the client endpoint machine, you will need to install it. And before you install it, you will need to Export it.

Exporting the CA’s issuing certificate

1. On the VDA, open an MMC console and Add the Certificates snap-in for Local Computer.  Under Personal > Certificates you should see the installed certificate.

2. Open the certificate and check the certificate of the issuing CA (not relevant for a self-signed certificate). Note the thumbprint if necessary so that you can ensure an exact match.

3. Go to the CA console and locate the exact same certificate identified in the step above.

4. Right-click and Export the certificate. You must export the certificate’s private key with it.  You will end up with a PFX file.

1. On the client machine, open a MMC console and add the Certificates snap-in for Local Computer.

2. Go to Certificates (Local computer) > Trusted Root Certification Authority > Certificates.

3. Right-click on the Certificates folder and choose Import.

4. Import the PFX file created earlier and ensure it is present after refreshing the folder.

5. (If necessary, intermediate certificates need to be installed after exporting also).

Self-Signed

A self-signed certificate has no separate issuing CA certificate – it trusts itself.  Obviously a self-signed certificate will not be known to the client endpoint, so you will need to Export the self-signed certificate and again with its private key. Then import it into Certificates (Local computer) > Trusted Root Certification Authority > Certificates on the client machine.

Notes:

• We discovered that the Enable-VdaSsl.ps1 PowerShell script (on the VDA) failed to complete when using a self-signed certificate.  The reason for this was that the self-signed certificate needs to be Exported (with private key) and imported to the Certificates (Local computer) => Trusted Root Certification Authority => Certificates on the VDA.  I know it’s essentially the same certificate, but it still needs to be done.

• A note about exporting the self-signed certificate.  It is possible to also use PowerShell to export the certificate.  You will need to use ConvertTo-SecureString and then Export-PfxCertificate to do so.  An article with step-by-step instructions is here: http://windowsitpro.com/blog/creating-self-signed-certificates-powershell

• When using the Enable-VdaSsl.ps1 PowerShell script, the thumbprint is entered without spaces and without quotation marks.

.\Enable-VdaSSL.ps1 -Enable -SSLPort 443 -SSLMinVersion TLS_1.0 -CertificateThumbPrint 6b4994016bf1d228f4a8d69c69ae415ca8fb2dfa
 
**Note the use of “-SSLPort” and “-SSLVersion” in the command.

Problem Cause

Citrix Blogs - How To Secure ICA Connections in XenApp and XenDesktop 7.6 using SSL