Deploying or Publishing PGP Encryption Server on the Internet (Symantec Encryption Management Server)
search cancel

Deploying or Publishing PGP Encryption Server on the Internet (Symantec Encryption Management Server)

book

Article ID: 190699

calendar_today

Updated On:

Products

Gateway Email Encryption

Issue/Introduction

The PGP Encryption Server (Symantec Encryption Management Server) is usually located on the internal network and Encryption Desktop clients therefore also need to be on the internal network or connected to the internal network using a VPN (Virtual Private Network).

It is possible to publish the PGP Encryption Server on the Internet so that PGP Encryption Desktop (Symantec Encryption Desktop) clients do not need to be on the internal network or use a VPN connection. This avoids overloading the VPN.

However, there are various considerations to be aware of, especially when seeking to publish a PGP Encryption Server on the Internet that was previously on the internal network.

The PGP Encryption Server can only be installed on physical hardware or as a VMware Virtual Machine. The major cloud providers all offer a VMware solution: Azure VMware Solution, VMware Cloud on AWS and Google Cloud VMware Engine.

Environment

PGP Encryption Server 3.4.2 and above.
PGP Encryption Desktop 10.4.2 and above.

Resolution

The considerations for publishing the PGP Encryption Server on the Internet are as follows.

Cluster members that do not host private keys

In a PGP Encryption Server cluster, some cluster members can be configured not to host private keys of internal users and consumer groups. Do not allow PGP Encryption Desktop users to connect to such cluster members if any of the following apply:

  • You are using SKM (Server Key Mode) keys for any of your users. This is because such client keys will be permanently corrupted.
  • You are using PGP Encryption Desktop drive encryption. This is because Whole Disk Recovery Tokens (WDRTs) are not stored on cluster members that do not host private keys.
  • You are using File Share Encryption, especially with Group Keys. This is because File Share Encryption relies on private keys.

If you do not use drive encryption or File Share Encryption and use only GKM mode keys for clients, it may be possible to allow Encryption Desktop to connect to cluster members that do not host private keys but this is not recommended.

Required port to publish

All communications between PGP Encryption Desktop and PGP Encryption Server occur over port 443 (HTTPS). Therefore this is the only port that needs to be open between Encryption Desktop and PGP Encryption Server.

PGPSTAMP FQDN

When you install the PGP Encryption Desktop, the PGPSTAMP registry setting contains the FQDN (fully qualified domain name) of the PGP Encryption Management Server. For example, keys.example.com. Clearly, if the PGP Encryption Desktop clients are connecting to PGP Encryption Server over the Internet, the clients must be able to resolve this FQDN to a public IP address.

If the FQDN within the PGPSTAMP value cannot be resolved from the Internet, the PGPSTAMP value needs to be changed. You can change PGPSTAMP by downloading the PGP Encryption Desktop installer from PGP Encryption Server after changing the PGP Encryption setting, then upgrading the clients. This will force the PGP Encryption users to re-enroll. You can avoid forcing the clients to re-enroll by writing a script to quit PGP Tray and change the PGPSTAMP registry entry. Search for article 153660 for further details about PGPSTAMP.

Internal Network or DMZ

You could place the PGP Encryption Server in the internal network and configure your firewall or reverse proxy to allow clients to connect to it from the Internet over port 443. In this scenario, so long as the clients can resolve the FQDN of PGP Encryption Server there is nothing more to do.

Generally, however, you would place PGP Encryption Server in a DMZ. What you then need to consider is which ports to allow to connect from the DMZ to the internal network. For maximum security, you would allow no traffic from the DMZ to the internal network but this affects enrollment of users, regrouping of users, replication and server management. Each of these considerations is addressed below as well as listing other ports and services that may be needed.

Enrollment and Regrouping of Users

