Installing SSL-certificates on Debian

Installing and configuring SSL certificates is always an issue as how to create them and where to store them. Most of the time people can find the procedure on how to create them, but they forget all the places where they have placed them. Some initiatives exist to have centralized key stores on systems, but getting applications to use them is still a problem.

Also on Debian is this an issue and key material is all over the system if you’re not careful. Some Debian developers tried to fix it, but it ended in a “stalemate” and for now an additional package called ssl-cert exists to create self-signed certificates. This package also provides a structure for storing commercial certificates and accessing them in a safer way. So for we install the package ssl-cert.

$ sudo apt-get install ssl-cert

After installing the package the different files for the SSL-key can be placed in /etc/ssl/private and have the right permissions as shown in the output below. This to protect the key material from being use by unauthorized processes as most keys don’t have a passphrase.

$ sudo ls -l /etc/ssl/private
-r--r----- 1 root    ssl-cert 2766 Dec 12 13:06 www.example.org_ca.pem
-r--r----- 1 root    ssl-cert 1671 Dec 12 13:06
-r--r----- 1 root    ssl-cert 1070 Dec 12 13:06
-r--r----- 1 root    ssl-cert 6268 Dec 12 13:06 www.example.org_intermediate.pem
-r--r----- 1 root    ssl-cert 1675 Dec 12 13:06
-r--r----- 1 root    ssl-cert 3502 Dec 12 13:06

The location and files can only be accessed by the root user or members of the group ssl-cert. Some applications as Apache startup under the root user and access the files before switching to the actual user like www-data on Debian. For those applications nothing is going to change, but for others like ejabberd that run completely under the ejabberd user somethings changes. Those users need to be made member of the group ssl-cert to read the files in /etc/ssl/private. Below two known services are made member of the group ssl-cert to read the certificates.

$ sudo usermod -a -G ssl-cert ejabberd
$ sudo usermod -a -G ssl-cert postgres
$ id -a ejabberd
uid=123(ejabberd) gid=125(ejabberd) groups=105(ssl-cert),125(ejabberd)
$ id -a postgres
uid=105(postgres) gid=108(postgres) groups=105(ssl-cert),108(postgres)

After checking of the modification was in affect as some servers use a Naming Service Caching Daemon the affected services need to be restarted. In this example both ejabberd and PostgreSQL need to restarted before the SSL certificates can be accesses.

Switching to Mozilla Extended Support Releases

At first I wasn’t impressed with Mozilla’s plan for Extended Support Releases for Firefox and Thunderbird, and after sites complained that Firefox 10 was too old it made me switch to the normal release schedule. But now with Firefox 17 being the current ESR and release 24 around the corner it made me rethink everything again. Updating your browser every six weeks sounds fun, but in the end it should just work.

So first stop was Debian that appears to adopt the new ESR strategy and updated their own spin of Mozilla Firefox, Iceweasel, for version 10 to version 17 in their stable release of Debian. The same for Icedove, the Debian spin of Mozilla Thunderbird. Hopefully their testing release will have version 17 soon, but you can grab it from the unstable release without any real issue. I have been using Iceweasel 17 for about three weeks again and experienced no issues browsing the web. So the first step to Firefox ESR has been taken.

The next step it to switch a portable apps installation of Mozilla Firefox to ESR, but for that I have to wait for the next Extended Support Release which is be planned September 17, 2013 and then change the release channel from “release” to “esr” by hand in default\pref\channel-prefs.js. Or I should reinstall the ESR version of PortableApps Firefox now, but for that I need to do some import and exporting of data and settings. We will see what will come first.

WordPress “upgrades”

I have been a long time WordPress user and not very happy with it from time to time, but sometimes you just have to accept certain things. Using WordPress is one of them as it slow became the industry standard for weblogs. It also became the standard for trouble, quick updates and hacked weblogs. As I have to live with it, it became time to take a closer look at WordPress.

While WordPress has a lot of coding errors and that is something that can’t be fixed overnight, but what can be solved is the ability to install additional code. While it sounds a smart move to offers users a way to upgrade WordPress with one click in their browser or to install new plugins or themes, it is also a hazard. If a webserver is allowed to update the application it is running without any trouble, then it simply means anyone who can trick the application to write code to disk and execute it also can host anything he or she wants. A lot of phishing and spam sites do this trick to host their code in some directory of a broken plugin. And the PHP-interpreter always happy to execute any PHP-code it finds, this is a mayor flaw.

For Debian Squeeze there is a backport of WordPress 3.3.2 which matched my version already running. So installing the packages and switching the webservers documentroot to the one supplied by the packages resolved the first issue. Now only the user root can modify the WordPress installation which also include all plugins and themes for WordPress. The base of WordPress now has been secured as remote users can’t modify or install any code. Right? Both yes and no as people still are able to upload content for WordPress and this is something for further review. Most ideally the content will be hosted in an image gallery for example, but it is a risk to accept for now.

Switching to packages also showed something else as most WordPress users just install plugins and themes by using the webinterface. As only root can install new plugins and themes this reduces the choice people have to what the system administrator puts in a package and installs it. Sadly enough now script currently exist for building packages from plugin/theme files and a quick look it appears that this isn’t an issue for themes. But it appears to be an issue for plugins as some developers include an extract from PHP Pear to make sure the plugin always works.

So the coming week I have to spend some time in creating packages and do some coding to make packages work with system provided and updated PHP Pear code. But I still wonder why people write plugins and just copy code to make it “work”. I also wonder how many plugins have outdated code with some funny features or is it something I don’t want to know?

PAM bug hit Debian and others

It has been years since PAM was hit by a serious bug in PAM, but people who upgrade to libpam-systemd version 44-1 can find that sudo stops working. Reading the bugreport on Debian and it doesn’t look promising as it also effects other distributions. For now it may be wise put systemd on hold in case the package transfers from unstable to testing.

A smoother transition in Debian

About a month ago a transition in Debian took a wrong turn for systemd users. This ended in systemd users who where unable to shutdown there system, but recently a newer version was uploaded to unstable solving this issue. So time to unlock the block packages and upgrading systemd to version 37-1.1 and blocked packages.

$ echo "bootlogd install" | sudo dpkg --set-selections
$ echo "initscripts install" | sudo dpkg --set-selections
$ echo "sysvinit install" | sudo dpkg --set-selections
$ echo "sysvinit-utils install" | sudo dpkg --set-selections
$ echo "sysv-rc install" | sudo dpkg --set-selections
$ sudo apt-get install -t unstable systemd libpam-systemd libsystemd-daemon0 libsystemd-login0 bootlogd initscripts sysv-rc sysvinit sysvinit-utils

Only remark after upgrade as for the last time a normal reboot isn’t possible since the system already looks at the new location, but a `halt -f` solves that.