Search
Clear search
Close search
Google apps
Main menu

SSL compliance

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 creatives

When 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.

Folder base paths are not available for video files, and are only available for folders created after May 27, 2015.

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:
  1. 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/"

  2. 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.jpg is: "https://s0qa.2mdn.net/ads/richmedia/studio/21429303/myimage.jpg"

To load assets in new creatives, learn how to use assets from Asset Library. The steps above are only for updating creatives that already reference static paths.
A creative was labeled non-compliant but it really is compliant

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.

Dynamic creatives

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 DCM 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.

  1. 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?
  2. 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.
  3. If the columns are not used for click-through URLs, then the feed is non-compliant and cannot be trafficked to SSL-required sites.
Checking the verify box if the profile/creative isn't compliant could result in live issues.
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.

Example for an encrypted website

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.

Example for an unencrypted website

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.

Example
If the url is http://www.google.com, enter https://www.google.com in your browser's address bar. If the URL is enabled for HTTPS loading, it will load properly, and a lock icon ( ) will be displayed in the browser's address bar.

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://.

Was this article helpful?
How can we improve it?