Archive for December, 2009

Many applications today require the use of certificates that certify multiple subject names. These certificates are typicalled SAN certificates because the additional names are stored in the Subject Alternate Name field of the certificate. One of the simplest ways to generate a request for such a certificate is to use Exchange 2007/2010’s New-ExchangeCertificate PowerShell command. If, however, you’re not running Exchange in-house, this option is not available. For those instances, the following process can be used to generate a SAN certificate request using native Windows tools.

1)      Open a new instance of MMC and add the Certificates Snap-in. Configure the snap in to access certificates for the computer account of the local computer.

2)      Right click the Personal folder and choose All Tasks-> Advanced Operations->Create Custom Request.

a)      Click Next on the welcome page.

b)      If prompted to select a policy, choose to proceed without a policy and click Next

c)      Choose “(no template) Legacy Key” as the Template

d)      For Request format, select PKCS #10 (the default selection) and click Next.

e)      Click on Details to expand the listing and show the Properties button. Click Properties.

f)       Set the following properties

i)        Private Key tab

(1)   Key Type: Exchange

(2)   Key Options: select the desired Key size. I typically use 2048.

(3)   Key Options: check Make private key exportable.

ii)      Extensions Tab

(1)   Extended Key Usage:  Add the Server Authentication option to the selected list on the right.

iii)    Subject tab

(1)   Add an entry of type Common name to the Subject name field with primary subject name

(2)   Add entries of type DNS into the Alternative name field. Add the primary subject name and any other required additional names.

NOTE: Wild cards can also be used with this method although currently Windows Certificate Authorities do not support issuing wild card certificates.

iv)    General tab

(1)   Enter a friendly name and description text that will be associated with the certificate and make it easier to identify the certificate and its purpose.

g)      Click OK to close the Properties dialog and click Next.

3)      Enter a filename for the request file (e.g. c:\iis-san-csr.req) and click Finish.

4)      The request file can now be used with an internal Windows Certificate Authority (Using Web Enrollment) or a third party CA. Note that for a third party CA additional fields might be required to match the organization’s registered identity (OU, Department, State, Country, etc).

5)      Once you get back the certificate from the Certificate Authority, open the Certificates MMC again, right click on the personal folder and choose All tasks -> Import. Find the file and go through the wizard with the defaults.

That’s it. The resulting certificate can be exported with the private key.

Advertisements

The complexity of a System Center Configuration Manager 2007 R2 (from here on referred to as SCCM) is significant without the addition of native mode security and Internet Based Client Management (IBCM). But if you do need to extend your systems management for clients that rarely join your network, a common requirement for an organization with a remote sales force or telecommuting workers, you’ll appreciate the functions that are delivered with the additional complexity.

One additional element that adds to the complexity is the security implication of the IBCM solution. Since Internet based systems must connect to SCCM servers that are domain members, allowing those clients to connect directly to the IIS component on the servers probably violates not only your organization’s security policy but also general security best practices (not to mention common sense). The solution? Since the authentication for those IBCM clients is two way, requiring both a client and server authentication using PKI certificates, the options are limited to publishing the solution using an ISA server. Of course, since we want to avoid single points of failure, it would typically be an ISA farm with two (or more) servers in an array.

General instructions for configuring this scenario can be found here: http://technet.microsoft.com/en-us/library/cc707697.aspx

This is where we run into a couple of complications:

Certificate deployment

The ISA servers in this scenario will act as application proxies for the SCCM connection so the clients will authenticate to the ISA server (Using their SCCM client certificates) and the ISA server will authenticate to the client (Using the SCCM server certificate that was exported and imported in each ISA server). Then the ISA server will establish the connection to the SCCM servers and authenticate to them using its own client certificate.

The complication occurs because the client certificate deployment process that is executed on each ISA server results in a unique certificate for each server and the publishing rule certificate authentication configuration requires a common certificate in an array/farm configuration.

By default, the SCCM client certificate template does not allow the certificate to be exported since that will allow anyone with 5 minutes of access to any client system to export the certificate and use it to create any number of unauthorized SCCM Internet client systems.

The solution is to make a copy of the SCCM client certificate template that does allow the certificate to be exported using the following process:

1. Open the Certificates Template MMC

2. Right click on the Configuration Manager client template and select Duplicate Template

3. Select a name for the duplicate, such as Exportable Configuration Manager client

4. On the Request Handling tab, check the box labeled ‘Allow private key to be exported’

5. Select the security tab and configure the required security

NOTE: Make sure to configure the security on the new template to restrict enrollment and auto enrollment as appropriate.

6. Click OK to save the new template

7. Open the Certificate Authority management console

8. Expand the certificate authority, right click on the Certificate Templates folder and select New->Certificate Template to Issue

9. Select the newly created exportable template.

Once the new template is deployed to the CA, use it to issue a certificate to one of the ISA servers, export the certificate and import it into all the other ISA array/farm members and it can be used on the publishing rule successfully.

Software Update deployment – WSUS

The software update deployment process, for internal and Internet based clients, uses WSUS as an update catalog. The result is that Internet based clients must access WSUS as well as SCCM components over the Internet.

The complication here is that WSUS doesn’t support client authentication at all, certificate or otherwise. Only regular SSL based server authentication is required. In an ISA published world, that means a new listener with a unique IP address/port combination.

The solution is to deploy WSUS to a custom web site on the Internet facing SCCM servers using custom ports (typically 8530, 8531 for WSUS) and configuring an ISA publishing rule for the custom ports. Step by step for the creation of the publishing rule are available here: http://blogs.technet.com/wemd_ua_-_sms_writing_team/archive/2008/10/29/how-to-configure-isa-ssl-bridging-for-the-internet-based-softare-update-point.aspx.

If you’ve already deployed WSUS to the default web site, moving it to the custom web site can be accomplished with the following command:

C:\Program Files\Update Services\Tools> wsusutil UseCustomWebSite True

And don’t forget to change the port configuration on the Software Update component in the SCCM console.

I hope these tips help someone avoid the two weeks it took me to put all the pieces together.