let's encrypt logo

Let’s Encrypt SSLs enabled on our reseller hosting platform

let's encrypt logoSSL Certificates have become a must-have for websites since Google declared secure HTTPS connections a ranking factor and especially since the search engine giant voiced its intention to start flagging all non-HTTPS pages as insecure later in 2017 in a visible-to-the-Chrome-user manner.

The hype around SSLs has made SSL providers reconsider the pricing of certificates so as to make them more affordable to the wide public.

Meanwhile, a public-benefit authority called Let’s Encrypt aimed at providing an all-free HTTPS encryption solution to users was born in 2016.

Let’s Encrypt represents a free open certificate authority (CA), which provides website owners with digital certificates for enabling HTTPS (SSL/TLS).

Just like regular SSL certificates, Let’s Encrypt certificates offer basic SSL encryption, i.e. they give site visitors assurance that they are exchanging information with the domain that is visible in the address bar and that their personal data (login details, credit card information, etc.) cannot be eavesdropped.

If a site is using a Let’s Encrypt SSL, you will see https:// at the beginning of the URL in your browser’s address bar, along with a green padlock.

Let’s Encrypt SSL certificates may, however, not be suitable for every website. Know more

To give our customers the benefit of this development we have enabled the setup and automated maintenance of Let’s Encrypt SSL certificates in your iWebz Web Hosting control panel.

You can enable a Let’s Encrypt SSL certificate for any website whose domain is hosted in your iWebz Web Hosting account. Once your site loads over HTTPS, you need to redirect all HTTP URLs to their HTTPS counterparts. You can do that by adding a few lines of code in your .htaccess file.

 

dnssec

DNSSEC enabled for domain names on our platform

dnssecBy translating domain names into IP addresses, the Domain Name System (DNS) makes client-server communication possible and is crucial for the operability of the Internet.

Over time, the DNS has yielded vulnerabilities that allow hijackers to sneak into sessions and deceive users into giving their secure details to fake websites, for example.

This has called for the introduction of the Domain Name System Security Extensions or DNSSEC technology so that this part of the Internet’s infrastructure can be made secure.

The DNSSEC digital signature ensures that you’re communicating with the site or Internet location you intended to visit. DNSSEC uses a system of public keys and digital signatures to verify data. It simply adds new records to DNS alongside existing records. These new record types, such as RRSIG and DNSKEY, can be retrieved in the same way as common records such as A, CNAME and MX.

A signed nameserver has a public and private key for each zone. When someone makes a request, it sends information signed with its private key; the recipient then unlocks it with the public key. If a third party tries to send untrustworthy information, it won’t unlock properly with the public key, so the recipient will know the information is bogus.

To know more about DNSSEC you can visit this page on the ICANN website.

In line with the global end-to-end deployment trend, we have added DNSSEC on our platform as well for your hosted domains hosted in your iWebz Web Hosting account. This option is currently available for .COM, .NET, .ORG, .INFO and .BIZ domains.

 

getssl logo

ssl.iwebz.net is now getsslnow.com

getssl logoThe team at iWebz would like to announce that as of 1st November 2017 we have permanently moved our address from ssl.iwebz.net to getsslnow.com thereby merging all our SSL certificate business activities under the getSSL by iWebz℠ brand.

ssl.iwebz.net is now getsslnow.com

  • The login details for your user account remain unchanged.
  • Your orders details will continue to be available.
  • Your certificates will continue to function until expiry of validity.
  • Newsletter subscribers have already been migrated.

If you are a customer and need any clarifications send us your query.

 

Top SSL Certificate Brands of 2017

An ongoing survey by W3Techs has thrown up some interesting numbers on the state of the global SSL Certificate market. Most notably 23.7% of websites have yet to implement SSL certificates.

W3Techs investigated technologies of websites, not of individual web pages. If a technology was found on any of the pages, it is considered to be used by the website.

W3Techs included only the top 10 million websites (top 1 million before June 2013) in the statistics in order to limit the impact of domain spammers. Website popularity rankings were provided by Alexa (an Amazon.com company) and a 3-month average ranking was used.

