SSL and HTTPS with App-V 5.0

Lately I have had a lot of people ask me about securing the App-V 5.0 infrastructure by utilising the HTTPS protocol so I thought I would share a step by step guide on how you can go about implementing it. There are three main areas you can utilise HTTPS in an App-V Full Infrastructure environment:

– Content Streaming

– Client to Publishing Server

– Publishing Server to Management Server

This blog post will cover all three, however much of the same steps around certificates will apply in all scenarios, infact it might seem less like steps and more like hurdles depending on how much patience you have to get this working! Hopefully if you follow the steps below you should have a largely stress free experience!

 

 Content Streaming

1. Create Virtual Directory

Assuming you already have a folder holding your content you need to create a virtual directory in your IIS console as shown:

You need to create a mapping to the physical folder you wish to provision:

Test the connection to the content and take note of any warnings, you may need to revisit this if you hit issues later down the line:

 

2. Add MIME Types

The next step is to add a MIME type for .appv file extensions, .xml files will already be covered by default:

The file name extension should be for .appv of MIME type application/appv

 

3. Check Directory and Tweak Permissions

Next, before you look to use HTTPS its best to check everything is in order with standard HTTP streaming, hit the Browse Virtual Directory link in IIS:

If it goes through fine then great, however if you get a screen like this saying “Cannot read configuration file due to insufficient permissions” then we need to tweak the permissions so the web.config in the content folder is accessible.

First thing to check is your application pool, typically it should be running as Network service but if it isn’t you can change it as shown:

Once you access the advanced settings of the application pool you change the Application Pool Identity account:

Next thing is to make sure the permissions on the security of your content folder itself are correct, give the following objects read & execute, list folder contents and read permissions if they are not already listed:

– IUSR

– SYSTEM

– NETWORK SERVICE

– COMPUTER ACCOUNT

Hit Browse again:

If you hit a page like this which says “The web server is configured not to list the contents of this directory” then it is actually a good sign! Your permissions are correct!

 

4. Enable Directory Browsing (Optional)

If you prefer not to hit the HTTP error above from a browser you can enable directory browsing to list contents. This can be useful for troubleshooting and general inspection of the HTTP(S) content structure but will be accessible to all users with permissions. You can find this setting in the Virtual Directory panel, just hit enable.

You should then find you can browse the content directory:

 

5. Check HTTP Import and Delivery

At this stage my opinion is you should check that a basic HTTP delivery of an application works by importing a package into the management server and publishing it to a client machine:

Aslong as it imports successfully and is successfully delivered to the client you can be satisfied that everything is setup correctly:

For some great information about optimising your IIS deployment for better performance check out this great blog post by Ingmar.

 

6. Import a Certificate

Now before we can start using HTTPS we require a certificate to allow us to start utilising SSL, this certificate will verify the identity of the machine and our URL for content. You have three options for obtaining a certificate:

1. Self Signed

2. Domain PKI

3. Third Party CA

Now I highly recommended avoiding using a self signed cert, not only because it is bad practice for a production environment but also as the Management Server itself is likely to reject it and throw a error at import which details that “Content decoding has failed”:

Another time you may see error message is when trying to load balance services with a wildcard certificate, more details on how to resolve that here.

As you can see below my machine already has a self signed certificate which has been created by IIS, but as mentioned instead of using this I would recommend either purchasing and importing a certificate from a third party CA or if you have a PKI infrastructure setup you can request a certificate from  your internal CA using the Certificates snap in for MMC :

]

Once you have your certificate in place you should see it appear in the MMC console:

 

7. Create Binding

Now to enable SSL on your content you need to create a binding for the HTTPS protocol by clicking bindings and adding an entry. You should select the certificate you have just imported:

 

 8. Require SSL (Optional)

It is very possible that as part of securing your content you will want it to only be accessed over HTTPS and not HTTP in which case you can tick the box that says “Require SSL” on the virtual directory settings:

 

9. Test HTTPS Access

You will notice you now have the option to browse via https since creating the binding, I have not required SSL as above so I also have the option for HTTP:

Clicking the browse HTTPS link however will appear to take you to a untrusted site:

This is because the URL does not match the URL in the certificate, if you enter the exact naming as specified in the certificate you should find it passes through without any warnings, in this case I am required to use the full FQDN in my URL as my certificate does not have any aliases for other URLs:

 

10. Import and Deliver the Package

Nearly there! Now all that is left to do is import and deliver the package to test it works:

Notice we need to use the full path as we specified in our certificate to ensure there are no challenges to authenticity.

And there we go all published, streamed and delivered over HTTPS!:

 

 Client to Publishing Server

Now next up is configuring the Publishing Server to enable refreshes over HTTPS to the client. As this will be on a different server you will need to repeat the steps 6 to 8 above relating to certificates. After that the remaining steps are pretty simple:

 

1. Create Binding

Exactly as we did on our content store, we create a binding for HTTPS, this time on the Publishing Service site:

 

2. Require SSL (Optional)

If you want your publishing server to only ever function over HTTPS then you can tick the “Require SSL” option on the SSL settings of the site. WARNING: This will stop any clients that are already configured to use the publishing server for standard HTTP performing a successful refresh.

 

3. Configure the Client

The next task is to configure client with the new publishing server URL:

and finally test that a refresh completes successfully!:

 

Publishing Server to Management Server

The final task is configuring the Management Server to operate over HTTPS and to allow the Publishing Server to communicate securely . As this will be on a different server to the Management Server you will need to repeat the steps 6 to 8 in the Content Streaming section relating to certificates. After that the steps are again pretty simple:

 

1. Create Binding

Exactly as we did on our content store  and Publishing Server, we create a binding for HTTPS, this time on the Management Service site:

 

2. Test Console

The next step is to test the console, you will likely get prompted for your credentials when connecting:

But it should look and function as normal once you are in:

 

3. Change Settings on Publishing Server

Next you need to change the PUBLISHING_MGT_SERVER setting on your Publishing Server which relates to the Management Server URL, this can be found in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Server\PublishingService and should be amended with the new URL of your Management Server with URL matching your certificate:

 

4. Restart Publishing Site

The last thing to do is to restart the Publish Service in IIS so it picks up the new setting:

Finally all you need to do is test that a new package imported into the Management Server is picked up by the Publishing Server, you can do this by checking the PublishingMetaData.xml in C:\ProgramData\Microsoft\AppV\Server\Publishing\ by looking to see if it is being updated according to your refresh interval (default 10 minutes). After following all of the above, any newly published packages should get successfully delivered to the client end to end over HTTPS.

 

Summary