Access Denied to cryptographic module 'global.com_snc_platform_security_oauth_glideencrypter' for Certificate-Based OAuth Authentication - Support and Troubleshooting

Access Denied to cryptographic module 'global.com_snc_platform_security_oauth_glideencrypter' for Certificate-Based OAuth Authentication Issue Details Users may have been setting up a new Email Account with type Graph (Receive) and decided to use certificates to retrieve their OAuth access tokens as documented in Configure an OAuth profile to use certificates for authentication with Microsoft Azure .

After following the steps in the above documentation, it works as expected by manually fetching an access token by clicking the related link on the Email Account form. Thereafter, the token will expire and the out-of-the-box 'Refresh Email Access Token' will fail to renew it without intervention.

Note: More generally, this may also occur when a JWT is being generated within a user-created script on the instance. This article will focus on the above scenario but the resolution may still be helpful. Before proceeding, please review KB1112530 to ensure that there is not a Module Access Policy automatically generated.

Symptoms This stack trace can be found in System Logs with each Email Reader execution:

Unable to process messages: com.glide.notification.inbound.GraphEmailReaderException: Access Token is not available: com.glide.notification.inbound.GraphEmailReader.getToken(GraphEmailReader.java:257) com.glide.notification.inbound.GraphEmailReader.getMessageIds(GraphEmailReader.java:235) com.glide.notification.inbound.GraphEmailReader.processMessages(GraphEmailReader.java:155) com.glide.notification.inbound.EmailReader.process(EmailReader.java:178) com.glide.email_accounts.EmailReaderJob.readEmailAccountsSerially(EmailReaderJob.java:118) com.glide.email_accounts.EmailReaderJob.execute(EmailReaderJob.java:93) com.glide.schedule.JobExecutor.lambda$executeJob$1(JobExecutor.java:194) com.glide.schedule.JobExecutor.executeJob(JobExecutor.java:197) com.glide.schedule.JobExecutor.execute(JobExecutor.java:177) com.glide.schedule.JobExecutor.execute(JobExecutor.java:167) com.glide.schedule_v2.SchedulerWorkerThread.executeJob(SchedulerWorkerThread.java:577) com.glide.schedule_v2.SchedulerWorkerThread.lambda$process$2(SchedulerWorkerThread.java:396) com.glide.worker.TransactionalWorkerThread.executeInTransaction(TransactionalWorkerThread.java:35) com.glide.schedule_v2.SchedulerWorkerThread.process(SchedulerWorkerThread.java:396) com.glide.schedule_v2.SchedulerWorkerThread.run(SchedulerWorkerThread.java:172)

The logs for the 'Refresh Email Access Token' transaction itself :

Started to generate JWT

Getting JWTProvider for jwtProviderSysId =

SEVERE *** ERROR *** Access Denied to cryptographic module 'global.com_snc_platform_security_oauth_glideencrypter' For guidance on this issue, please have your Security Admin refer to KB: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1112530

WARNING *** WARNING *** Access denied to crypto module

WARNING *** WARNING *** string may not be encrypted: Input length must be multiple of 8 when decrypting with padded cipher

SEVERE *** ERROR *** Error while generating JWT token.Cannot recover key

SEVERE *** ERROR *** *** Script: JWT Token is not valid. Please make sure standard claims are valid.

OUTBOUND_HTTP: protocol=HTTP/1.1 response_status=401 response_time=335 request_length=142 response_length=623 app_scope=global session_id=glide.scheduler.worker.6 transaction_name="Refresh Email Access Token - system" transaction_id= user_name= mid_server= source_table=sysauto_script source_record= system_id= method=POST log_level=All scheme=https hostname=login.microsoftonline.com path=/ /oauth2/v2.0/token

OAuthProblemException{error='invalid_client', description='AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app ' '. ...

WARNING *** WARNING *** failed to get access token from remote oauth server.

*** Script: OAuth authentication failed for Release This is not known to be related to a specific release or environment.

Cause The root cause of the problem is indeed that the script is being denied access to the KMF module, exactly as indicated in the transaction logs. Generally, script includes and applications will install with a pre-configured module access policy (MAP) as required. Alternatively, MAPs are automatically generated with a 'Result' in accordance with the corresponding default policy upon attempted encryption/decryption.

In this scenario, a module access policy (MAP) was not automatically generated as described in KB1112530 . A granular MAP had to be manually created for the caller, which is the 'Refresh Email Access Token' scheduled script execution [sysauto_script] record in this case.

Resolution Creating the below module access policy is a security decision. The reader should understand the implications of creating this policy and how those will impact their security before implementing it.

Navigate to the sys_kmf_crypto_caller_policy table Click 'New' to create a new MAP Choose 'Type' => 'Script' Choose 'Script Table' => 'Scheduled Script Execution [sysauto_script]' Use the lookup button to the right of 'Target Script' to select the 'Refresh Email Access Token' record Ensure that 'Active' = True and that the 'Result' = Track. Subsequent runs of the 'Refresh Email Access Token' job should now successfully generate the JWT and result in a 200 response and token from the Graph API.

Related Links Note: Creating a MAP even more specific and granular for the script include created by duplicating GraphCertificateOAuthTemplate was not sufficient. Unfortunately, access continued to be denied until a MAP was created for the calling script.