W3Techs did not consider subdomains to be separate websites. For instance, sub1.example.com and sub2.example.com are considered to belong to the same site as example.com. That means for example, that all the subdomains of blogger.com, wordpress.com and similar sites are counted only as one website.

W3Techs did not include redirected domains. For example, Sun.com redirects to Oracle.com, and is therefore not counted.

Not surprisingly to us at iWebz, the results show Comodo certificates are preferred by 39.4% of all websites that use SSL certificates, and the free SSL certificate authority Let's Encrypt is yet to get major traction with websites.

w3techs ssl certificate market chare

The stats are updated daily and are available on W3Techs.com

 

Need Help Selecting A Certificate?

Let us help you select one for your site.
chrome 63 ftp not secure

FTP sites will be marked Not Secure from Google Chrome 63

FTP sites will be marked as Not Secure with the release of Google Chrome 63 in December 2017

chrome 63 ftp sites not secure

Thats the direction of the discussion at https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/HknIAQwMoWo/xYyezYV5AAAJ

Although there have been plans to remove FTP support altogether, for now FTP sites will only be marked as Not Secure.

About FTP

FTP, or File Transfer Protocol, used with ftp:// requests is a decades-old network protocol that is used to transfer files between clients and servers. FTP does not encrypt traffic by default, making it susceptible to interception and manipulation by eavesdropping third parties.

FTP can be secured using an SSL/TLS, which in turn creates FTPS. Unfortunately, FTPS is not a widely-supported feature on most browsers, including Chrome, due to its low usage rate.

What are FTP sites?

FTP sites are locations from where you can use your browser to download large files such as the latest Linux OS distribution, or third-party softwares for your operating system.

However, since in time most software distribution services have moved to HTTPS download, and it is suggested the rest do the same.

 

fware

Ransomware On Your Website – Is It Possible?

fware ransomware

Ransomware on a website?

Ransomware is popularly thought to affect only PCs, mainly containing older versions of Microsoft Windows, through phishing of login details. Actually, nothing is farther than the truth.

In fact, ransomware can be introduced even into Linux-based web servers / websites without using any phishing techniques, and even if they are behind a firewall.

The above image displays the new homepage of a website on cPanel shared hosting recently locked by ransomware. The image below is a listing of the ransomware-encrypted website files as seen via an FTP client.

fware ransomware file listing

How did the ransomware get in?

Servers are computers available on the public Internet and are required to serve information via multiple protocols such as HTTP/HTTPS, FTP, SSH, etc. This also creates multiple points of entry for attackers in addition to poorly secured entry points in web apps.

In this case, the website had allowed file uploads into directories that (carelessly) had execute file permissions enabled for everyone. In Linux this is the 777 permission. This allowed an attacker to upload the fware encryption PHP code to the website and then cause the code to execute via a web browser call.

What would you do if this happened to you?

How would you be affected if you woke up one morning to see your website that wasn’t available anymore? Even after paying the ransom there is no guarantee of receiving the decryption key and getting back your website files and data.

Luckily, in this case, the webmaster (website manager) for this website had already enabled automated website backups and was able to restore the website quickly. Most webmasters agree frequent automated backups are the best defense against total website loss. So does your website have automated backups?

 

symantec trust issue

Chrome and Symantec – the Final “Trust” Solution

chrome symantec trust issue

The Google Chrome team announced in March 2017 that it had a problem with Symantec for violating industry standards related to SSL certificate issuance. This has been discussed cooperatively over the last 4 months by Google, Symantec, and other members of the internet community. On 27th July 2017, Chrome and Symantec announced their final plan to move forward.

If you operate a website that uses a Symantec SSL certificate, please read this post to see if future versions of Chrome will affect your specific certificate and how you can replace that certificate (for free) before anything goes into effect.

Are you affected?

If you are a current user of Symantec certificates or plan to purchase one in 2017, this could affect you.

As a leading Certificate Authority, there are more than an ideal amount of Symantec SSL certificates will be affected.  Note that Symantec operates multiple brands, all of which are affected:

  • Symantec
  • GeoTrust
  • Thawte
  • RapidSSL

