Start a conversation

Fixing GAM “Incoming request is rejected due to security reasons” After a Salesforce Sandbox Refresh (Media Fulfillment v36.0)

Overview

When connecting a Salesforce sandbox to GAM, the connection test (for example, “Check Login” from an Ad Server configuration record) can fail with the error Incoming request is rejected due to security reasons. Contact your system administrator.

In Media Fulfillment, this commonly occurs after a sandbox refresh and re-provisioning when the RSA public key stored on the CloudSense provisioning/integration side does not exactly match the public key embedded in the Salesforce sandbox certificate. Even a single-character Base64 mismatch produces a different decoded key and causes cryptographic verification to fail, resulting in the security rejection.

Solution

Applies to

  • Salesforce: Full Sandbox
  • CloudSense package: Media Fulfillment v36.0
  • Scenario: Often seen after a sandbox refresh and a follow-up request to re-provision the sandbox integration to GAM

Error message

Incoming request is rejected due to security reasons. Contact your system administrator.

Symptoms

  • GAM connection fails from the sandbox during a connection test (commonly “Check Login” from an Ad Server configuration record or similar setup UI).
  • The failure often starts shortly after:
    • A Salesforce sandbox refresh, and/or
    • A re-provision request that was reported as completed

Cause

The RSA public key stored on the CloudSense provisioning/integration side for the sandbox org does not match the RSA public key embedded in the Salesforce sandbox certificate currently used for the integration.

Because the integration relies on certificate-based cryptography, any mismatch (even one Base64 character) results in a different decoded key and breaks signature/verification. The platform then rejects the incoming request “for security reasons”.

This mismatch is commonly caused by a copy/paste or transcription error during provisioning, or by a stale key after a sandbox refresh/certificate regeneration.

How to diagnose (what to check)

  1. Identify the certificate currently used in the Salesforce sandbox

    • In Salesforce, navigate to Setup → Certificate and Key Management.
    • Locate the self-signed certificate used for the integration (often recreated during refresh or reconfiguration).
    • Record certificate details for traceability, such as:
      • Subject (example: CN=SelfSignedCert_<env>_<date>, OU=<sandbox_org_id> ...)
      • Valid-from / valid-to dates
      • Fingerprints (SHA-256 / SHA-1) if available in your process
  2. Extract/confirm the certificate’s public key

    • Export/download the certificate from Salesforce (as permitted by your security process).
    • Extract the public key from the certificate (example command pattern):
  3. openssl x509 -in <certificate_file>.crt -pubkey -noout
    • Keep the extracted PEM output verbatim (do not edit whitespace/characters).
  4. Confirm the CloudSense/provisioned public key matches exactly

    • Provide the extracted public key (or certificate + fingerprints) to the Provisioning/Security Operations team so they can compare it to what is stored for your sandbox integration.
    • If the stored value differs by any character (for example, a one-character Base64 variation), it must be corrected to an exact match.

Resolution (step-by-step)

  1. Regenerate or confirm the sandbox certificate/public key (if required)

    • If your process requires a fresh certificate after refresh, generate/confirm the correct self-signed certificate in the sandbox.
  2. Submit a provisioning update to correct the stored RSA public key

    • Request that the provisioning/integration configuration store the exact RSA public key corresponding to the current Salesforce sandbox certificate.
    • Include the following to avoid delays:
      • Sandbox Org ID: <sandbox_org_id>
      • Certificate subject/name: <certificate_name>
      • Certificate fingerprints: <sha256_fingerprint> (and/or <sha1_fingerprint>)
      • Extracted public key PEM block (verbatim), or the exported certificate file (per your security policy)
  3. Wait for provisioning confirmation, then re-test

    • Once the key is confirmed as updated on the provisioning side, proceed to verification.

Verification

  1. In the sandbox, re-run the same action that previously failed (commonly “Check Login” from the Ad Server configuration record).
  2. Confirm the error no longer appears and the connection succeeds.
  3. If it still fails, confirm:
    • The sandbox is still using the same certificate/public key that was provided for the provisioning update (a new cert regeneration can change it).
    • The provided/stored public key was not altered (no missing characters, substitutions, or modified line breaks).

Frequently Asked Questions

1. How can I tell if this is the same issue?
If the GAM connection test fails with Incoming request is rejected due to security reasons. Contact your system administrator. shortly after a sandbox refresh or re-provisioning, and other settings look unchanged, a public-key mismatch between the Salesforce certificate and the provisioned key is a primary suspect.
2. Does a one-character difference in the public key really matter?
Yes. A one-character Base64 difference produces a different decoded key, which breaks cryptographic verification and can trigger a security rejection during authentication.
3. What information should I provide to provisioning to fix this quickly?
Provide <sandbox_org_id>, the certificate name/subject currently used in Salesforce, certificate fingerprints (SHA-256 preferred), and the exact extracted public key (or the exported certificate) so the stored key can be updated to an exact match.
4. What should I test after provisioning updates the key?
Re-run the same sandbox action that failed before (commonly “Check Login” on the Ad Server configuration record) and confirm the error no longer appears and the connection succeeds.
5. The error persists after provisioning says it’s updated. What next?
Verify the Salesforce sandbox is still using the same certificate/public key that was sent to provisioning (a certificate regeneration or refresh can change it). If the certificate changed, export/extract the updated public key and request another provisioning update using the new certificate details.
Choose files or drag and drop files
Was this article helpful?
Yes
No
  1. Matej Storga

  2. Posted
  3. Updated

Comments