This article goes over the basics of downloading a "Managed" client or "Customized" client from Symantec Encryption Management Server.
The Symantec Encryption Management Server (SEMS/PGP Server) manages all of the Symantec Encryption Desktop (SED/PGP Desktop) clients that are deployed to the environment. You create PGP Desktop client installers with the features and settings that support your organization's security requirements and then deploy those client installers to your end users.
The PGP Server can allow you to create two client installer types: Auto Detect and Preset Policy--the former being the most widely used and recommended option.
The Auto-Detect Policy option means that when the user enrolls with the server, the policy is automatically applied. This is the best option to use if Directory Synchronization is being used to enroll clients.
If you are using a Load Balancer to route communications to the PGP server, enter the FQDN the Load Balancer will be using. For example, if you have two PGP Servers, one called "
pgp01.example.com" and the other "
pgp02.example.com", you'll want to use a name that will resolve to the Load Balancer and then Load Balancer will then redirect traffic to one of the two servers in question.
In one example, the Load Balancer FQDN could be named "
keys.example.com". So when you build the PGP client, enter this hostname and this will assign "
keys.example.com" for the installer package, this is called the "PGPSTAMP", which is the FQDN for the PGP Server. Post install, when the PGP client attempts to check in, it will attempt to resolve the PGPSTAMP value, or "
keys.example.com" FQDN, which will go to the Load Balancer.
At this point, you will need to consider how the TLS communications should behave.
PGPSTAMP is pointing to "
keys.example.com", the TLS certificate being used for the interface should also match "
keys.example.com", whether it is the PGP Server that presents the TLS certificate or the Load Balancer.
If you are using the "passthrough" method on the Load Balancer, meaning the Load Balancer will not be presenting any certificates for the TLS connection and is simply sending to one of the two PGP Servers, ensure the certificate that is being used matches the same FQDN used to create the client.
If the TLS certificate is created for "
keys.example.com", but the servers are called "pgp01" and "pgp02", then the PGP client is going to produce a certificate warning. To avoid this scenario, you can use a wildcard certificate so that regardless of the hostname of the PGP server, as long as the domain is the same, the certificate warning will not show. For example, the hostname "
pgp01.example.com" and "
pgp02.example.com" will not produce a certificate warning if a wildcard certificate for "
:*.example.com" was created.
Optionally, if a wildcard certificate is not possible, you can try adding SANS Alternative values for each PGP servers assigned.
If a wildcard certificate is not being used and SANS Alternative Values are not available, then Symantec recommends creating the certificate for "
keys.example.com" and assigning that certificate to the Load Balancer and have the Load Balancer renegotiate. All the PGP clients will be connecting with TLS via the Load Balancer, and the Load Balancer will renegotiate to the PGP servers. The PGP clients will not be aware of the TLS connection being made from the Load Balancer to the PGP servers if TLS renegotiation/TLS Termination is being done on the Load Balancer and should avoid any TLS pop ups.
Caution: If you are using an Internal CA, ensure the Root and Intermediate Certificates are uploaded and fully trusted into the Trusted Keys section on the SEMS. In some cases using an internal CA, you may need to specifically assign the server certificate to be trusted. In other words, some environments will not accept any certificates unless they were specifically added, even if they are signed by a trusted Internal CA so it's a good idea to test this thoroughly before deploying to the entire organization.
For more information on PGP and Load Balancers, see the following article:
156803 - Using DNS Round Robin and Load Balancers with Encryption Management Server
example.*.com. Customized client installations will not work without mail server binding.
Note: In the Mail Server Binding, you can type the name of a specific mail server you want bound to that Encryption Management Server.
Once the PGP client is installed on the machine, you can see which customized URL was used by going to the following location in the registry and make note of the "
PGPSTAMP" value shows:
In the above example, you can see which FQDN was used to create the client.
Tip: Use Preset Policy *only if* Directory Synchronization is not being used. Auto-Detect Policy is the recommended method for all client downloads.
Note: You can also select to Embed Policy into the installer. In this use case, there will never be a connection between the client and the Encryption Management Server. The client never receives any updated policy information from the Encryption Management management server, even if the policy is updated on the server side. This is available in Encryption Desktop for Windows only. See the following article for more information on this feature:
153203 - What is the Embed Policy Option for Symantec Encryption Desktop Configured Installations?
To download Symantec Endpoint Encryption, see the following article:
|Note: In the Mail Server Binding, you can type the name of a specific mail server you want bound to that Encryption Management Server.
You must have a mail server defined unless your users read mail directly from the Encryption Management Server via POP or IMAP.
If you are trying to download the client and running into issues with the operating system and complaining the installation package is not valid, this is normal behavior and expected.
The errors may be similar to the following:
"The signature of PGPDesktop.msi is corrupt or invalid"
"PGPDesktop.msi isn't commonly downloaded. Make sure you trust PGPDesktop.msi"
"Microsoft Defender SmartScreen couldn't verify if this file is safe because it isn't commonly downloaded"
"Microsoft Defender SmartScreen prevented an unrecognized app from starting"
When checking the Digital Certificate on the PGP installer to see if the certificate is valid, it may show as not valid:
The reason for all of the above messages is the file is being built from a "template" PGPDesktop.msi file. The template file "
PGPDesktop.msi" is digitally signed.
If you do not customize the PGPDesktop.msi, you can compare the certificates and they will all match.
When the template is customized by wrapping the custom PGP Server name into it, and some other items, such as Trusted Keys, it modifies the file slightly.
These are the only modifications made to this installer, but is completely safe to then deploy to your environment.
We have seen some issues after migrations where the PGP Desktop client does not download after checking the box to "Customize".
If you don't check the Customize box, the download works fine. For more details on this, see the following KB articles: