File Share Encryption Command Line cannot find keys on Encryption Management Server

Products

File Share Encryption File Share Encryption Powered by PGP Technology Encryption Management Server Encryption Management Server Powered by PGP Technology

Issue/Introduction

The File Share Encryption Command Line utility, pgpnetshare.exe, can search for keys on Symantec Encryption Management Server. There are two switches that enable you to do this:

pgpnetshare --remote
pgpnetshare --universal-server

For Encryption Desktop clients that are managed by Encryption Management Server, the --remote switch is preferred. By default, it causes pgpnetshare.exe to search on the keyservers that are configured in Encryption Desktop. By default, these are:

The PGP Global Directory - keyserver.pgp.com. This search is done using LDAP port 389.
The Encryption Management Server that manages the client. For example, keys.example.com. This search is done using the PGP Universal Services Protocol (USP) port 443.

The pgpnetshare --universal-server switch allows you to specify a specific Encryption Management Server that it searches using the Universal Services Protocol. Note that the --universal-server switch requires that the --auth-username and --auth-passphrase switches are used if the --reencrypt, --reencrypt-full, reencrypt-delta or --reencrypt-clone switches are being used. The --auth-username and --auth-passphrase switches are not required if the --encrypt switch is being used.

The --remote and --universal-server switches usually do not work. In the example below, 0x052CE77A is the local user's key and 0xFFFDC3D6 is a group key on Encryption Management Server:

pgpnetshare --encrypt Z:\share\FileShare --recipient-owner 0x052CE77A --signer 0x052CE77A --recipient 0xFFFDC3D6 --remote Error: Could not resolve key [0xFFFDC3D6] [-11984].

The error message is the same with the --universal-server switch:

pgpnetshare --encrypt Z:\share\FileShare --recipient-owner 0x052CE77A --signer 0x052CE77A --recipient 0xFFFDC3D6 --universal-server keys.example.net Error: Could not resolve key [0xFFFDC3D6] [-11984].

Environment

Symantec File Share Encryption 10.4.2 and above.

Cause

The pgpnetshare.exe application requires that Encryption Desktop contains the hash value of the Encryption Management Server TLS certificate when searching using Universal Services Protocol.

Resolution

There are three workarounds for this issue:

Capture the certificate hash value of the Encryption Management Server by searching using PGP Universal Services Protocol using a different FQDN.
Search the Encryption Management Server using LDAP or LDAPS and the --remote switch. However, please note that this is unlikely to be possible in most corporate environments because the LDAP and LDAPS protocols will be blocked by a firewall. Note too that the --universal-server switch does not work with LDAP or LDAPS.
Do not use the --remote or --universal-server switch. Instead, import all applicable public keys into the local keyring.

1. Search using USP with certificate hash

This workaround requires that the IP address on the interface of Encryption Management Server that runs the USP service is reachable using an alternative FQDN.

For example, this workaround is possible if Encryption Management Server has a default FQDN of keys.example.com but the FQDN alt-keys.example.com resolves to the same IP address. If no alternative FQDN is available, a name can be added to the C:\Windows\System32\drivers\etc\hosts file though this requires local administrator rights.

Do the following to add the alternative USP keyserver:

Open Encryption Desktop.
Click on the Tools menu.
Click on Edit Keyservers to display the current list:
Click the Add button.
Specify the Type as PGP Universal Services Protocol.
Specify the Address as alt-keys.example.com where alt-keys.example.com is the alternative FQDN of Encryption Management Server and save the new keyserver entry:

To capture the certificate hash value, search for a key on the new keyserver using Encryption Desktop:

Open Encryption Desktop.
Click on the Tools menu.
Click on Search for Keys.
From the Search dropdown list select the name of the new keyserver. For example, alt-keys.example.com.
Click the Search button.
An alert window appears stating that the TLS certificate does not match the keyserver name.
Click the button Always Allow for This Site:

The pgpnetshare --remote switch will then search for keys on the new USP keyserver automatically.

The pgpnetshare --universal-server switch will then be able to search for keys on the new USP keyserver. For example, pgpnetshare --universal-server alt-keys.example.com.

2. Search using LDAP or LDAPS

To add a new LDAP(S) keyserver entry:

Open Encryption Desktop.
Click on the Tools menu.
Click on Edit Keyservers to display the current list.
Click the Add button.
Specify the Type as either:
- PGP Keyserver LDAP - searches using LDAP port 389.
- PGP Keyserver LDAPS - searches using secure LDAP port 636.
Specify the Address as keys.example.com where keys.example.com is the FQDN of Encryption Management Server and save the new keyserver entry:

The pgpnetshare --remote switch will then be able to search for keys on the new LDAP(S) keyserver automatically.

The pgpnetshare --universal-server switch will not be able to search for keys on the new LDAP(S) keyserver because this switch uses only the USP protocol.

3. Import the applicable keys into the local keyring

From the Encryption Management Server administration console, export all the public keys that you wish to encrypt to and import them into the Encryption Desktop keyring. After doing this, there is no need to use the --remote or --universal-server switches.

Broadcom is committed to product quality and satisfied customers. This issue is currently being considered by Broadcom to be addressed in a forthcoming version or Maintenance Pack of the product. Please be sure to refer back to this article periodically as any changes to the status of the issue will be reflected here.

Additional Information

Jira: EPG-22090, EPG-22042