CT-VL Key Cache
The CT-VL key cache manages cryptographic keys with a default expiration time of 600 seconds (10 minutes). The actual expiration depends on whether the key is actively used in a session or not. For performance optimization, CT-VL implements two distinct local caches:
Key cache for tokenization operations
Key cache for cryptographic operations
Since CT-VL uses NGINX as both a web server and reverse proxy, the caching mechanisms differ between these two types of operations.
Key Cache for Tokenization
Key cache for tokenization operation is based on NGINX. The key cache in NGINX is maintained per worker process. The number of worker processes corresponds to the number of CPU cores allocated to CT-VL at the time of installation.
Each worker process maintains its own independent key cache with its own start time and expiration timeline.
When a key is first loaded into a worker’s cache, it remains valid until the configured expiration time is reached (default is 10 minutes). The cache expiration time is configurable using the
jwt_expire_timeparameter. See Modifying Key Cache Timing.
NGINX efficiently distributes tokenization requests across worker processes using availability and scheduling algorithms. As a result:
Each worker can populate its cache independently, optimizing cache management timing.
Cache expiration times may vary slightly per worker, ensuring fresh key availability.
Note
Intermittent tokenization failures are still possible because there is no guarantee that NGINX worker processes will have successfully cached the required keys before a disruption to the CipherTrust Manager connection occurs.
Key Cache for Cryptographic Operations
Key cache for cryptographic operations is independent of NGINX. When a cryptographic operation request is made, key is added to the local cache and it remains cached until its expiration time.
Note
If a key ID has the
:refreshattribute appended to it, it will clear both local and crypto caches. But calling it on every request would degrade the performance, although integrity is preserved.To find out the remaining expiration time, look at the
deactivation_dateattribute and figure figure how much time is available until the next rotation.
The key cache expiration time is configurable using the jwt_expire_time parameter. See Modifying Key Cache Timing.
Modifying Key Cache Timing
CT-VL key cache is in-memory cache designed for performance optimization. It is not intended to replace the availability of the CipherTrust Manager for CT-VL.
If you experience tokenization failures when the CipherTrust Manager connection is disrupted for more than 10 minutes, it is recommended to adjust the CT-VL key cache timeout value.
Note
CipherTrust Manager availability: It is strongly recommended that at least one CipherTrust Manager always be available to the CT-VL cluster. Tokenization success cannot be guaranteed based on the key cache alone, even with a longer timeout.
Key Cache Timeout Characteristics
The CT-VL key cache timeout is same as JWT timeout value.
The default timeout is 10 minutes.
The key cache is in-memory; it does not persist across service restarts or reboots.
Modifying Key Cache Timeout
To change the key cache timeout value:
Change the JWT timeout setting using CLI command:
main > auth jwt --expire XXHere, XX is the expiration time in minutes, ranging from 10 to 60480 minutes (up to 6 weeks).
After changing the timeout setting, perform VTS service restart on each node:
main > vts service --restart
Note
The JWT timeout setting must be configured individually on each CT-VL node in the cluster via the CLI. The setting does not replicate across the cluster.
Mismatched timeouts across nodes can lead to intermittent tokenization failures, if requests are load balanced.
Automatic vs Manual Key Rotation Process
Automatic Key Rotation
A way to ensure that the key isn't expired is to do a GET on the key, and look at the deactivation_date attribute value. When you are close to expiration time, append the :refresh attribute until you see a different date in the future.
Manual Key Rotation
The creation_date can be used to calculate a deactivation date if you have a manual rotation process, and you know how long the key will last. As it is manual, you may want to do refreshes for a grater period of time until you see a new creation date.
Once out of the rotation risk zone, drop the :refresh, and you will get better throughput at these times.
There are no performance numbers for key operations, since the original assumption is that keys and their states do not change that often. CipherTrust Cryptographic operations do perform a key fetch internally if not cached.
