25 March 2016

Setting up a Let's Encrypt certificate on a web hosting account at webgo

The web hosting provider webgo.de  has set up an automatic installation of SSL certificates provided by Let's Encrypt within the web hosting space. There is no need to install any software. The SSL certificate is generated in the Webspace Admin with a few clicks. With that encrypted connections are implemented easily in shared hosting.

1. Prepare the website

Provide access to hidden files

To make things run smoothly it is necessary to pay attention to some points. There will be an automatic generated text file with a content which is predetermined by Let's Encrypt. The text file will be put under the URL www.domain.tld/.well-known/file-name-also-predetermined-by-lets-encrypt. Let's Encrypt checks if the content of the text file (a short mix of characters) is accessible under this URL. Is the content readable by Let's Encrypt, the certificate will be created for www.domain.tld. All that happens automatically.

However, the folder .well-known is a hidden folder, caused by the preceding dot. Some CMS block the public access to hidden folders and files by default due to security reasons.

If that is the case, remove the blocking of hidden folders. Normally this is an entry in the file .htaccess in the root directory of the website installation.

E.g. drupal installations have a default RewriteRule in the .htaccess which looks like this:

#RewriteRule "(^|/)\." - [F]

Commend this line out as above with a # for the length of the installation of the certificate. When the certificate installation is finished, you can delete the #.

If you are unsure if hidden files are accessible, you can just test it easily. Create a text file with a text editor (important, not a word document or similar - the format must be plain text). Write just something, e.g. 'Everything is okay, hidden files are publicly accessible.'. Save it as 'test-file'. Create a hidden folder, e.g. .test-folder (begin with a dot), save 'test-file' into .test-folder, and upload it into the root directory of your website installation. Open a browser and visit the URL www.domain.tld/.test-folder/test-file.

test hidden directory of website in browser

The folder .well-known/file-name-also-predetermined-by-lets-encrypt will be deleted automatically after the installation.

Redirect from domain.tld to www.domain.tld

If there is already a redirect from domain.tld to www.domain.tld or vice versa the redirect must be removed during the installation. This was the case at least for me. I tried it with an existing redirect, but the installation terminated with an error message. The creation of the certificate ran smoothly only after I commented out the redirect in the .htacces. In drupal, the redirect looks like this (non-www to www):

#RewriteCond %{HTTP_HOST} .
#RewriteCond %{HTTP_HOST} !^www\. [NC]
#RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

But there are also different notations possible, e.g.:

#RewriteCond %{HTTP_HOST} !^www\.xyzdomain\.de$
#RewriteRule ^(.*)$ www.xyzdomain.de/$1 [L,R=301]

These lines can also easily commented out with a # as above.

2. Create the certificate in the Webspace Admin

Now the certificate can be created and installed. Log into the Webspace Admin, go to Website administration → SSL and click 'create SSL'.

