Access Denied to cryptographic module 'global.com_snc_platform_security_oauth_glideencrypter' for Certificate-Based OAuth AuthenticationDescriptionDetails 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 JWTGetting JWTProvider for jwtProviderSysId = <JWT Provider sys ID configured in the script include>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=KB1112530WARNING *** WARNING *** Access denied to crypto moduleWARNING *** WARNING *** string may not be encrypted: Input length must be multiple of 8 when decrypting with padded cipherSEVERE *** ERROR *** Error while generating JWT token.Cannot recover keySEVERE *** 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=<transaction_id> user_name=<the run as user> mid_server= source_table=sysauto_script source_record=<sysauto_script sys ID> system_id=<FQDN of the app node> method=POST log_level=All scheme=https hostname=login.microsoftonline.com path=/<tenant ID>/oauth2/v2.0/tokenOAuthProblemException{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 '<app ID>'. ...WARNING *** WARNING *** failed to get access token from remote oauth server.*** Script: OAuth authentication failed for <JWT Provider sys ID configured in the script include>Release or EnvironmentThis is not known to be related to a specific release or environment.CauseThe 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.ResolutionCreating 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 tableClick 'New' to create a new MAPChoose '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' recordEnsure 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.Additional InformationNote: 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. Related Articles and links: Configure an OAuth profile to use certificates for authentication with Microsoft Azure (and its child pages) Key Management Framework - Password2 - Access Denied