Site hosting news, tutorials, tips, How Tos and more

Office 365 Plans Available

banner-announcements

Today, we announce that Office 365 Plans are available for our USA-based customers.

What is Office 365?
Office 365 is a subscription service offered by Microsoft that gives you all the business productivity software you are familiar with – like Word, Excel, and PowerPoint and more. Office 365 is in the cloud so you can work from anywhere and from any device (PCs, Macs, Android tablets and phones, iPad, iPhone) – and on top of that, unlike one-time purchases of Office,  you won’t have to worry about upgrades ever again. You’ll always have the latest versions with the latest features.

office 365 applications

Office 365 subscriptions can come with Exchange email service which supports your custom domain and comes with a 50 GB mailbox.

Office 365 subscriptions can also include full Office desktop software, Office online services like Exchange, SharePoint, Skype for Business, and Microsoft Teams.

Office 365 Services

And you also get 1 TB of Cloud storage on OneDrive.

It’s the Office you know, but better. Find out more details about Office 365 plans, pricing and features on our website.

 

 



Spring App Installer Updates

The latest version of these apps are now available:



How we celebrate World Backup Day

I just found out that March 31st, 2018 is World Backup Day!

We had a quick meeting and decided to celebrate this special day by checking our backup system to make sure its functioning and continuing to backup our customer’s site/data like we do every day for disaster recovery.

If you haven’t done so in a while, we do recommend that you take the time to backup your websites and databases. March 31st would be a good day as any but it’s a good idea to make a schedule for backups at whatever time interval works for you and your needs. If you have any questions about backups, please contact our technical support team.

And if you want to celebrate World Backup Day everyday like us, then you can check out our SiteBackup service, which will automatically perform a daily backup of your website and databases for any of your websites hosted at Winhost or even websites and databases that are hosted at another hosting provider.

Happy World Backup Day!

 

 

 



Windows 2016 hosting available

banner-announcements

Hosting on Windows 2016 is available as an option when you sign up. Windows 2016 hosting comes with IIS 10.X.

If you are an existing customer and wish to move to a Windows 2016 server, contact our technical support team and they can migrate your site.

 



Scott Hanselman demos .NET Core cross-platform capabilities – OR – shows how hard it is to run .NET Core on linux shared hosting

Scott Hanselman recently blogged about getting ASP.NET Core to run on a cheap shared Linux hosting account at GoDaddy. The point of the article was to demonstrate that .NET Core is cross-platform and can even run with all the constraints of a shared hosting plan.

The post was impressive, but Scott repeated several times and even put it in the title of his post – “Don’t try this at home” – because of all the hacky hoops you had to jump through to get .NET Core to work.

I found the post an interesting read, but while I was reading through the article, I couldn’t stop thinking – why go through all that trouble to run .NET Core on a “cheap” ($3/mo plan that turns into $8/mo) linux plan, when you can run .NET Core out-of-the-box on Windows hosting providers – like Winhost. Even with our Basic Windows hosting plan (that starts at $3.95/mo), .NET Core is supported.

At Winhost you can deploy .NET Core apps straight from Visual Studio or, if the specific Core framework version is not on the server, you can use Self-Contained Deployment.

I totally understand that Hanselman’s blog was a “theoretical” exercise to demonstrate the versatility of .NET Core. But when you actually want to do something real with .NET Core, you are going to want to be on a hosting environment that makes it easier for you, not harder.

 



The Chrome Browser and Symantec SSL Certificates

You may be aware of the problem that Symantec has been having with Google over issuing of a large number of SSL certificates for major domains to individuals who were not associated with the domains. It’s a long story, but the result was Google informing Symantec that the Chrome browser would no longer trust SSL certificates issued by Symantec. The revocation of trust was to occur gradually over certain dates.

As a result, Symantec sold their SSL certificate business to another company that Google does trust. It becomes a little confusing though, since the new company is keeping the Symantec name for the certificates they issue.

If you bought an SSL certificate from us, you have either a RapidSSL, GeoTrust QuickSSL or GeoTrust True BusinessID certificate, and those are Symantec certificates.

Are you affected?

