The push to secure peo­ples web­site con­nec­tions is going a lot fur­ther. At first it was login forms that where get­ting labeled as inse­cure (most promi­nent­ly in Fire­fox). Now Google, with Chrome is going a step fur­ther, from July this year all sites which are not using encrypt­ed con­nec­tions (old http) will be marked as not secure. From Googles secu­ri­ty blog:

For the past sev­er­al years, we’ve moved toward a more secure web by strong­ly advo­cat­ing that sites adopt HTTPS encryp­tion. And with­in the last year, we’ve also helped users under­stand that HTTP sites are not secure by grad­u­al­ly mark­ing a larg­er sub­set of HTTP pages as “not secure”. Begin­ning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure”.

So now real­ly is the time, even if what you have is a sim­ple brochure site to make sure your site works with secure connections.

Most web host­ing pan­els will give access to enable SSL if you don’t have tech­ni­cal exper­tise. Lets Encrypt pro­vides free, auto renew­able SSL cer­tifi­cates that work in all recent browsers, and there are also ser­vices such as Cloud­flare that can offer upgrade con­nec­tions to SSL, though this does open a per­son in the mid­dle issue as Cloud­flare decrypt the traf­fic and then make a fur­ther request for the page, which depend­ing on set­tings may not be secure.

Once secure con­nec­tions are enabled and the cer­tifi­cate is installed, its impor­tant to check any resources that load on the page are also set to load over https. Some­times with plat­forms such as Word­Press, when the ini­tial install was over a stan­dard http url, any images that where uploaded can be includ­ed in the page with the absolute URL. This will flag up warn­ings when load­ing the web­site under a secure con­nec­tion (a mixed con­tent warn­ing). This will require a search and replace over all the old URLs, as well as chang­ing the sites set­ting to use the secure ver­sion in the future (under Set­tings → Gen­er­al). There are also plu­g­ins that can silent­ly rewrite inse­cure requests to the secure ver­sion as web­pages are loaded. Sim­i­lar plu­g­ins or mod­ules are avail­able for oth­er platforms.

Same issue can hap­pen with resources such as CSS and Javascript. If your not tech­ni­cal­ly mind­ed you may need to talk to the per­son who devel­oped your web­site, or find a devel­op­er. In gen­er­al its bet­ter to load resources rel­a­tive­ly using /resource type uris instead of the full link. For exter­nal resources (scripts loaded from Google for exam­ple) then //api.google.com (just exclude the http: bit) will mean that the resources load on whichev­er type of con­nec­tion the web con­nec­tion the site was orig­i­nal­ly loaded with.

Upgrad­ing to secure con­nec­tions pro­vides bet­ter reas­sur­ance to those who make use of your web­site, though its only one step. With GDPR com­ing into force then there is a lot more to make sure your web­site is secure. I have a feel­ing that soon enough it will not just be inse­cure warn­ings, but http will stop being sup­port­ed altogether.