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:
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 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].
Symantec File Share Encryption 10.4.2 and above.
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.
There are three workarounds for this issue:
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:
To capture the certificate hash value, search for a key on the new keyserver using Encryption Desktop:
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.
To add a new LDAP(S) 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.
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.
Jira: EPG-22090, EPG-22042