Configuring the PGP Encryption Server Verified Directory service (Symantec Encryption Management Server)
search cancel

Configuring the PGP Encryption Server Verified Directory service (Symantec Encryption Management Server)


Article ID: 180146


Updated On:


Encryption Management Server Gateway Email Encryption PGP Command Line Desktop Email Encryption File Share Encryption Drive Encryption Endpoint Encryption PGP Key Management Server PGP Key Mgmt Client Access and CLI API PGP SDK PGP Encryption Suite


The PGP Encryption Server (Symantec Encryption Management Server) Verified Directory (VKD - Verified Key Directory) service allows internal or external users to upload their public keys using a web interface.

If you trust the Verified Directory 

It also allows users running PGP Encryption Desktop (Symantec Encryption Desktop) or PGP Command Line to upload public keys to the PGP Encryption Server. However, this is only available over LDAP or LDAPS and it also requires the Keyserver service to be enabled.

The Verified Directory service is disabled by default.

Depending on the Vetting Method that is configured, Verified Directory sends verification messages to the email addresses of the keys that are submitted to it. If the key owner responds to the verification message with permission to add the key, then the key is added to the directory.

Clearly, if an internal user submits a third party's public key to Verified Directory then the email Vetting Method is not appropriate because the third party would receive verification emails.

Published user keys are signed by another key. Keys submitted by internal users are signed by the PGP Encryption Server Organization Key. Keys submitted by external users are signed by the Verified Directory Key. Prior to enabling Verified Directory, you must upload a Verified Directory key by navigating to Keys / Organization Keys and clicking on the button to upload a Verified Directory Key. This key pair should be created on a standalone system running PGP Command Line or Encryption Desktop.

The Verified Directory web interface allows users to search the directory for the public keys of persons to whom they want to send secured messages.

Once a key that has been uploaded using Verified Directory is published, it is available for use in encryption in the same way as the keys of External Users. However, unlike External User keys, Verified Directory keys are not replicated to other cluster members.



Section 1 of 5: Enabling the Verified Directory service

  1. On the Services/Verified Directory card, click the Enable button to enable the service.

  2. To disable the PGP Verified Directory service, click the Disable button on the Verified Directory card.

Important Note about TLS and VKD: Before you deploy your PGP server to start hosting your Verified Directory host, it is recommended to obtain a TLS certificate for the host signed by a trusted Certificate Authority, such as Digicert so that all external clients will trust the connection.

The PGP Server can be configured with an additional NIC and IP address to which you can assign a separate FQDN for the service.  For example, could be the hostname to configured for DNS and the TLS Certificate and then subsequently, assign that hostname to the service.

Assigning TLS will ensure seamless trust for all external clients as every website on the internet is required to be HTTPS, whether or not the data provided is private or public. 

HTTP Only should be used only for testing or labs only, but production servers should use TLS/SSL (HTTPS).

Important Note about VKD Signing Keys: Before you can properly use Verified Directory, you need a VKD Signing key.  Ensure this key does not have an expiration date for the near future as this will cause keys uploaded to the VKD to be removed.  We recommend choosing an expiration date a few years in advanced so that you never have to worry about this. 

Section 2 of 5: Configuring Verified Directory

  1. On the Services/Verified Directory card, click the Edit button.

    The Edit Verified Directory screen appears.

  2. The Interface tab is displayed by default.

  3. In the Public URL field, enter the PGP Verified Directory network name. Directory users access the PGP Verified Directory using this URL. The default URL is the hostname of the server prefixed by http://. If you wish to use a secure connection, change the prefix to https://.  You may want to change the URL, depending on your network configuration. 

  4. In the Interface field, select the appropriate network interface for Verified Directory from the drop-down list. Note that if you use HTTPS then a TLS certificate that matches the URL will need to be assigned to the interface.

  5. In the Port field, enter a port number for Verified Directory. The default is port 80 but if you are using https then change this to port 443. You can also use a custom port.

  6. Enable the SSL option if you are using a secure connection.

  7. Click the Options tab to specify key and user interaction settings.

  8. Establish key submission criteria for internal users:

    Allow Submission. When checked, users can submit their public keys to Verified Directory. You can choose whether Internal Users or Verified Directory Users can submit their keys. An Internal User is one where the domain part of the email address of a submitted key is listed under Consumers / Managed Domains in the management console. There are very limited circumstances whereby Internal Users will need to submit keys to Verified Directory and by default, Internal Users are not allowed to submit keys.

    Vetting Method. This determines how submitted keys are posted to Verified Directory. The choices are Implicit, Manual or Email. The Implicit option means that any key that is uploaded to Verified Directory is added automatically. Manual means that the PGP Encryption Server administrator must manually approve or reject all submitted keys. Email means an email message will be sent to the primary email address of the key and must be responded to.

  9. In the Re-email Timeout field, enter a timeout value for resending email. The default is 24 hours. If for some reason a user's key is submitted multiple times, the timeout value specifies how often the user will receive the vetting email in response. The default of 24 hours means that users will only receive the email once every 24 hours.

  10. In the Email Token Timeout field, enter the timeout value for the expiration of the email token. The default is 336 hours (14 days).

  11. In the Signature Expiration field, enter the expiration time for the signature of the Organization Key or Verified Directory Key signature. The default is 6 months.

    When the signature expiration time period is reached, the user's key will automatically be re-verified using the selected vetting method.

  12. In the Max Search Results field, enter the maximum number of results users receive for a web-based search. The default number of results returned for
    web-based searches is 25.