(I'm not sure, I think the website is only in German. I translate it here, because it might be similar with other web hosting providers).

Select 'Generate with Let's Encrypt', select your domain, and indicate an email address. The automatic renewal can also be selected, which makes the whole process very convenient.

A key bitlength of 2048 is sufficient for most cases. If the key bitlength is doubled to 4096, the decryption takes 6-7 times longer. That is something everybody has to decide for themselves. There is a threat about it Default RSA key bitlength should be 4096.

However, web hosting space is much cheaper than a virtual server or a root server, but server capacity is lower as well.

There should be no entries in the fields CRT, CSR, PrivateKey and CA, just hit the button 'Create'.

generate Let's Encrypt certificate in Webspace Admin

The installation of the certificate was done rapidly in only 15 seconds. This depends of course on the connection. The website is not accessible for a moment, because the web server apache has to be started again. Afterwards https://www.domain.tld can be accessed with a browser.

The webgo support wrote me in an email:

"Since every customer has its own apache, it starts every time if adjustments are made in the Webspace Admin which needs a restart. The websites are not accessible for 1-2 minutes. But that is normal."

When the website is accessed, you should see the lock symbol, and on a click at it 'Secure Connection', and 'Verified by: Let's Encrypt'.

browser check for an encrypted connection

webgo creates a new certificate for each domain. Let's Encrypt has a limit of 5 certificates a week, after that you must wait.

Redirect

My aim was to redirect all URLs for the site to https://www.domain.tld. That meant the http://www.domain.tld (the unencrypted site), http://domain.tld, and https://domain.tld.

Create a certificate for www.domain.tld as well as one for domain.tld. From the view of Let's Encrypt, there can be a number of domains running under one certificate. But in the Webspace Admin you can only select one domain, so you have to do it one after the other.

After the creation and installation of the certificates I activated the redirect from domain.tld to www.domain.tld, by deleting the # in the lines in the .htaccess which I had commented out before.

The redirect from http://www.domain.tld to the encrypted https://www.domain.tld can be done either through an entry in the .htaccess or in the Webspace Admin. Log into your account. Under Website administration → Domain administration edit domain.tld and www.domain.tld. Under 'Redirect automatically http to https' click 'yes'.

redirect domain from http to https

The order is: redirect first from domain.tld to www.domain.tld, and then from http to https; also if you make the entries solely in the .htaccess.

A redirect is a good thing to avoid duplicate content. Let's Encrypt is supported by all major browsers. Here is a list of browsers which support Let's Encrypt.

HTTP Strict Transport Security (HSTS) can added to the .htaccess for additional security:

Header set Strict-Transport-Security "max-age=10886400"

With that a https connection is forced, and this will be cached in the browser for the specified period. Next time the browser connects to the website, all elements will solely called via https - that prevents possible attacks.

The max-age is defined in seconds. If later the website shall be connected unencrypted for any reasons, e.g. certificates shall be canceled, then this line in the .htaccess must be deleted before doing that. Otherwise the call to the site cannot be made.

The cache is valid for all visitors. That means, if later the encrypted connection is taken back, the visitors can not connect to the website as long as the cache is active in their browsers. On the other side a long cache time is useful, because visitors can connect safely after a long absence.

3. Problems with the website

Some of the sites were not displayed correctly and even changes in the .htaccess seemed not to be effective. This was due to the browser cache, and restarting Firefox solved the problem for me. Also the web server apache can be restarted in the Webspace Admin under Server → Apache Status; the error log can be downloaded from there as well.

Mixed Content

At the first call of the encrypted connection to the website the whole design was destroyed, and the browser warned me because of an insecure connection. This was due to mixed content. Some parts of the website are delivered through the encrypted connection, others through the unencrypted http connection. In this case find out exactly which parts of the website run through http. Call the source code of the site. In Firefox this is done with a right click and then select 'View page source'. Somewhere there is a line looking like

href="http://www.domain.tld/for-example/path-to-my-images/image.jpg"

It can be different things, not only pictures and graphics but also scripts. Look if you can call the path with an encrypted connection: copy the path into a new browser tab and edit http to https. I don't have external content, so I could reach everything through an encrypted connection as well. So for me the solution was easy: just to log into my website and clear the website cache. Maybe some settings must be adjusted in the backend of the website, e.g. if content has an absolute path which is specified with the beginning http.

If you have external content, inquire beforehand whether a certification with Let's Encrypt is possible; and if the external content can be integrated with a https connection. Here is another threat about it How will LE be addressing mixed content?

Privacy protection and OCSP with web server Apache 2.2

When the browser requests an encrypted website, for safty reasons the validity of the certificate is checked. The CAs (Certificate Authorities) often maintain lists of revoked certificates, as Let's Encrypt does.

With websites running under web server Apache 2.2 (as this website does), the technique is structured such that the browser of the visitor requests the proof of validity of the certificate at the CA. In this process sensitive data like the IP address, User Agent string and the website to be visited will be transmitted to the servers of Let's Encrypt.

Let's Encrypt does not use the data to identify people. The data is deleted within seven days, or after investigation due to failure or abuse. You may read that under Privacy Policy - Public User.

The transmission of IP information is not specific to Let's Encrypt, but affects other encrypted websites and Certificate Authorities as well. It's a frequent practice, which doesn't make it better though. The only solution is an upgrade to web server Apache 2.4. There the technique is improved in a way that sensitive information of the visitors is not transmitted any more.

4. Conclusion

In my opinion Let's Encrypt is very suitable for smaller sites like the ones running on web hosting services and in shared hosting. They tend to have less external content and less need for wildcard certificates or extended validation. But exactly there implementation is mostly not possible without the support of the web hosting provider.

Well, my compliments for webgo, that they support Let's Encrypt and make a quick and simple implementation possible for the site owners.

I like that with a https connection the privacy of the visitors is enhanced - despite of the flaws with OCSP. Also my website is protected, when I log into the website and work on contents.

 

Update 29.3.16: Added paragraph about HSTS and OCSP.

Add new comment