The Symantec Encryption Management Server (PGP Server) Verified Directory (VKD) service allows internal or external users to upload their public keys using a web interface.
It also allows users running Symantec Encryption Desktop (PGP Desktop) or PGP Command Line to upload public keys to Encryption Management 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 Encryption Management 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.
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, keysvkd.example.com 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.
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.
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 "keysvkd.example.com" in the example.
The IP Address we will use for the Verified Directory service is 192.168.1.109.
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:
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 "keys.example.com" and IP address is 192.168.1.103, so we will need to create a new certificate for the keysvkd.example.com 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:
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:
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 Encryption Management 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.