Certificate

Preparing Certificates and GPOs for System Center Update Publisher

Richard Green on 23rd March 2015

If you are using Configuration Manager to manage and patch your client estate then you already know that it’s great to have your Software Updates in the same console as your Application Delivery and the way in which Configuration Manager 2012 R2 manages Software Updates is a big leap on usability over Configuration Manager 2007 however the missing piece of the puzzle for many is managing non-Microsoft updates and for that, we need to enlist the help of a free product from Microsoft called System Center Update Publisher.

Before we start anything with Configuration Manager, WSUS or SCUP however, we do have the small matter of prerequisites to cover off and in this case it requires a certificate and a Group Policy setting or two. The certificate we are interested in is a Code Signing certificate which unless you are familiar with signing PowerShell scripts that you author, you may not have come across previously and your internal CA may not be setup to issue. You can buy these certificates for Code Signing from an external third-party CA if you wish but it is easiest and best done internally as after all, the code you are going to be signing is for updates to your internal clients.

Creating the Code Signing Certificate Template

On your Certificate Authority, we need to configure it to issue a Code Signing certificate. You can either use the native Code Signing template or you can create a custom template just for SCUP so that you can limit the scope of the certificate template to selected users or a group of users accordingly. If you want to create a new template then duplicate the existing Code Signing certificate for the purpose.

Once you have decided on the template to use, configure the CA to issue the certificate. In my lab, my template is called SCUP Code Signing and the security on the template limits users in an Active Directory Group called SCUP Code Signing Users to being able to Enroll the certificate which prevents users, malicious or otherwise from requesting the certificate.

Request the Code Signing Certificate

Once you have configured everything on the CA, you need to request a certificate based on this template. Using the Certificates MMC snap-in for your user account, you can request to enrol the certificate from your Active Directory Enrollment Policy.

If you based your new Certificate Template on the Code Signing template or you used the Code Signing template, you don’t need to enter additional information and the request will be built from Active Directory user attributes. Once you have created the certificate, you need to export it twice. For the first export, export the certificate only in .cer format and do not export the private key. This portion of the certificate will be used in the Group Policy Object shortly. The second export is required to be in .pfx format and include the private key and is used in SCUP for configuring it once installed.

Configure the Trusted Publishers Group Policy Setting

Once you have issued the certificate and you have exported it twice; once as a .cer file and once as a .pfx file, we need to configure the Group Policy for the Trusted Publishers. Put simply, in order for your client PCs to install updates that are not signed by Microsoft, the clients need to trust the updates. In order for the updates to be trusted, they need to be signed with a certificate that the clients trust. Having a certificate from your internal CA isn’t enough for this though. Once you have a certificate, a client will trust it as it is from a Trusted Root Certification Authority but it will not be trusted for code signing unless added to the appropriate certificate store.

Using ether a new Group Policy Object or an existing object which contains your other Certificate Services related settings, we need to add the .cer certificate exported earlier to the policy.

Within the Group Policy Object, expand the Computer Configuration folder and then drill into Security Settings followed by Public Key Policies. Within the Public Key Policies folder, open the Trusted Publishers folder. In here, you need to import the Code Signing certificate .cer file that was previously exported. Doing this allows your clients to trust updates signed with this certificate for the publishing of software and applications.

Make sure you use the .cer export and not the .pfx export here as we only want the clients to have and trust the public key portion of the certificate. Distributing the .pfx would give these clients the private key also and that would be bad to have sent throughout the entire environment on every machine linked with the GPO.

Next, we need to change one setting in relation to the Windows Update Agent on the clients. In the same GPO or in another GPO if you have one dedicated to Windows Update related settings, navigate to Computer Configuration, Administrative Templates, Windows Components, Windows Update. Here, you need to change the status of the Allow signed updates from an intranet Microsoft update service location setting from Not Configured to Enabled. This second setting allows the Windows Update Agent to actually detect and download updates from your WSUS and SCCM environment if they are not signed by Microsoft and this setting is paired with the Trusted Publisher certificate above to make non-Microsoft updates trusted on the client.

With these all the above completed, you are now set and ready to deploy System Center Update Publisher and a follow-up post I will be publishing soon will cover the SCUP installation and setup.

SSL Certificates and Wild Pricing

Richard Green on 9th October 2013