If, like most users, you renew your SSL certificate every year, this issue should not affect you. When you renew, the certificate will still be issued by Symantec, but it will be issued by the new incarnation of Symantec which Google trusts.

If you purchased a multi-year SSL certificate, check this timeline to see if there are any important dates that you should be aware of:

Certificates issued before June 1st, 2016

The Chrome browser will no longer trust this certificate after March 15, 2018. In order to retain trust by the Chrome browser, you need to replace this certificate.

Certificates issued after June 1st, 2016

The Chrome browser will no longer trust this certificate after September 13, 2018.

If you have a multi-year cert and aren’t quite sure if you’re affected, open up a support ticket and we’ll help you out.



Recap of New Hosting Services and Features in 2017

As 2017 comes to a close, we reflect on the year that’s passed and look forward to a new year.  Here are some of the new features, services and enhancements that we introduced in 2017.

ASP.NET Core Deployment Options

Last year, we launched support for ASP.NET Core on our hosting platform. Since then, Microsoft has been busy with many minor updates and also a major update with ASP.NET Core 2.0. We’ve been working hard to support .NET Core and support the different versions that our customers may be using. Winhost supports Framework Dependent Deployment (FDD) and also Self-contained deployment (SCD).

ASP.NET Framework 4.7

While Microsoft continues to update their latest .NET Core initiatives, they continue to update ASP.NET 4.x as well. We kept up-to-date with Microsoft’s ASP.NET 4.x framework and support ASP.NET 4.7 hosting on our platform.

Managed WordPress

Since WordPress is one of the most popular apps on the web, we host a fair share of WordPress sites. Ans due to its popularity, WordPress gets a lot of attention from hackers, so we’ve helped many of our customers with compromises and hacks. To insure security, it’s important to keep up-to-date with WordPress updates, theme updates and plugin updates.

To that end, we understand that many of our customers may not have the time or the know-how to maintain their WordPress site – so we launched a Managed WordPress service. With our Managed WordPress service, we harden your WordPress application and will update your WordPress core, plugins and themes monthly. Our expert staff will also personally review your WordPress installation every month, looking for any signs of compromise or malicious files. And if any malicious activity is found, we’ll clean it up.

node.js

Due to customer requests, we added support for Node.js. If you are interested in using Node.js, get in contact with us.

Increased FTP Users

We also increased the number of FTP users that can be created for each of our plans. The Basic plan supports 10 FTP users, the Max plan supports 30, and the Ultimate plan supports 100.

Although I didn’t highlight any of the behind-the-scenes activity in this list, you can rest assured that we continue to make improvements to our back-end infrastructure, security, processes, hardware and support.

We’re honored that so many of you trust Winhost with your important websites and applications, and we work hard every day to make you happy that you’ve made that choice.

Wishing everyone a very happy new year!



How SSL certificates work