Usually, the PGP Encryption Server is configured to use Directory Synchronization for enrollment. It connects to one or more Active Directory domain controllers in order to authenticate users at enrollment time. It also usually groups users according to their membership of Active Directory security groups. Therefore, if the PGP Encryption Server is in a DMZ, it will need to be able to connect to domain controllers in the internal network over LDAPS (or LDAP but this is not recommended).

If it is not possible to connect to domain controllers in the internal network over LDAPS, the PGP Encryption Server can be configured to allow clients to enroll using email. However, regrouping of users according to membership of Active Directory security groups will not be possible. At best, you would need to create a Dictionary of user names in the PGP Encryption Server and use that Dictionary to group users. It is much more time consuming and requires frequent maintenance.

In a clustered environment, one alternative configuration would be to keep at least one PGP Encryption Server in the internal network. That server could regroup  users according to Active Directory security group membership. Users would still need to enroll using email.

If you wanted to enroll users using Directory Synchronization rather than email, you could implement split DNS whereby, for example, keys.example.com resolves to a public IP address when the client is connected to the Internet and resolves to an internal network IP address when the client is on the internal network or connected to the VPN. This way, users would need to be on the internal network or VPN for initial enrollment but after that could connect over the Internet.

Replication

If you have more than one Encryption Management Server in a cluster, the cluster members will need to be able to communicate with each other. This communication is done over port 444 so the servers will need to be able to communicate with each other in both directions over this port.

Management Console

Administrators connect to the PGP Encryption Server administration console over port 9000 so this port would need to be accessible from the internal network. For security reasons it should not be accessible from the Internet.

DNS - forward and reverse

The PGP Encryption Server must have access to at least one DNS server and in a clustered environment, that DNS server will need to be able to resolve the names of the PGP Encryption Servers themselves, using both forward and reverse DNS. In other words, the DNS server must be able to resolve the FQDN of each cluster member to an IP address and resolve each cluster member's IP address to its FQDN.

NTP

In a clustered environment, each PGP Encryption Server must be able to connect to an NTP server so that the time on each cluster member is identical and accurate.

SSH

Administrators with the SuperUser role will need to be able to connect to PGP Encryption Server over SSH (port 22) from time to time so this port needs to be open from the internal network only.

SMTP

If users are enrolling using email then clearly the PGP Encryption Server needs to be able to send email to that user. It can either send directly using the MX record of the recipient domain or, more usually, relay using one of the organization's mail servers. If users are not enrolling using email, PGP Encryption Server may still need to send the daily status message to administrators. Obviously, if the PGP Encryption Server is used for gateway email then it may need to receive as well as send email.

TLS Certificate

Given that the PGP Encryption Desktop clients are connecting to a public FQDN, it is recommended but not required that the PGP Encryption Server uses a TLS certificate issued by a well known Certificate Authority.

LDAP

If either the PGP Encryption or PGP Encryption Server are being used for email encryption, the Server will need to use LDAP to search for PGP keys on remote key servers. Outbound LDAP will also be required if the PGP Encryption Desktop users need to encrypt files to keys located on remote key servers.

Inbound LDAP will be required if remote key servers need to perform key lookups on the PGP Encryption Server.

SNMP

If the SNMP service is enabled on PGP Encryption Server, connectivity to the SNMP server will be required.

Certificate Revocation List (CRL)

If the PGP Encryption Server is used for S/MIME email and the Certificate Revocation service is enabled, remote hosts should be permitted to connect to port 80 (HTTP) on the server in order to download the Certificate Revocation List.

Verified Directory

If the Verified Directory service is enabled on the PGP Encryption Server, remote hosts will need to be able to connect to port 80 (HTTP) or port 443 (HTTPS), depending how the service is configured.

Web Email Protection

If the Web Email Protection service is enabled on the PGP Encryption Server, remote hosts will need to be able to connect to port 443 (HTTPS).

External Syslog

If the PGP Encryption Server is configured to send its logs to an external syslog server, outbound UDP or TCP port 514 to the syslog server will need to be permitted.