Due to its server-oriented nature, testing PGP Universal required a unique test set up. I configured two networks: Arpstorm and Foobar. The Arpstorm network was the network that the product was deployed on, while the Foobar network was the external network that messages would be sent to.
Both networks ran Windows Server 2003 Enterprise Edition, which managed their mail and DNS servers, and hosts on both networks ran Windows XP Professional. In order to eliminate any unforeseen variables such as hardware or network difficulties, and since my goal was a functional review of the product and not any performance benchmarking, I set up both of these networks on a machine running VMWare Workstation.
It is important to note that the above Windows clients and servers were chosen because they are supported by PGP Corp. While my experience with the product leads me to believe that Open Source applications would be able to manage an installation of PGP Universal, with the exception of the Thunderbird mail client, there are no Open Source applications that are supported at this time.
Figure 5: Initial setup screen for PGP Universal
(Click image for more detail)
As previously noted, PGP Universal is installed on a dedicated host on an organization's network. The product can be set up in one of two configurations - gateway placement, or internal placement.
In gateway placement, the host sits logically outside of the mail server (and outside the network's firewall) and encrypts outbound mail after it is sent from the server.
In internal placement, the host sits logically behind a company firewall and between clients and the mail server. In this configuration, Universal encrypts outbound email before it hits the server, where it sits queued in encrypted form before being sent on its way.
Since MX records and DNS names must be updated differently for each of these configurations, the placement decision must be made before starting installation. Something else that needs to be considered when choosing the installation configuration is the protocols that will be used for email. POP or IMAP may only be utilized with the internal server placement, while SMTP may be used with both placement methods.
Figure 6: Linux packages being unpacked onto the system
(Click image for more detail.)
I chose an internal placement and started to set up the server. Booting the dedicated (virtual) machine - since Universal will wipe the hard drive of whatever you put it on - with install CD in place briefly displayed a loading screen followed by a prompt where we could enter any options for installation. Since I was ok with the default network IP addressing used (Universal assigns itself an IP of 192.168.1.100), I didn't need to use the customnet argument and simply hit Enter.
The program then pretty much installed itself, unpacking and installing all of the necessary Linux packages such as Java and Tomcat, and then restarted.
Figure 7: The PGP Universal setup page welcomes you in seven different languages
When the dust had cleared from the restart, I was able to log into the PGP Universal Server via a web browser from another machine on the network and configure it. This was an easy enough process, and after entering information about my test network such as DNS and mail servers and assigning the Universal box its own name, the system restarted once more. (Note that I had to to update our DNS server's host records to allow other machines on the network to access it via name.)
In the next and final part of this review I'll dive deeper into PGP Universal to see if it lives up to its claim of effectively implementing automatic email encryption for an entire organization.