Http to Https redirect after SSL encription

[Grégoire_Miche2]

One of my customers is being asked to implement SSL encryption of the Marketo instance. The rationale behind it is that the web site and documentation center will have the SSL encryption implemented.

As they have been using Marketo for a couple of years now, the problem is they have literally hundreds of programs running with LP's and emails, all of them using content (mostly images and links to download docs) that we need to edit to replace http into https.

Is there an alternative solution?

Thx to all

-Greg

[Jason_Keller3]

I added a SSL cert to Marketo LPs awhile ago and the labor for me was in updating the CSS at the template level. Reviewing and re-approving impacted LPs was not that difficult. The file library does automatically update, so that was easy, but it is worth checking to ensure you are using Marketo assets (like images) on non-Marketo pages - or at least ensure those are updated.

As for the overwhelming amount of LPs to audit, it would be a good practice to figure out a way to manage these, regardless of whether you have to for this project. There are ways that make managing hundreds/thousands of LPs sustainable, but they do usually start with a little bit of manual tracking of what is active, what is redirected and when things were last updated. I really love occasionally downloading the list of LPs from Design Studio from time to time to review these.

Good luck!

[Ben_Griffith1]

We have gone through this exercise with a client as well.  See here for details: https://salytics.com/ssl/

[Vinod_Mahadeva]

Hi Ben,

We're using postman to run the APIs and when I run the get landing page content API through API collection runner am not able to download the iterations response body which has the Landing page content. Do you have or know how to do that or any alternative way of doing this task

[Vera_Parassidis]

We are actually starting SSL migration as well. We have been working with John Mattos (W) from Marketo and he recently published this post​.

During the discovery calls we were assured that no changes/updates to emails/email templates would be needed and the only assets we would need to update are:

Landing Page templates

Landing pages (if they were not created from the above templates or if some insecure assets are referred to from the page editor)

Snippets

Update CSS files and import them using "Replace image or file"

All the assets, except css files, could be worked on and kept in draft mode until the cutoff which allows some time for us as we have a lot of templates and landing pages.

[Grégoire_Miche2]

Well,

Editing all LP's and LP templates, snippets and CSS might already be a cumbersome job!

-Greg

[SanfordWhiteman]

Editing all LP's and LP templates, snippets and CSS might already be a cumbersome job!

Yeah, that's hardly comforting, I know.

And it's definitely not true that all links in emails will be rewritten. They may still work, but they won't be secure -- which was the whole idea in the first place, right?

[John_M]

The rules governing insecure content are established by the W3C, so im not sure where you heard that. It's 100% true that if you refer to a non http asset in an secure page, you'll see a warning in MOST browsers (its browser dependent). The most glaring of these will be scripts and CSS files, which will actually not work. Images will yield a warning, but will render.

[Dan_Stevens_]

Greg, when we did the same thing a couple of years ago, all of those links were changed to https automatically. We didn't have to manually change anything.

[Grégoire_Miche2]

Hi Dan,

Yes all the URL of the images and files are changed together with that of the landing pages. But then, in order to avoid any "unsecure content" alert in browsers, one needs to edit every LP and every email and change the URLs of images and other files from HTTP to HTTPS.

I am hoping that someone knows a way to avoid the workload associated with this change, but I am afraid there is none.

-Greg

[Dan_Stevens_]

That's what I'm referring to. All image references (in emails and LPs), URLs of, and links to LPs, were changed automatically.

[Dan_Stevens_]

Ok, scratch that. I suspect you're referring to references to non-Marketo resources/assets - correct?  This wasn't really an issue for us since most of our LPs and emails reference Marketo assets (except for the occasional external link to a third-party site).  Also, any references to third party code, like bootstrap, already uses https.

[Grégoire_Miche2]

Hi Dan,

Apparently, from this FAQ and this post and the comments (specially the post from Justin), there is nothing automatic unless you implement HSTS on the top level domain. Maybe this what you did, didn't you?

-Greg

[SanfordWhiteman]

HSTS can only "solve" the problem in browsers that support it (notable exception being IE < IE 11).

More important, treating HSTS as ensuring security is wrong unless your domain is on the browsers' HSTS Preload list.  If you're not on Preload your site is insecure for every initial visit (which is to say: it's insecure). HSTS is at best a transitional mechanism while you hard-code https:​// links (or protocol-relative // links, of course).

[Grégoire_Miche2]

HI Sanford,

Thx. What does it take to implement HSTS?

-Greg

[SanfordWhiteman · Accepted solution]

In its most basic form, it just means adding an HTTP header to the parent registered domain, that is, whoever controls http:​//example.com (with no hostname) adds the header to Apache/IIS/Nginx and that's it.

This gives an unprecedented -- and dangerous -- level of control to the people who operate the uppermost parent domain.  Not that they would mess anything up on purpose , but it means the webmaster of http​://example.com in effect has control over how people are allowed to access http​://pages.example.com -- and not just marketing-related hostnames but any other hostnames, like webmail.example.com or documentmgmt.example.com or some-internal-app-not-running-over-https.example.com.  Aside from HSTS there really isn't any other to exert this kind of control (and you don't even need access to DNS records to do it) so it's pretty freaky.

So this kind of migration is not to be taken lightly and requires a thorough audit of all hostnames in use, both internally and externally, to ensure that they are listening for HTTPS connections.

[Grégoire_Miche2]

I am talking here about very large accounts. Very unlikely that they will let anyone doing this

So this does not tell me how Dan got his migration go so smoothly....

-Greg

[SanfordWhiteman]

I am talking here about very large accounts. Very unlikely that they will let anyone doing this

I agree. Even small accounts will break stuff if they don't plan.  The payoff is great, and it's the next step to getting into browsers' inbuilt HSTS lists, which is when real security happens. But not an overnight thing.

So this does not tell me how Dan got his migration go so smoothly....

Me neither! I can't see program tokens (let alone my beloved Velocity tokens) being safely translated on-the-fly to the secure domain.

[Dan_Stevens_]

To be honest, I can't remember since it's been so long.  All I know is that is was pretty effortless on our end.  We (Marketo Support and our IT folks) did need to be on a call together when they "flipped the switch".