Gigya Job Openings

Certificate Provisioning

Skip to end of metadata
Go to start of metadata


Unable to render {include} The included page could not be found.

SSL Certificate Provisioning is ONLY available for the US/EU/AU data centers.

Unable to render {include} The included page could not be found.

Internal Note

Certificate Provisioning will fail ("Identity already exists") if a another certificate exists anywhere in an Amazon Distribution (S3 or CloudFront) that uses either the same prefixed domain name or a wild-card that includes the prefixed domain of the domain that is attempting to be processed.

i.e., Attempting to register a certificate for the domain will fail if any of the following are true:

  • There is already a certificate hosted in any Amazon Distribution for
  • There is already a certificate hosted in any Amazon Distribution for *

In this scenario, preferably, the client should try to solve the issue on their own.
if not, then we ask for Amazon's help to free the domain with the following steps:

  1. For each of the prefixed domains, ask the client to add a TXT record (DNS) from the prefixed domain (i.e to .
  2. Reach out to IT and request to open a ticket to Amazon about moving ownership of that CNAME to the above distribution.
  3. Once the CNAME ownership moves to the above distribution - we will delete it and free the domain.
  4. Inform the client they can re-try the certificate provisioning process.

Unable to render {include} The included page could not be found.

Currently, there are a few different scenarios where difficulties may arise using Gigya products, notably within an SSO Group, due to newer browsers not allowing 3rd Party Cookies. This document outlines how to configure an API Domain Prefix via the Gigya Console so that API calls to Gigya resources will no longer be considered as 3rd Party.

For this solution to work effectively, every site connected to the API Key needs to use a Domain Prefix with an SSL Certificate connected to it. Whenever a new site or subdomain is added to the API key's list of Trusted Site URLs  on the Site Settings page of the Gigya Console, this certificate must be re-generated and domain ownership re-verified for all subdomains.


Unable to render {include} The included page could not be found.


Important First Steps

A few things need to be completed prior to creating a Domain Prefix in the Gigya Console.

  1. Ensure that all currently used subdomains are listed in the Trusted Site URLs section of the Site (API Key) the certificate will be created on.
  2. Determine the Prefix they want to use for all of the subdomains defined in step 1, above, e.g., if thee subdomains are, and; you will need to know the prefix they wish to use, i.e., <prefix>, <prefix>, and <prefix>
  3. Create CNAME records for all of the new proxy URLs using the agreed upon prefix, pointing to the sslproxy that is located on the Generate New Certificate page within the Gigya Console and will resemble <siteID> This must be completed prior to continuing.

    Your Site ID can be located next to the Site's name in the main page of the Gigya Console.


Certificate Provisioning In The Gigya Console

First, ensure you are logged into the Gigya console.

Navigate to the Site you wish to create or modify the certificate for.

Make sure that the list of URIs within the site's Trusted Site URLs are accurate and up to date.

Proceed to the Certificate Provisioning page of the Gigya Console to create a new, or modify an existing, certificate.


Generate A Certificate

Click Generate New Certificate. This will open the Generate New Certificate screen which lists all the currently available subdomains. This page also displays the CNAME that you need for creating Cname records for each proxy alias.

Enter the pre-agreed upon API domain prefix, which will be prepended to all the subdomains in the list. The resulting subdomains, including the prefix, will be the CNAME aliases used when creating CNAME records.


Complete Certificate Request

Provided that Cname aliases have already been set up, press Generate

If everything is set up correctly, you will arrive back on the Certificate Provisioning page and you will see under Status that the request is Pending and the timestamp that the request was initiated.


Unable to render {include} The included page could not be found.



If Cname records are not yet configured or are configured incorrectly, you will receive a warning similar to the following:


Email Verification

Verification emails will be sent to the following 5 addresses by default

  • admin@<Your-Domain>

  • administrator@<Your-Domain>

  • hostmaster@<Your-Domain>

  • webmaster@<Your-Domain>

  • postmaster@<Your-Domain>

In addition to the above default addresses, if the whois information is publicly available, emails will also attempt to be sent to the domain's Registrant, Technical Contact, and Administrative Contact.

The verification emails will come from Amazon Certificates ( and their subject will be "Certificate approval for <Your-Domain-Name>".

For additional information, see

Resending Verification Emails

If you need to resend verification emails for any of the subdomains, you can click the Resend email icon icon next to the appropriate entry. Clicking Resend on the notification pop-up will send a new verification email to all addresses for that subdomain.


Certificate Failure

If certificate creation failed you will see it noted on the Certificate Provisioning page, along with the reason it did not complete.


Finalizing The Certificate

Once the certificate is created and active, you must then add the Prefix to the Site Settings page of the client's Gigya Console.


Be sure to press the Save Settings button at the bottom right of the Site Settings page.

Setup of the SSL Certificate is now complete.





  • No labels