- Details
-
Created: Sunday, 30 April 2017 11:09
-
Last Updated: Sunday, 30 April 2017 11:09
-
Written by Ingo
Introduction
To supply an SSL certificate for all my domains hosted on this server, I used Let's Encrypt and generated one certificate for the whole server which included all domains hosted there. I currently rent a second dedicated server from Hetzner and instead of ordering a new domain, I took one of the unused ones I already have. Now this domain was configured on my main server when I generated the certificate. I changed the DNS entry for qatal.de and everything worked. Since qatal.de does not have a web presence at the moment, I never configured https there.
Problem
When the main server's certificate came up for automatic renewal, Let's Encrypt tried to verify that the web presence of qatal.de was still available at the previous DNS address (the one of the main server). Certificate renewal failed completely.
Then I discovered that currently (2017-04) there is no easy way to extract one domain from a certificate before renewal. Editing the renewal config file and removing the domains did not help - it still checked for them. Disabling the apache-hosted vhosts did not help - it now complained about those.
Solutions
- revoke the current certificate and issue a new one, without qatal.de
- keep existing setup and revert the DNS change. Use another domain for the second server.
- use a newer version of Let's Encrypt which supports the --allow-subset-of-domains (see: discussion of how to remove a domain from cert).
I decided to do 2) and created reddit.qatal.de for the second server. If I had needed to move a more important domain like dewarim.de to a new server, I would have to use solution 1.
Option 3 is certainly better, but replacing system packages on Ubuntu 16.04 will probably break automatic updates for letsencrypt. If I install my own newer version, I have to be on the lookout for updates, because Ubuntu will no longer manage this for me. Seems like a problem for security related packages...
Generally it seems like a better idea to create separate certificates for each domain separately, but that may be slightly more work (needs a list of domains and a bash loop ;) ).
- Details
-
Created: Tuesday, 14 February 2017 21:40
-
Last Updated: Tuesday, 14 February 2017 21:42
-
Written by Ingo
// posted here so I remember it //
LetsEncrypt offers owners of domains the option to create free-of-charge SSL certificates. Having a blog's login form sending passwords via encrypted channels is a Good Idea, but so far I put it off because previously it was costly and a hassle to get this done.
When the initiative to have SSL everywhere started, the tools were not so great and not all browsers recognized LetsEncrypt. Often they would show warnings about an unknown certificate authority, but by now it looks those things have been solved. There are even a lot of tools and package to get you started quickly for your given web server and host operating system.
sudo apt-get install letsencrypt
will get you started on Ubuntu.
sudo letsencrypt --apache
will give a list of your enabled domains on the Apache web server and ask which ones to SSLify.
Caveat 1: if you are using vhosts, each must be in its own configuration file. This was some work.
Caveat 2: if you are using Joomla, you need to configure it to use SSL - I did simply turn on "force SSL for entire site" and whoops, endless redirect loop.
Since my Joomla instances live inside a virtual machine (KVM), the proxy Apache on the host would serve as a termination to the SSL connection and then send the unencrypted request to the virtualized Joomla. But since Joomla would try to force a redirect to SSL, it would always answer with "hey, you need to encrypt this request" - and the browser would follow the redirect, only to end up in another iteration of the host de-crypting and Joomla complaining.
You need to add a request header to the host Apache:
<VirtualHost *:80>
RequestHeader set X-Forwarded-Proto "http"
…
</VirtualHost>
<VirtualHost *:443>
RequestHeader set X-Forwarded-Proto "https"
…
</VirtualHost>
and add
SetEnvIfNoCase X-Forwarded-Proto https HTTPS=on
to the Apache server's config file inside the VM.
Only that did not work for me, I kept getting either redirect loops or mixed content problem (when some links point to non-encrypted URLs). So my hack is to use
RequestHeader set X-Forwarded-Proto "http"
and a second SetEnvIf for: SetEnvIfNoCase X-Forwarded-Proto http HTTPS=on
on the guest system.
This makes all traffic coming to Joomla look like it's encrypted via https.
Note: this is only secure against MITM because the Joomla VM is on the same machine as the proxy server and does not listen to the internet (all traffic to the VM must originate on the host, in this case the Apache proxy server).
Renewing certificates:
Add a cron file "letsencrypt" to /etc/conf.d folder with:
17 1,13 * * * root letsencrypt renew && /usr/sbin/service apache2 reload17 1,13 * * * root letsencrypt renew && /usr/sbin/service apache2 reload
so it tries two times a day to renew any certificates in danger of expiration. (Tool to create cron expressions: the beautiful Crontab.Guru)
- Details
-
Created: Friday, 04 November 2016 16:53
-
Last Updated: Friday, 07 April 2017 16:59
-
Written by Ingo
The Cinnamon Portable Edition is a way to run a full version of Cinnamon on your Windows desktop without installing any software or configuring your environment in any way.
The current version for download at the Cinnamon's SourceForge.net project page is really outdated, so I have put together a new version. It's a little rough on the edges and does not include a DITA renderer at the moment, but it has all the features of the most recent Cinnamon version.
Download the zip archive of Cinnamon Portable 3.7, use right-click to set the is-secure flag on the properties page (otherwise Windows holds all contained code as suspicious and you cannot run the programs). Then unpack the archive and read the Getting-Started.html page.
Note: the server's background Java process tends to stick around even after termination. You may need to end it via the task-manager.
If you need help or want to provide feedback, please write me an email (This email address is being protected from spambots. You need JavaScript enabled to view it.)
Cinnamon Portable 3.7 Preview edition checksums (to verify the integrity of your downloaded files):
md5sum: 03e1625fe57a58157a43d9b81ea4dbf7
sha256sum: 77de5c153ad34b78c0d044a68a9efd \ b227afbee173a39625c95b429c8ef263b5
- Details
-
Created: Tuesday, 28 June 2016 22:12
-
Last Updated: Thursday, 03 November 2016 17:18
-
Written by Ingo
The newest version of the Cinnamon Enterprise CMS is finished: Cinnamon 3.6
New features
- Microservice-Change-Trigger: You can configure almost all API requests with a pre- or post-trigger which calls a remote web service with all the parameters available to the server at the respective stage.
Possible applications:
- Blocking of API requests. If the remote service sends a non-OK response at the beginning of a request, the Cinnamon API call will not be executed. Use case: validity checks on documents through third party tools (no need to add Grails plugins to Cinnamon, use any language / tool you want to implement custom features).
- Enhancement / modification of parameters. Example use case: ensure that all documents have a valid copyright header - if one is missing, add it prior to storing the content in the repository.
- Trigger render server and other tools: if new content is stored or existing content is updated, you can now start a render server process to generate updated renditions of the content (for example, running a DITA to PDF conversion process which also creates thumbnail images [some customization required])
- Logging of Cinnamon responses to third party tools / services.
- Summary-flag: Many parts of the API have been enhanced to accept summary information on content. This way you can use the client application to easily searchable meta data which can be displayed without fetching the complete content of a document or data item.
- Flag to disable change tracking for system accounts: normally all changes to an object are tracked and the modified date field is updated as well as the modifier data. This caused system accounts (for example the render server) to appear as modifiers on documents where they just updated meta data (thumbnails etc). But when looking at a document, most users want to track human interaction with the content, not modifications by system users. Cinnamon 3.6 allows you to enable / disable this.
Updates
Incompatible Changes
Cinnamon server now uses one repository per installation. Handling multi-database multi-tenancy on each request was more trouble than it was worth, and it was never really used by customers.
Download
- Demo Server VM 3.6.1 (4.7 GByte, includes DITA sample data)
md5sum: f4c4de6d9ac5bfd21639fe3e01873840
sha512sum:945f55294c3cafd0f8b32241a0967e0d05b0d70ce2cf6ee \
4e2b8768bb18db9f66055025b6e4df66ad02ed279833e6fd8cb26f876 \
28c7d73230a4da239ce09b50
- Desktop Client (500 KByte)
md5sum: c01f77e3ee8f15b12b91e41efc6d5fc3
sha512sum: bfe340e9c4f4609046eba60c2d20e13cb5d9dcde45a95 \
6ad8cef7f21c50ce0ab15b411dc94c0edc4b8743ed870d4e9611 \
9ec7adbd6b23b75121aa1f3545df836
- Introductory video for the very first steps once you have downloaded both client and server
The source code for the server and its dependencies is available from the Github repositories:
The source code for the client is available via SourceForge.
The Cinnamon homepage can be found at: http://cinnamon-cms.com
Edit: updated link to new version 3.6.1 (bugfixes, more sample data)