Section 3 of 5: Allow SMIME Certificates to be uploaded via the Verified Directory web portal

The PGP Server has always allowed the upload of PGP keys to the portal.  Starting with PGP Server 10.5.1, there is new functionality to allow the upload of SMIME Certificates to the portal.

To be able to do this, there is a preference that needs to be enabled (disabled by default).

To do this, you would modify the prefs.xml making the allow-smime-cert-import parameter "true".

There is no need to restart services.

If you would like assistance making this change, please reach out to Symantec Encryption Support and we can assist in doing this.


Section 4 of 5: Configuring the Verified Directory Service on a separate network interface with TLS

TLS is now the de facto standard for all websites published on the internet.  Verified Directory is technically a website that can be used to upload PGP Keys or SMIME certificates.

Given that the PGP Server is already running on TLS, enabling TLS for an additional service such as Verified Directory will require an additional interface that you can assign a new certificate to.

Step 1. Pick out a new Hostname and IP Address for the Verified Directory Service
First, you will want to determine the hostname and IP address you would like to use for the Verified Directory service assignment.  In this scenario, we have decided to use the host "" in the example.  
The IP Address we will use for the Verified Directory service is

Step 2. Add another NIC to the PGP Server for new hostname and IP address assignment
Once you know which host and IP you will use to assign to the interface, you can then add this to your PGP server's hardware.

To be able to do this, if you are running in VMWare, you can add one more Network Adaptor in the VMWare settings and reboot the server.  Once you have rebooted the server, you can then use the additional NIC to assign the new IP address and hostname. Once that is done, you can then save the configuration and will prepare you for the next steps. 

Doing these "Save" operations will restart network services, so it's best to perform these operations at a time when you can take a few minutes to restart (it doesn't take more than a few minutes, and rebooting the server usually happens within five minutes or so.

As you can see in this example, "Interface 2" is available and we simply type the the IP address, and subnet mask for this and once done, you click "Save":

Once you have saved and the network service has been restarted, then you can assign this to the Verified Directory service (Once you do, you'll see "Attached Services: VKD" appear as shown in the screenshot above.

Next, go to the Verified Directory Service and click "Edit..."

Validate the proper Interface is assigned with IP and make sure you check the box "SSL" when you edit the options:

Click Save.

Step 3. Create a CSR for your new Certificate for the new Hostname for Verified Directory

Once you have a new NIC on the PGP Server and have assigned the new hostname and IP address to it, you will be ready to get a new certificate for Verified Directory as the hostname will be publicly accessible.

In this example, the main hostname of the PGP Server is "" and IP address is, so we will need to create a new certificate for the host as you cannot have two certificates for the same hostname on the same port.  For this test, we will use a "Self-Signed Certificate". 

Important Note on Self-Signed Certificates: Using a Self-Signed certificate in a production environment is not typically acceptable as there is no "trust" established, so we recommend getting a certificate from a Trusted Certificate Authority, such as Digicert.  Self-Signed certs are made available for testing purposes directly on the PGP Server, but using a trusted authority is highly recommended when you are ready to make this hostname available publicly.  If the server will be publicly available, it is basically required to get a cert from a CA.

Once you have your DNS configured and valid host is available publicly, you can request your certificate from the PGP Server.  For more information on generating a Certificate Signing Request, see the following article:

158133 - Create a Certificate Signing Request and Add SSL Certificate to Symantec PGP Encryption Server (PGP Server)

Step 4 - Assign the certificate to Interface 2

Once you have your Certificate Request completed, you can now assign the new Interface 2 you have added and click "Save":

Step 5: Validate the new Website for Verified Directory and ensure the Certificate looks good

Once this has all been done, when you go to the Verified Directory URL you have chosen, you should not receive a certificate warning and looking at the certificate, it should look like the one you assigned to the network interface:



Section 5 of 5: Clustering and Verified Directory

Internal user keys submitted through Verified Directory are replicated throughout a cluster. However, submitted external user keys are not replicated.

To make sure these keys are replicated across your cluster, you can manually add Verified Directory user keys to the external user list. Export the Verified Directory user keys, then re-import them into the External Users page.

You can also make sure external user Verified Directory keys are always available by building an PGP Encryption Server to function as a dedicated Verified Directory server. Make sure that you add the Verified Directory server to your list of searchable key servers for any mail policy rule that requires it.

Additional Information

EPG-27231, IMSFR-993