Also, note that Mozilla Firefox will be taking a similar course of action, but at this time they have not committed to a final plan.

What changes are expected in Google Chrome

The two stages of Chrome’s distrust, which serve as deadlines, are marked in RED to clearly show the difference between general information and actionable items.

October 24th, 2017
Chrome 62 will display a message in Developer Tools to help identify certificates which will be affected by distrust in Chrome 66. Visit your websites with the Developer Tools panel open – this will allow you to identify which websites will be affected by distrust in Chrome 66.

December 1st, 2017
A partnered Certificate Authority (CA) will begin issuing certificates for Symantec. As an end user, you may notice some small changes in the issuance process. From a technical standpoint, this date is significant because it marks beginning of the “new” Symantec certificates. Certificates issued after this date will be issued from different roots and will not be affected by Chrome’s dis-trust.

April 17, 2018
All Symantec certificates issued before June 1st, 2016, will no longer be trusted by Chrome.
Certificates issued after June 1st, 2016 are not affected at all in this release. Replace any Symantec certificates issued before June 1st 2016 by this date. This can be done by reissuing your certificate for free from your provider and installing the new certificate in place of the old one. If your certificate expires around this time (April-June) you may want to consider renewing it, instead of reissuing, to avoid two replacements within a short time frame.

Oct 28th, 2018
All certificates issued by Symantec with their existing infrastructure will no longer be trusted by Chrome.
Starting in the stable version of Chrome 62, a message will be added to the Developer Tools panel when a certificate that will be distrusted in Chrome 66 is encountered. Developers can use this functionality to ensure they identify certificates on their websites that will be affected.

Our Recommended Plan of Action

To reduce the amount of disruption and effort required, we recommend the following action:

If your certificate expires BEFORE December 2017

We recommend you renew (instead of reissue) your certificates prior to December. This will allow you to have a trusted certificate in place through the holiday season up until Oct 2018 when all certificate files from Symantec’s existing roots will have an issue and need to be replaced on your website. Alternately, switch over to certificates from a different Certifying Authority (CA) such as Comodo to avoid any issues.

If your certificate expires DURING December

Symantec hopes to have their partner CA issuing certificates on December 1st (a Friday). If you can wait to reissue and replace your certificates until after this occurs, you will most-likely never need to replace your certificate files on your website until their natural expiration date.

However, note that delays may occur which require Symantec to miss the December 1st estimate, and there may be an unusually high volume of issuance at that time which could cause technical issues.

If that is the case, if you are close to the expiration of your current certificate you may risk outages. ‘Holiday freezes’ may also prevent you from replacing certificates during this month.

If you do need to replace your certificate before Symantec’s partner CA is ready to issue certificates, you will need to replace the certificate files again before Chrome 70’s release (expected late Oct 2018).

Alternately, you can switch over to certificates from a different CA such as Comodo to avoid any issues.

If your certificate expires AFTER December 31st, 2017

We recommend you wait to replace any of your certificates until Symantec’s partner CA begins issuing certificates (expected December 1st, 2017). After this date you can begin reissuing and replacing certificates as needed. This way you need to replace your certificate files only one time.

Certificates issued by Symantec’s partner CA will not be affected by Chrome’s changes and will not need to be replaced until their natural expiration.

Special Case: If your certificate was issued BEFORE June 1st, 2016 and expires AFTER April 17th, 2018

You fall into a special case. Your certificate must be reissued and files replaced BEFORE the release of Chrome 66, which is expected April 17th, 2018 in order to remain trusted in Chrome.

However, you should wait until after December 1st 2017 to reissue your certificates. On this date, Symantec’s partner CA will begin issuing certificates. By waiting until this date you will only need to replace your certificate one time.

If you reissue before Symantec’s partner CA is available, your certificate will come from one of Symantec’s current root certificates and will need to be replaced against before October 2018.

UPDATE: Mozilla Firefox will follow more or less the same timelines as Google Chrome.