A remote PGP Encryption Server (Symantec Encryption Management Server) is known to permit key searches but the local PGP Server cannot connect.

By default, when an internal user tries to send an encrypted message, the PGP Encryption Server will attempt to retrieve the recipient's public key by doing a key search.

For example, if the recipient's email address is [email protected], the PGP server will attempt to connect to the host keys.example.org on the LDAP port 389 and perform a search.

The Mail log will contain an information message like this:

key search <[email protected]> [keys.example.org]: Could not get recipient encryption key: server open failed

Although Port 389 is discussed in this KB, it is recommended to use port 636 for secure LDAPS Key lookups, however the principals for this scenario still apply.

For more information on port 636 and its requirements, see the following article:

175858 - PGP Encryption Server Requirements to connect to a remote key server over LDAPS (Symantec Encryption Management Server)

Normally there are three potential reasons for this issue:

1. The local PGP Encryption Server is blocked by a local firewall from connecting to remote hosts on the LDAP port 389.
   
   
2. The Default Gateway of the local PGP Encryption Server cannot route traffic to the remote host.
   
   
3. The local PGP Encryption Server cannot resolve external DNS names.
   
   Therefore, when it tries to resolve a name such as keys.example.org, it fails and cannot perform a key lookup on the remote host.

If a local firewall is blocking the PGP Encryption Server from connecting to remote hosts on LDAP port 389 then the firewall rules need changing in order to allow this.

If the Default Gateway cannot route traffic to remote hosts then the Default Gateway needs to be changed. This may require manual routes to be configured for local subnets.

If the PGP Encryption Server cannot resolve external DNS names then the DNS settings need to be changed. The Server needs to be able to resolve both internal and external DNS names.

It needs to resolve internal names so that, for example, it can communicate successfully with other cluster members. Both forward and reverse DNS lookups need to work correctly between cluster members.

For example, in a cluster that included the host sems1.example.net with an IP address of 10.10.10.10, running this command from another cluster member should return the IP address 10.10.10.10:

nslookup sems1.example.net

In addition, running this command should return the name sems1.example.net:
nslookup 10.10.10.10

It needs to also be able to resolve external names. For example, if a remote PGP Encryption Server had the public name keys.example.org, running this command should return its public IP address:

nslookup keys.example.org

The PGP Encryption Server can point to multiple DNS servers. However, only the first DNS server will be used unless it is unreachable. Therefore the first DNS server in the list needs to be able to resolve both internal and external names.

This means that the PGP Encryption Server will not work correctly if some DNS servers in its list can resolve only internal names and other DNS servers in its list can resolve only external names.