skip to main content
Security Guide > X.509 Certificates > Certificate Storage
Certificate Storage
When configuration (in the form of JSON) is provided by an application to the Engage Engine, the various certificates to be used may be passed directly in the certificate as PEM-encoded text. However, this certificate data often includes the private key with the certificate. Applications, or the platforms they execute on, may not always meet government or enterprise stringent data protection guidelines. To deal with this, Engage offers a set of certificate management APIs that secure certificates and private keys in an encrypted storage container known as a certificate store. This certificate store is typically physically implemented as an operating system file, which may be stored securely by the underlying operating system. That OS-provided secure storage notwithstanding, Engage encrypts this file following a sophisticated security algorithm where the encryption key (AES256-CBC) for the file is comprised of three components:
*An application-provided (binary) password/passphrase/PIN
*A 512-bit algorithmically-generated salt contained within the Engage Engine
*A 128-bit initialization vector embedded into the certificate store itself
Also, the initialization vector changes every time the file is modified by Engage, effectively creating a dynamic keying material baseline upon every store modification operation.
To aid in protecting against unauthorized certificate store modification, Engage embeds a SHA-256 digest in the certificate store and also validates each element in the store every time that store is opened. Therefore, for an adversary to obtain access to the content of the store - or to modify it in any way, they would have to know the application-defined passphrase, the algorithmically-generated Engage-provided salt, the IV inside the certificate store, and (finally) understand the method in which the encryption key is generated.
Each certificate (and its private key if applicable), is de-referenced with an application-provided identifier which is then used within the JSON configuration to "point" to the certificate. For example, JSON containing the actual PEM certificate could be represented as:
"security":{
"certificate":"-----BEGIN CERTIFICATE-----\nMIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G\n .... ",
"certificateKey":"-----BEGIN EC PARAMETERS-----\nBgUrgQQAIw==\n-----END EC PARAMETERS-----\n-----BEGIN EC PRIVATE KEY-----\nMIHbAgEBBEGXac ... "
}
Or, a certificate store can be used that contains a certificate (and private key) identified with an application-defined value, such as "PrimaryX509". In this case, the JSON would look as follows:
"security":{
"certificate":"@certstore://PrimaryX509",
"certificateKey":"@certstore://PrimaryX509"
}
In this case, Engage will extract the certificate and key for "PrimaryX509" from the active certificate store and insert it directly into its internal configuration without the certificate or key ever being exposed - even to the application itself.