ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

Key Cache with Symantec Encryption Management Server FAQ (Caching Keys for inbound email)

book

Article ID: 158748

calendar_today

Updated On:

Products

Encryption Management Server Gateway Email Encryption

Issue/Introduction

This article will go over some of the FAQs for Key Cache, or "Caching Keys" on Symantec Encryption Management Server (SEMS).

One of the core features of SEMS is that of being a keyserver.  Keys are managed by the SEMS for further use via key lookups/searches from various sources.  Having keys on the local SEMS speeds up encryption operations as there is no need to search for keys elsewhere.  One of the methods to benefit from this speed of using these keys is to cache keys on the "Inbound" mailflow.  If someone sends an SMIME email and SEMS processes it, the SMIME key is typically attached to the email and it is then cached on SEMS in its own Key Cache.  Keys are cached temporarily (configurable duration) so that further messages to these recipients can be encrypted, and the key lookup process will find the key quickly in the local key store and the overall process is faster. 

Resolution

The Key Cache on SEMS can be accessed by going to Keys, and then clicking on "Key Cache":

 

Question 1: Do keys in the Key Cache get purged periodically?
Answer: Yes, they are cleaned out after 500 Days by default.

 

For additional information, see the following article:

162609 - Symantec Encryption Management Server (SEMS) Key Cache purge routines differ depending on how keys are retrieved


Question 2: What is the Max Duration for the Key Cache on SEMS?

Answer: The lowest value keys can be cached is 1 hour and the maximum value configurable for this is 999 days.


Question 3: I have my server in the mailflow, but it's not caching keys--why?

Answer: In order for the keys to be cached, the email containing the key must be an "Inbound" message.  In other words, the SEMS does not harvest keys that are sent "Outbound" as typically all the keys for users sending outbound already exist as "Internal Users" on the SEMS.  Only Inbound emails will harvest these keys.


Question 4: I have an email that came from an external domain, why is it still not caching it?

Answer: Depending on how the proxies of SEMS are configured, the email from an external recipient may be interpreted by SEMS as an "Outbound" message.  If the Proxies are configured with an MTA that is the inbound and outbound connector into SEMS, then having two interfaces on the SEMS with different IP Addresses is recommended.  In this way, the messages for "Inbound" always go to the Inbound IP, and the messages destined for the external domains will always use the Outbound IP Address.


Question 5: Should I purge the Key Cache before the timeout value is reached?

Answer: If you know a single key has been updated, then purging of all keys may be overkill.  Instead, delete the single key in question from the Key Cache, and then re-harvesting will need to take place.


Question 6: Immediately after I created a cluster member, the cached keys on the host server are removed and are not replicated.

Answer: The timeout value for cached keys has expired.  After one or more servers are joined to the host server during the creation of a server cluster, one of the services checks the cached key timeout setting as it restarts. If the current date minus the keys’ create date exceeds the defined timeout value, the service flushes the key cache. You will have to repopulate it.

This key-cache expiration issue is corrected using the command line of the Symantec Encryption Management Server to edit the key-cache timeout field in the prefs.xml file.

The prefs.xml file is located in the /etc/ovid directory.

In the prefs.xml file, the <key-lookup-cache-timeout></key-lookup-cache-timeout> field needs to be set to something greater than the default 24 hours (1440 minutes).

Warning: Accessing the Symantec Encryption Management Server command line for read-only purposes (such as to query the database, or to view settings, services, logs, processes, disk space, and so on) is supported. However, performing configuration modifications or customizations using the command line may void your Symantec Support agreement unless the following procedures are followed.

Changes made to the Symantec Encryption Management Server using the command line must be:

  • Authorized in writing by Symantec Technical Support or published as an approved and documented process on the Symantec Knowledge Base.
  • Implemented by a Symantec Partner, reseller or Symantec Technical Support.
  • Summarized and documented in a text file in /var/lib/ovid/ on the Symantec Encryption Management Server itself.
     

Changes made through the command line may not persist through reboots and may be incompatible with future releases. Symantec Technical Support may also require reverting any custom configurations on the Symantec Encryption Management Server back to a default state when they troubleshoot new issues.

For assistance on changing the prefs.xml file, submit a request to Technical Support.

Attachments