SSL certificates are necessary if you do credit card transactions on your site, or if you simply want to make your site available via an HTTPS URL (such as: https://example.com). If you visit that URL without the HTTPS prefix, you’ll notice that there’s no security “lock” displayed in your browser. That lock icon means your connection to a site is encrypted.

If you’ve never cared about HTTPS, it’s probably time to start. The days when you could avoid using HTTPS are rapidly coming to an end, and Google and the other big web browser makers are more or less forcing the change on everyone. So it’s a change we’re all going to have to make, or one day in the not-too-distant future, security warnings could be greeting every visitor who loads our sites.

With that in mind, here’s a high level overview of what SSL is and how it’s implemented. Think of it as an introduction to the concepts and a peek at the inner workings for anyone who is new to the subject.

Technical note: modern web servers don’t really use the SSL (Secure Socket Layer) protocol anymore, but the name has stuck to the certificates as kind of a generic identifier, so we use “SSL” in this article. The TLS (Transport Layer Security) protocol has replaced SSL for most uses. We’re also using the example of a web browser connecting to a web server, but the concept is the same no matter what kind of client is making a secure connection to a server.

What is an SSL certificate?

An SSL certificate is really just a text file that is installed on the web server. It ensures that the domain name in the certificate matches the domain name of the site, and enables a visitor’s browser to make a secure connection to the site, so that the traffic back and forth is encrypted and no third-party can listen in on the conversation.

The reason for encrypting transferred data may be obvious where financial transactions are concerned, but even if you’re not sending financial data across the web, quite a bit of private data can be passed between your site and a visitor’s browser (like usernames and passwords). That private data is valuable to unscrupulous types, so encrypting the connection protects the data. Without an SSL certificate and the HTTPS connection, that encryption doesn’t happen.

It’s worth noting here that an HTTPS connection doesn’t prevent someone from finding out which domains you’ve visited. It just makes it (theoretically) impossible for them to see any of the data that was exchanged during the visit.

What’s inside the SSL certificate?

An SSL certificate contains information about your business or organization (or simply you as a person), and a cryptographic key unique to your domain or certificate. That key is used to establish the encrypted connection. Your website presents the key to the visitor’s browser, and if the browser determines the key is valid (more on that in a minute), the encrypted connection is established.

Let’s talk about trust for a minute…

The entire SSL system is based on trust. When the HTTPS protocol was established, everyone agreed to trust certain organizations (and later companies) to issue legitimate certificates. Those organizations and companies are called certificate authorities. The certificate authority verifies who you are when they issue the certificate and the browser trusts the that the certificate authority has done that verification.

You might see a bit of a problem there if you’ve ever requested a “domain validated” SSL certificate and noticed that no one actually checked anything other than the fact that you had an email address on the domain. It wasn’t always that way. In the early days of SSL, the certificate authority did verify that you were who you said you were, and the owner of the domain you were requesting a certificate for. But as you might imagine, that time-consuming kind of validation quickly became impossible, so now that level of manual human validation is only done for expensive “extended validation” certificates.

How does the browser know when to trust an SSL certificate?

Every certificate authority issues a “root certificate,” which is like a master certificate for that authority. If the authority operates under different names or resells certificates through other companies, they issue “intermediate certificates” that are related or connected to the root certificate. Then the certificate for your domain is associated with the intermediate or root certificate, and that makes up a certificate chain. So the browser trusts the certificate for your domain because it’s associated with a root certificate.

Your certificate, any intermediate certificates and the root certificate are all installed on the web server. The same root certificates are also pre-installed in web browsers and many computer operating systems, so the browser can validate the root certificate on the web server. There are actually a few checks and validations that take place between the different certificates, but her’s a simplified diagram of the chain:

The connection is trusted if:

How does SSL work?

It’s pretty easy to get lost in the tall weeds here, because the underlying system that handles HTTPS encryption between a client (browser) and a server (your site) is quite complicated (and to add to the complication, the system is always changing, as better and stronger encryption methods are introduced).

But in a nutshell:

– The browser makes a TCP (standard Internet) connection to the site on the web server.

– The browser starts an SSL “handshake,” which is a transfer of data to the server about which version of SSL/TLS the browser is running, and which encryption methods it wants to use.

– The web server determines the highest SSL/TLS version that is supported by both the server and the browser, then sends its certificate(s) to the browser.

– If the certificate(s) meet all the criteria described above (in the “connection is trusted if” section), a cryptographic key is then exchanged and the browser tells the server that all further communication will be encrypted, and sends an encrypted authentication message to the server.

– The server verifies that the message is correct, then returns a similar message that the browser verifies.

– That’s the end of the “handshake,” and until it is broken, the browser and server can communicate securely.

Luckily all of those steps typically take place in a fraction of a second, and the browser and web serer don’t have to do them again (unless the secure connection is broken).

Well, that’s a lot of words for a “simplified” explanation, isn’t it. Sorry about that. But hopefully this has helped you to better understand what an SSL certificate is and what it does.

 

Still curious about SSL/HTTPS? Check out these other articles:

Ready or Not, It’s Time to Consider HTTPS
Let’s (not) Encrypt. But let’s not ignore https either.
How to Secure Your Primary Domain for Free When Ordering an SSL Certificate
Google Chrome, SSL certificates, SHA-1, SHA-2 and the “obsolete cryptography” message