Unable to decrypt Key Store password after upgrading to San Diego - Known Error

Unable to decrypt Key Store password after upgrading to San Diego Description The password2 submodule ("com_glide_certificates_glideencrypter") that protects data within tables related to sys_certificate provided out-of-the-box is missing module access policies.

Because of that, any attempt to decrypt the key store password is refused (which is the default behavior when no policy is defined).

Steps to Reproduce

1. Navigate to sys_certificate. 2. Open any KeyStore record. 3. Use "Show XML" to access the ciphertext (contained in key_store_password ). 4. Via background script (or Script Include, or ...), use GlideEncrypter to decrypt the KMF-encrypted value in 3.

Expected: Value is decrypted successfully (Rome behavior) Actual: Access Denied to cryptographic module 'global.com_glide_certificates_glideencrypter'

Workaround IMPORTANT: The following workaround is provided for the 'com_glide_certificates_glideencrypter' crypto module ONLY . Applying these steps for a different crypto module greatly reduces the security of the instance , and should never be attempted.

1. Navigate to the 'com_glide_certificates_glideencrypter' module and set the "Default module access policy value" to "Track" : https:// .service-now.com/sys_kmf_crypto_module.do?sys_id=8994cbe3ff23201022f462aa453bf13d 2. Delete the auto-generated Reject MAPs for the specific module "com_glide_certificates_glideencrypter" : https:// .service-now.com/sys_kmf_crypto_caller_policy_list.do?sysparm_query=crypto_module%3D8994cbe3ff23201022f462aa453bf13d%5Eactive%3Dtrue%5Eresult%3Dreject

NOTE: This can only be done as a sn_kmf.cryptographic_manager. Customers can assign this role by elevating to security_admin and following: https://docs.servicenow.com/bundle/quebec-platform-administration/page/administer/key-management-framework/reference/kmf-roles.html . Alternatively, this change can be executed by ServiceNow support as MAINT user.

NOTE 2: A previous version of this article recommended to deactivate the auto-generated MAPs instead of deleting them. Unfortunately, doing so may cause a second issue, documented in PRB1581408, that mostly occurs for cloned instances.