Normal communication on internet is not cryphered, the connection between computers can be easily listened to. By using SSL/TLS certificates the communication between computer of user and server, where websites are stored, is cryphered and can't be listened to or be modified on the way.
Visitors of websites have certainty, that data send to server (names, passwords, credit card numbers etc.) are send only to website operator and no third part can access them during the communication.
At the same time with use of HTTPS it is not possible, that for example free wifi hotspot, will insert unwanted data, for example ads or harmful code to websites without the owner of website or visitor knowing.
For more information and specific offer of SSL certificates from ACTIVE 24 visit our SSL offers.
- Let's Encrypt for free
- CSR (Certificate Signing Request)
- Certificates verification
- Certificate installation
- Implementing HTTPS and redirection on Linux hosting
- Implementing HTTPS and redirection on Windows hosting
Let's Encrypt for free
To every Linux hosting we offer for free and fully automatic certificate from certification authority Let's Encrypt. These certificates are trusted in browsers and can be used for full site security.
Issued certificate is valid for 3 months and is automatically renewed at regular intervals. You don't have to worry with certificate updates, which are usually installed manually.
Conditions for Providing Let's Encrypt Certificates at ACTIVE 24:
- They are generating for main name and aliases. Aliases inserted later are automatically involved in certificate within several hours.
- They are not generated for aliases with * - for example *.active24.cz, we only generate a www variant instead www.active24.cz. If the certificate has to be for some not specified subdomain, it is necessary to have alias with specific name.
- The condition for obtaining the certificate is a properly set DNS record pointing to the right hosting server at ACTIVE 24.
- Let's Encrypt does not support so-called IDN domains (accented). For such domains, the certificate will not be issued.
- Domains are verified in databases containing information about malware. If the chosen domain is on list like this, certificate will not be created.
- One certificate can not contain more than 100 aliases.
- When a hosting is established, a self-signed certificate is first generated and replaced with the Let's Encrypt certificate. It can take up to several hours and all conditions have to be fulfilled, before the certificate is created.
- If your own certificate will be installed through customer center, no other attempts to install Let's Encrypt certificate will be made. Renewal of other certificate is directly managed by customer. If you wish to restore Let's Encrypt certificate and its management, contact customer support.
CSR (Certificate Signing Request)
To issue an SSL / TLS certificate, a so-called CSR (Certificate Signing Request) is required. This is a file that contains information about the applicant and is based on the private key of the server. CSR is always generated by server administrator.
CSR for hosting at Active24 with operating system Linux can be generated from customer center (walk through can be found in article Certificate installation), or you can ask as to generate CSR by Authorized request. Together with this request, please provide the information below.
CSR has to contain minimum of these information:
Common Name: Domain name, for which the certificate has to be created, there is difference between domain with and without www. (most common is order of certifitace for domain with www). Organisation: Name of company, for which the certificate should be listed. Locality: City Country: Code of country insert only with capital letters (for example UK) State: State
Walk through for generating CSR on your own server can be found on websites Thawte:
Certificates verification
Before the certificate is issued, the Certification Authority requires to verify the owner. Without this verification, you will not issue a security certificate!
The verification method depends on the type of certificate. Either it is validated only by a confirmation link or it can also be telephoned.
On address active24.co.uk you can choose certificate by verification methods. In general, it can be argued that the more complex the verification of the organization is, the more credible the certificate is
For example, payment portals may require a certificate to be verified by the company by phone.
Domain Validation (DV)
Is verified by customer chosen e-mail from admin, administrator@, webmaster@, hostmaster@ or postmaster@domain.xy.
Other e-mail can not be chosen. Certification authority will send e-mail on chosen address and through link in e-mail the domain will be confirmed.
Organisation Validation (OV)
Certification authority will contact the company, for which the certificate is ordered. They will find the company in publicly available telephone lists, 1188.cz and zlatestranky.cz for ČR, where the telephone number of company can be found, where the order of certificate will be validated.
Calls are made only in English. The company will enter a code on the phone, which must be confirmed in the email.
Extended Validation (EV)
It is the same as verifying the company, but it is much more thorough. Therefore, verification can take longer.
Information is obtained from more sources and sending certified documents is required.
Certification authority will contact the customer on his e-mail, where the customer is informed, what will be needed for the validation.
In addition, the employee's employment relationship, which is listed as an administrative contact in the certificate, is also verified.
Certificate installation
All shared virtual servers with operating system Linux supports function auto-SSL. As a result, you have active access to your site through a secure HTTPS protocol immediately after hosting is created. A self-signed certificate is first generated on the virtual server, and then the system periodically tries to replace the certificate with trusted from Let's Encrypt. It can take up to several hours and it is necessary to fulfill terms for Let's Encrypt creation (the most important to have domain directed on this hosting).
Self-signed and Let's Encrypt certificate can be replaced anytime by your own certificate, in that case the responsibility for regular and current updating of certificate is on server user.
Certificates are on our Linux servers installed by SNI method, where on one IP address is more certificates installed.
In detail of virtual server in Customer center at section Services/Servers and hosting/Details/server settings at option SSL/TLS certificate the basic information about currently installed certificate is shown. You will see the certificate issuer here, the expiration date, and other SSL / TLS management options.
View
The details of the installed certificate are displayed. In the case of a self-signed certificate, the publisher is the domain to which the certificate is issued. For other certificates there is the certification authority that issued the certificate.Replace
Here you can replace the currently installed certificate, order a new one, or generate CSR for hosting.
- Order certificate will redirect the user on our offed of paid certificates. After the certificate is issued, our administrators will install it.
- Create new certificate application CSR for new certificate. Will generate CSR key, which is needed for SSL/TLS certificate creation at another provider.
- Directly upload new certificate: If you have new certificate issued, you can insert it to form easily and update it on server. You just have to follow the installation wizard.
Implementing HTTPS and redirection on Linux hosting
Using "Redirection to HTTPS" option in customer center you can redirect your website to HTTPS by one click. There are four available options:
1) Depending on server settings (implicit option) - does not redirect, but can be changed by ACTIVE 24 in future
2) Disabled - does not redirect and cannot be changed by ACTIVE 24 in future
3) Basic redirection enabled - all requests are redirected to HTTPS, but does not deal with mixed content, so CSS styles or JavaScripts loaded over HTTP won't be interpreted in some browsers, which affects web page layout and functionality.
4) Enabled and deals with mixed content (recommended option) - all requests are redirected to HTTPS and browser is informed to load all site content using HTTPS, which prevents mixed content problems. Parts of website loaded from other domains, which are not available using HTTPS, won't be loaded.
HTTPS is on Linux hosting implemented (as the HTTP itself) by using reverse proxy Nginx, which issue so called TLS offloading.
Traffic between Nginx and Apache is not cryphered and Apache will know about cryphering only from communication. This results in the following limitations for applications that try to verify that they are accessed through secure HTTPS.
- detection in PHP using the variable $_SERVER ['HTTPS']! = 'On' is fully functional - variable $_SERVER['SERVER_PORT'] contains even with use of HTTPS number 80
For redirect to HTTPS using .htaccess it is recommended that you comply with the following conditions while retaining backward compatibility:
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI} [L,QSA,NE]
Header set Content-Security-Policy "upgrade-insecure-requests;"
Added header with "upgrade-insecure-requests" value solves the mixed content problem.
Implementing HTTPS and redirection on Windows hosting
You have to order certificate first on Windows hosting. Automated Let's Encrypt certificates are not available yet on Windows.
When you have your certificate installed, you can redirect website to HTTPS using web.config file this way:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Redirect to https" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" negate="false" />
<conditions logicalGrouping="MatchAny">
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="upgrade-insecure-requests;" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>
Added header with "upgrade-insecure-requests" value solves the mixed content problem.
For more configuration options see web.config file documentation.