As part of a project of work I’m looking into currently, we are planning a move from Exchange 2007 to Exchange 2010. As those of you who’ve done this before will know, you need to setup the environment with two namespaces for a period of the migration which Microsoft refer to as the Exchange 2010 namespace and the legacy namespace (the Exchange 2007 namespace). As part of this, we need to get a new SSL certificate.

Normally we buy our certificates from VeriSign as a standard rule of thumb however after looking at the costs today, I’m starting to wonder how VeriSign do so well in the SSL certificate business? I’m not going to go into exact specifics, but the overall cost for the certificate I was looking to purchase was £69,000 which is frankly unbelievable for a certificate to secure a messaging platform. The cost of the certificate is over double what we paid for a pair of HP DL380p servers fully loaded with 900GB SAS disk for local storage to host the DAG Mailbox roles. To make it worse than just the price on it’s own, that’s just for one year validity on the certificates too.

Out of curiosity and because they are starting to develop a bit of a name for themselves, I decided to compare the cost of this to GoDaddy. That very same certificate, offering me the same number of SAN names for the Exchange features with GoDaddy is a mere £165 a year.

How I wonder, when you compare £69,000 to £165, do VeriSign actually sell any certificates? Sure VeriSign offer more in the way of commercial compensation that GoDaddy ($1,500,000 for VeriSign and $160,000 for GoDaddy) but commercial compensation really only applies to transactional or commerce websites. When you are talking about a messaging platform, coupled with a two factor authentication system, the compensation loses it’s value quickly. GoDaddy offer a Malware inspection service for secured sites, something which VeriSign also offer. VeriSign have some value add propositions that GoDaddy don’t, I will grant them that. Features such as Norton Secured Seal and a Symantec Search Seal are on offer but both of those things are dependant on people having Norton software and browser plugins installed to show the seal. Installing browser plugins which really aren’t needed and adding a true sense of value is something which I don’t recommend and nor do Microsoft hence the popups that modern versions of Internet Explorer have asking you to disable addons.

With GoDaddy being so popular these days, their Trusted Root CA certificate is valid on a claimed 99.9% of devices therefore gone are the days of use the likes GoDaddy or Comodo SSL at your peril due to the possibility of getting certificate invalid warnings on the clients.

I haven’t taken a decision on the purchase just yet as it needs some consultation within the company, but one or two people I spoke to today agreed with me in so much as why shouldn’t we use GoDaddy and frankly, I’m not seeing a lot of reasons why currently?

Certificate Store Permissions and Windows Live Block App-V RTSPS Protocol

Richard Green on 11th October 2011

Last week, when converting our existing ICT internal dogfood trial of App-V to a highly available production capable App-V solution, we came to a decision to utilize the RTSPS (Real Time Streaming Protocol Secure) protocol for streaming our applications.

Using some my own and another colleagues laptops for testing the RTSPS protocol, we ran into an issue whereby the client received the following error:

The specified Application Virtualization Server has shut down the connection. Try again in a few minutes. If the problem persists, report the following error code to your System Administrator.

Error Code: xxxxxx-xxxxxx0A-10000009

We initially discovered from an App-V blog article (http://blogs.technet.com/b/appv/archive/2010/03/09/troubleshooting-common-rtsps-issues-with-app-v.aspx) that this issue occurs when the server lacks permissions for the NETWORK SERVICE account to access the certificate store machine keys.

Following the advise of the article for Windows Server 2008 R2 systems, this was quickly resolved by using a Certificate Management based Microsoft Management Console to grant Read permission for the NETWORK SERVICE account to the certificate which is being used to sign the RTSPS protocol in App-V.

Thinking the issue was resolved, we proceeded to initiate a Refresh on the App-V client and tried to stream an application that we had previously sequenced, however we now received a new error:

The Application Virtualization Client could not update publishing information from the server App-V Server. The server will not allow a connection without valid NTLM credentials. Report the following error code to your System Administrator.

Error code: 4615186-1690900A-00002002

Leaving us puzzled. We were unable to find a solution initially, so we turned to Bing for some assistance, unearthing an interesting but niche blog post.

According to the source of our findings (http://blogs.ethz.ch/jlaville/2011/08/25/app-v-error-00002002/) machines with components from the Windows Live Essentials suite of applications cannot run the RTSPS protocol due to a registry key added to the LSA Security Packages key.

After removing the livessp value from the multi-value string in the registry and restarting the system we were successfully able to refresh the server and also stream the applications.