Deploying a Self-Signed Root Certificate with Group Policy

Several customers are deploying the latest version of
the excellent
Evolution
payroll service-bureau software from iSystems, and the new management
interface is web based via SSL. This is a major improvement over
the previous version that required interaction with the server via
a logged-in user.

But the web certificate used by the vendor is self-signed, which means
that Internet Explorer users visiting the management interface are
greeted with an untrusted-certificate message:

Though it’s not difficult to dispense with this message – one can accept
the certificate with a few clicks – all users on all workstations must
go through this, and we’d prefer to avoid it. Fortunately, we
can capture and deploy the certificate with Group Policy throughout
the enterprise. It’s worked really well.

Note – this Tech Tip is intended to be used generally
for any kind of certificate deployment, but we’re using the
specific example of Version 6 (“Garfield”) of Evolution. Our
server platform is SBS2003 with XP/SP2 workstations. We’ve
not investigated this process for any browser other than IE.

Disclaimer – We’ll also note that we are not even remotely
approaching PKI or Group
Policy experts, and we have mainly muddled through several of the choices
offered on the road to something that appears to work well. We’d certainly
welcome input from those who actually know this stuff.

Getting a copy of the certificate into a file

Ultimately we need a copy of the public certificate into a file so
that it may be imported into Group Policy, and though some vendors
may publish this certificate on a website, it’s easy to use the
browser itself and export the cert to a file.

Begin the process by loading IE, visiting the website of interest,
and provoking the security warning. It may be necessary to exit all
instances of IE if the certificate had previously been accepted, but
once visible, click the [View Certificate] button.

There is lots of information about this certificate, and we want the
[Details] tab which confirms that the certificate is from who we
think it’s from. Click the [Copy to File] button:

Here we’re offered quite a few choices of certificate format, and we
have chosen Cryptographic Message Syntax Standard (PKCS #7) for no
particularly good reason – we know that it imports correctly into
the Group Policy editor. We don’t think the certificate path matters.

Clicking [Next] prompts for a filename, and it should be of the
form (the .p7b extension matters). The
file should then be somehow moved to the Windows Server with the Group Policy
Management.

Deploying the Certificate with Group Policy

With vendorcert.p7b now on the server, we’re ready to
deploy the certificate.

Launch the Group Policy Manager
and navigate to a suitable object: we prefer the Default
Domain Policy because there is no harm in deploying this
certificate throughout the entire enterprise. Right-click
on that object and select Edit:

In the Group Policy Object Editor, navigate down to:

Computer Configuration
» Windows Settings
» Security Settings
» Public Key Policies
» Trusted Root Certification Authorities

Then right-click and select Import.

In the Certificate Import Wizard, browse to the location of the
file; here we’re looking for vendorcert.p7b. Click
[Next].

With the file selected, we’re shown the Certificate Store
dialog that selects the target location for the cert.
We’ve seen only one choice available with all the rest
grayed out. Click Next.

In the wizard completion dialog, review the settings: they should
all be familiar. Click Finish.

Finished! The certificate has been imported, and it appears in the Group
Policy object. The next time a user logs in, these settings will be
applied and the certificate will be trusted by Internet Explorer.

Multiple (and unrelated) certificates may be deployed in the same
way, so that as other systems enter production with self-signed
certs, they may be included in the same Group Policy object.

We should note, however, that this procedure is intended for
intionally self-signed certificates that are known to be
trusted, and it’s not meant to ameliorate browsing
sites with broken certs (expired, wrong server name, etc.).
Please keep in mind that SSL certificates are a security
measure, and bypassing it thoughtlessly may lead to unpleasant
surprises.

This entry was posted on Tuesday, January 27th, 2009 at 12:23 pm and is filed under Information Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.