This site uses advanced css techniques
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.
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 vendorcert.p7b (the .p7b extension matters). The file should then be somehow moved to the Windows Server with the Group Policy Management.
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:
» 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.
First published: 2005/07/06