Learn How DIY Home Center Implemented a Secure Shopping Domain

A few months ago, we published a blog post encouraging all our customers to implement a secure shopping domain. Not only is it a positive signal in itself, but Google has implemented some changes to Chrome that means that any insecure form will now be flagged as 'Not Secure'. While you'll obviously have secure domains for your checkout and account sections, you may not have them for the shopping section — that means inputs, such as the keyword search field, could end up being flagged as insecure, potentially scaring away customers.

Since we published that post, I've spoken to a few of you about this and I'm pleased to see that many of you were already ahead of the game and preparing for it and, in some cases, already done it.

One site to have already taken the plunge is DIY Home Center.

DIY Home Center is purely ecommerce, so it's of paramount importance that their SuiteCommerce Advanced site runs quickly and smoothly. Concerned about what their shoppers would think when buying materials or furniture for their deck, they decided to migrate to a secure shopping domain.

I caught up with president and founder Michael Anderson, and platform manager Amelia Smith to find out how the process went, what others can learn from their trailblazing, and why it wasn't as scary as you might think.

Steve Goldberg: What made you want to implement a secure shopping domain?

Amelia Smith: A recent change to Google Chrome (and a few other browsers, such as Firefox) means that it has started flagging sites that allow users to submit data over an insecure protocol (HTTP) as 'Not Secure'. While we would never send sensitive customer data over an insecure connection, any keyword searches done on a 'Not Secure' connection would be flagged by Chrome.

From an operational point of view, this means that our shoppers might get a little nervous and not buy from us even if there was no actual risk to them. In ecommerce, user retention and conversion rate are super important. Any negative impact of these two things could be significant to our sales.

Michael Anderson: This was also partially due to a change that the Google search team initiated several years ago. Essentially, sites that implemented a “secure shopping” experience would potentially rank higher in Google organic search results. How much higher is frankly a mystery as there are literally hundreds of ranking signals, but it is definitely one signal they are looking at. In other words, all things being equal, sites that provide a “secure shopping” experience will rank higher organically than those that don't. Early on, many sites went ahead with secure shopping, but it was the recent change to Chrome (and the other browsers) that Amelia mentioned that created the sense of urgency for us and others in ecommerce.

SG: What was the first technical step you took to implementing a secure shopping domain?

MA: We went to the patch page on the developer portal. This page has a number of patch files that can be used to update or fix functionality for sites running older versions of SCA. We downloaded the patch that enables secure shopping.

Patch files are the code changes that need to be made to a site to get that functionality to work. You can apply them one of two ways: either by using a command like git apply or by manually updating the individual source files.

SG: Are there any issues with that?

MA: Yes. If your implementation has core source files that are overridden, you cannot automatically apply the patch file.

AS: Due to the number of changes in the patch and because of the number of overrides in our implementation, we had to create individual patch files for each source file that the patch impacted. We then went through them individually and applied each file to the core source file or made the change manually if it was an override.

SG: What happens after this?

MA: We wanted to test it. Unfortunately, you're not able to test a secure domain in sandbox, which means you can't fully test it there. This means you need to test your changes in a production environment under a different subdomain.

AS: In our case, we purchased an SSL certificate for ssltest.diyhomecenter.com and used that to test with. Initially we were not able to do this in production due to a limitation on the number of secure domains in our account. Once we raised this issue, NetSuite support acted quickly and was able to raise the limit so we could test.

SG: Were there other changes that need to be made before going live?

MA: We discovered that in a few instances we were using absolute links, rather than relative ones, when pointing to some resources. For example, this meant that we had hardcoded a link to a banner image starting with http://www.diyhomecenter.com/ etc — if we went live with this it would have loaded an insecure image (which would have caused a 'Not Secure' warning).

Fixing this meant going through all our code and making sure to use relative links, which means removing the protocol and domain. Relative path URLs inherit the protocol of the page it's served with, which means that it will automatically be served over HTTPS if that is what the rest of the page has loaded with.

SG: What did you do once it went live?

AS: After testing, of course, we needed to consider how the change would affect things off-site. For example, we have pay-per-click advertising and so we needed to update our ads to include https in the target URLs. We also needed to update our Google Analytics configuration.

SG: Did you need to create a new container?

MA: No, you can just update the URL option to change the protocol. You don't lose any history this way.

AS: Google and Bing also have search consoles that you need to update. You want to make sure to claim both versions of your site. You can copy any settings you have set from the http version over to the https version (such as URL parameters, sitemap file location and your disavow file for bad links).

MA: Finally, it was just a case of checking all of our other off-site links: confirmation page review prompts (Shopper Approved, TrustPilot), social tracking pixels, Google Tag Manager scripts, off-domain blog links, advertorials, email marketing, newsletters, transactional emails, etc. We decided to do these things after we went live in case there were any issues with our go live. If we had done them in advance and had run into issues, any off-site links with https specified would have created errors. Because SCA automatically redirects any http requests to https once you go live, it was safe to wait on these changes.

SG: Were there any issues after going live?

MA: No. None.

SG: How has the experience been since going live? Has there been an improvement in sales and conversions?

AS: We’ve noticed a small increase in conversion rate compared to the same time period last year.

SG: Thanks for your time.

Setting Up and Testing Secure Shopping Domains

Hopefully, Michael and Amelia's experiences will give you encouragement and useful advice for going through this process yourself. We have a lot of documentation around this subject, in particular if you're switching from a currently insecure shopping domain to a secure one.

The technical process of making your shopping domain secure takes about 45 minutes, but the process at large will obviously take longer depending on how much work you need to do to your code. As Amelia and Michael point out, there are considerations around the impact that moving to a secure site will have to your associated operations (eg analytics, marketing, advertising, etc).

To summarize the steps, you need to:

  1. Prepare your domains and security certificates
  2. Prepare and possibly patch your code
  3. Enable the secure domain in NetSuite, and upload your security certificates

Gradual Distrust by Chrome of Symantec Certificates

A further change in the security certificate world involves Symantec certificates, specifically the ones issued through its public key infrastructure.

Specifics can be found on Google's security blog from September. The important thing to keep in mind is that you should replace certificates that are part of its authority chain (brands include Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL) if they were issued before June 1, 2016.

The revocation of trust won't come into effect for a number of months, so you have time to replace any old certificates in the meantime.

Final Thoughts

Introducing a secure shopping domain is good for your customers' peace of mind. It's becoming the norm nowadays, and there's no good reason not to do it — especially as it's the direction the web is going in. Especially for ecommerce sites, you already have a secure checkout and account applications: the next logical step is to seucre the shopping experience too.