The secure sockets layer (SSL) protocol is used by secure sites to encrypt communication between the server and the user's browser. In order for a site to be SSL-compliant, all elements loaded onto the site must also use SSL.
If a non-secure creative is served onto a secure site, it can prompt a warning in the user's browser, cause ad serving problems, or even cause the entire page to be blocked. Therefore, it is very important to pay attention to SSL compliance.
Standard rich media creativesWhen you upload a creative that has non-secure URLs to the Creatives tab in Studio, you'll see a warning about it in the "Manage files" step of the "Creatives details" screen. The warning next to each creative will specify the non-secure URL that you should fix.
Make creatives SSL-compliant
To make your creatives secure and SSL-compliant, replace the non-secure URLs that are listed in Studio with secure URLs and re-upload the creatives to Studio. (See Upload your files to learn how.) Secure URLs either begin with https or use protocol-relative URLs. For example, //mysite.com.
Tips
- You can't just change http to https. Sometimes vendors or advertisers have completely different secure URLs, especially in the case of tracking URLs for event tags.
- Don't modify click-through URLs, http is acceptable for links leading away from a secure site.
Migrate assets from a non-secure host
If your current asset hosting platform doesn't offer secure serving, you can migrate to a secure host or use Studio's Asset Library.
Replacing asset URLs in an existing creative with Asset Library
To replace non-secure asset URLs in an existing creative, first upload your assets to the Assets tab in Studio, then follow the steps below.
Load assets from an Asset Library folder using folder base paths:-
Select a folder and copy the "folder base path" from the Details panel in the Assets tab. The folder base path points directly to this folder and allows you to reference any file within.
For example, your folder base path will be similar to:
"https://s0qa.2mdn.net/ads/richmedia/studio/21429303/" -
Replace the non-secure path in your creative with the folder base path. Add the filename at the end.
Using the example path above, the static url that points to a file called
myimage.jpgis:"https://s0qa.2mdn.net/ads/richmedia/studio/21429303/myimage.jpg"
When you upload the creative to the Creatives tab in Studio, Studio looks through all functions in the creative code, regardless of whether a particular method is invoked or not. To remove the SSL non-compliance warnings from Studio, remove the methods that aren't getting invoked from the creative code, double-check that all non–click-through URLs used in the creative are secure, and upload the creative again.
If your feed or field is non-compliant, there will be an alert icon displayed next to it in Step 2: Manage Data. You may choose to either update the feed so it meets SSL requirements or ignore the alert if the associated dynamic creatives will never be trafficked to SSL-required sites. Profiles created before July 1, 2014, will have a checkbox option to verify the feed is compliant.
About the "I verify this feed is SSL-compliant" checkbox
Dynamic profiles created before July 1 will have an option to manually verify compliance by checking the checkbox, 'I verify this feed is SSL-compliant'. Checking this box means you have checked the feed and can verify it is compliant. Then, the associated creatives will be compliant in Campaign Manager 360 for trafficking.
A feed is still compliant if the click-through URLs were mislabeled as 'text'. Technically this is still compliant though it triggers the Studio alert.
- Check if the feed is eligible for the checkbox: look for URL columns in the feed that start with
http://and also use the text field type. Are these columns used for click-through URLs? - If so, submit a request to your Solutions Consultant to turn on the feature called
GPA_ALLOW_OVERRIDING_SSL_STATUS. Once this is done, then check the verify box in "Step 2: Manage Data" of the Dynamic workflow. - If the columns are not used for click-through URLs, then the feed is non-compliant and cannot be trafficked to SSL-required sites.
Make dynamic creatives SSL-compliant
To make sure your dynamic creatives are secure and SSL-compliant, check that Data/Field types containing 'http://' URLs are not set as 'text'. This is because when a URL is set as 'text', the feed and profile will be considered non-compliant. Instead, use one of the options in the table below.
| Use cases | Data/field type | Accepted URLs |
|---|---|---|
| images | Image URL | http:// OR https:// |
| pixels, to construct videos on the fly, videos* | third-party URL | (pixels only) http:// OR https:// (others) http:// |
| clickthrough links | Exit URL | http:// OR https:// |
| Exit URLs used for reporting | Exit URL | http:// OR https:// |
* videos always need https URLs
Note: Keep in mind that secure URLs can be different from non-secure URLs; that is, you can't just change http to https. Sometimes vendors or advertisers have completely different secure URLs, especially in the case of tracking URLs (for event tags).
Next steps for SSL non-compliant profiles
To remove the SSL non-compliance warnings from the Studio Profile, check the elements in Step 2: Manage Data for http:// fields set as 'text'. If they are, then try one of the following:
- Update the data/field type to Asset/Image/3rd Party URL. (Don't forget to update the creative code too).
- Some profiles have a checkbox with the message 'I verify this feed is SSL-compliant'. Check this box if you checked the profile and can verify it's SSL-compliant. (Read more in the section: About the "I verify this feed is SSL-compliant" checkbox).
- Do nothing and leave the profile non-compliant. If the placement doesn't require SSL, then creatives could stay non-compliant.
How protocol-relative URLs work
A protocol-relative URL has neither HTTP nor HTTPS at the beginning. Instead it starts with a //. A protocol-relative URL has the advantage of automatically adapting to the protocol of the page the URL is used on. You can only use protocol-relative URLs from hosts that support both HTTP and HTTPS serving.
If a protocol-relative URL is loaded on https://www.youtube.com, then the URL will automatically be loaded via HTTPS as YouTube is loaded via HTTPS. // becomes https:// at load time.
If an HTTP URL attempts loading on an HTTPS website you visit, a warning will appear in your browser, and the content may not get loaded at all.
If a protocol-relative URL is loaded on http://www.theguardian.com, then the pixel will automatically be loaded via HTTP as the Guardian is loaded via HTTP. // becomes http:// at load time.
Loading an HTTPS URL on an HTTP website works without problems.
Switching to a protocol-relative URL
If a URL begins with http:// and you want to use the protocol-relative version of the same URL, make sure to first test the HTTPS version of the URL in a browser. Not all sites have HTTPS enabled, and attempting to load URLs that are not enabled for secure serving will cause an error. A simple way to check if a URL works over HTTPS is to enter the url with https:// in a browser.
Local Testing
Protocol-relative urls have one disadvantage: when creative developers work on their creatives from their workstation, browsers sometimes try to open them via the file:// protocol. That means the protocol-relative URL does not work in a local environment. As this only impacts local testing of a creative, it's still recommended to use protocol-relative URLs when possible. If a developer wants to test the pixel locally too, the protocol needs to be specifically set to https://.