Will visitors know I've gone from an SSL site to a non-SSL site for HTTP?

November 15, 2012 5:56 AM

SSL, licences, and migrating a website. Old server has an SSL certificate. New one has not. Not using HTTPS. Will visitors see any warnings or otherwise perceive the change?

Migrating a website. Everything looks fine: old database/files on new machine all work when you browse them with the temporary test domain name. About to re-point the actual website domain name with our DNS host/provider. So "www.mysite.com" points to the old server, and we're about to change it to point to the new server.

But wait! The old server has an SSL licence and is set up to use SSL. (We used to do some HTTPS stuff, but now we don't.) The new one does not: SSL is not set up on that server. So I can visit https://www.mysite.com on the old server, but not on the new one.

So Fred has been to our old server, http://www.mysite.com. Next day he goes to http://www.mysite.com. Will his browser warn him that the license has disappeared? Will there be any other untoward effects?

Background information: this sounds like a dumb question. Fred is using HTTP. That doesn't use SSL! So what's the problem?

In an unrelated accident yesterday, we told the old site to use an invalid (expired) SSL certificate. And people accessing got security warnings about the SSL certificate. They weren't trying to use HTTPS. (OR WERE THEY? Do modern browsers all try to switch HTTPS by default?)

So I'm worried now that when we migrate to the new SSL-less server, we'll have users getting warnings about the sudden lack of an SSL license, even though they are not using HTTPS. Can anyone reassure me?

posted by alasdair to Computers & Internet (13 answers total)

If all visitors are only using HTTP, then they won't see any difference, as you expect.

However, you appear to have evidence that some visitors are still using HTTPS to access the site (or parts of it -- maybe you have images or CSS files served over HTTPS?). Those visitors will see warnings if you are using an invalid cert, or broken functionality if the new server is not responding to SSL.
posted by richb at 6:03 AM on November 15, 2012

Http links and https links are distinct URLs, so bookmarks will break, and suggested URLs in the browser history will break. You're probably serving out an error page or refusing connections on the https port, so those cases won't be pretty. But other than that, it'll be up to the user to notice the absence of whichever clues the browser affords them.
posted by Monsieur Caution at 6:04 AM on November 15, 2012

After the switch, users going to http://www.mysite.com won't get a warning about the SSL certificate. However, if users have bookmarked https://www.mysite.com they'll get an error unless your server redirects them to the non-SSL http://www.mysite.com URL. You should make sure that redirect is set up.

Re: your problem yesterday, people who got security warnings were trying to use SSL, whether they knew it or not. Annoyingly, many browsers now hide the "http(s)://" portion of the URL in the location bar, so it's not always obvious when you're requesting an SSL URL. Your (old) server may have a redirect rule in place that sends users who have requested http://www.mysite.com to the SSL-enabled https://www.mysite.com - this is pretty standard practice for sites that use SSL.

For your new site, just make sure that you have a redirect rule in place to catch all https requests and send them to the equivalent http URL, and your users won't see any errors.
posted by sriracha at 6:10 AM on November 15, 2012

Browsers don't default to HTTPS, so that shouldn't be an issue. However, if someone has HTTPS URLs of your site in their browser history, I've noticed that Firefox will autocomplete to HTTPS if they type in all or part of your domain in the location bar. So that could be a problem (but new visitors will be fine).
posted by floomp at 6:11 AM on November 15, 2012

@sriracha: "For your new site, just make sure that you have a redirect rule in place to catch all https requests and send them to the equivalent http URL, and your users won't see any errors." -- unfortunately, you won't be able to set up such a rule unless the new server is accepting SSL requests and presenting a valid certificate (in which case you might as well serve the site over HTTPS).
posted by richb at 6:13 AM on November 15, 2012

"Annoyingly, many browsers now hide the "http(s)://" portion of the URL in the location bar, so it's not always obvious when you're requesting an SSL URL."

While a lot of browsers hide http://, they'll all show https:// (as far as I know).
posted by floomp at 6:15 AM on November 15, 2012

2nding the idea to check if there are images or something like that with https URLs that could have caused the error Fred mentions despite the URL in his browser's address bar being http.
posted by XMLicious at 6:18 AM on November 15, 2012

As mentioned above, this will break any bookmarks that go to the old https URL. Check your web logs or analytics software to see how many people access the site through https. If it's an even marginally significant number, I would recommend installing the certificate from the old server on the new one, and redirecting users who access the site through https to the http server instead. If you can't get the old certificate, then purchase a new one—it's a relatively painless process, and inexpensive compared to potentially losing those users who had bookmarked the site as https.
posted by aparrish at 6:33 AM on November 15, 2012

You could test it out first. Change your network's internal DNS or your computer's hosts file to point to the new site.
posted by Nonsteroidal Anti-Inflammatory Drug at 6:57 AM on November 15, 2012

First, thank you all, very helpful.

None of my browsers (IE10, Firefox 16, Google Chrome 23) appear to hide "https://": if I go to https://www.amazon.co.uk then I see the https:// in the address bar for all three browsers, as floomp says.

If I go to https://www.metafilter.com then I end up at http://www.metafilter.com, but I'm inferring from sriracha and richb that this is because MetaFilter has a valid SSL certificate that it uses to enable communication on the HTTPS address, the communication being "go and use the HTTP address, thanks!". (1) I won't be able to do this for my site unless I similarly provide a valid SSL certificate for the new site so it can do the redirect. So as aparrish observes I should check the server logs to see who this affects and make a call on sorting SSL for the new server.

I'll test with Nonsteroidal's suggestion too, thanks. Thanks again to all, mentioned or not. If anything I've written above is wrong, or anyone else has any comments, I'll check back in tomorrow.

(1) (Same for http://www.amazon.com. Slight oddness with https://www.metafilter.com and Firefox, where this does NOT work - I stay at https://www.metafilter.com)
posted by alasdair at 8:54 AM on November 15, 2012

You can just get a new cert for the new domain for like, $10, can't you?
posted by jsturgill at 9:07 AM on November 15, 2012

Your caching directives (or lack thereof) may be such that you have cached pointers to https resources floating out there. I would take a look at your access logs - they will have a record of all https addresses that have been requested so you can "uncache" those references as needed.

Also, there are browser extensions that redirect everything through https. If your site was https-enabled, these extensions may continue to try to force it into secure mode not knowing you don't offer it anymore. You can contact them individually to get removed.
posted by rada at 11:05 AM on November 15, 2012

OK, we migrated the site. There were zero problems detected with any browser. So looks like I was worrying unnecessarily!
posted by alasdair at 12:42 PM on December 15, 2012