SSL Certificate Provisioning is ONLY available for the US/EU/AU data centers.
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 abc.example.com will fail if any of the following are true:
- There is already a certificate hosted in any Amazon Distribution for abc.example.com
- There is already a certificate hosted in any Amazon Distribution for *.example.com
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:
- For each of the prefixed domains, ask the client to add a TXT record (DNS) from the prefixed domain (i.e gigya.mysite.com) to d1nd30sf63x38i.cloudfront.net .
- Reach out to IT and request to open a ticket to Amazon about moving ownership of that CNAME to the above distribution.
- Once the CNAME ownership moves to the above distribution - we will delete it and free the domain.
- Inform the client they can re-try the certificate provisioning process.
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.
Important First Steps
A few things need to be completed prior to creating a Domain Prefix in the Gigya Console.
- 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.
- Determine the Prefix they want to use for all of the subdomains defined in step 1, above, e.g., if thee subdomains are sub1.mysite.com, sub2.mysite.com and sub3.mysite.com; you will need to know the prefix they wish to use, i.e., <prefix>.sub1.mysite.com, <prefix>.sub2.mysite.com, and <prefix>.sub3.mysite.com.
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>.gigya-api.com. 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.
If Cname records are not yet configured or are configured incorrectly, you will receive a warning similar to the following:
Verification emails will be sent to the following 5 addresses by default
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 (email@example.com) and their subject will be "Certificate approval for <Your-Domain-Name>".
For additional information, see https://aws.amazon.com/certificate-manager/faqs/#email_validation.
Resending Verification Emails
If you need to resend verification emails for any of the subdomains, you can click theicon next to the appropriate entry. Clicking Resend on the notification pop-up will send a new verification email to all addresses for that subdomain.
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
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.