I recently stumbled over a problem on my notebook running Ubuntu 16.04 “Xenial Xerus”. When trying to connect to a new, protected Wi-Fi network no password dialogue appeared, making a quick GUI connection impossible. Creating the connection manually, entering the Wi-Fi password in the “Wi-Fi-Security” setting in the process worked like a charm. Using nmtui from the terminal also worked flawlessly.

As I didn’t connect the notebook to new Wi-Fi networks in months, I didn’t encounter this error for a long time. Therefore I had a lot of problems debugging it as I installed bazillions of updates and new packages in the meantime.

I narrowed the problem down to NetworkManager not having a way of saving the Wi-Fi password, which is normally done via gnome-keyring, specifically via gnome-keyring-daemon. The daemon didn’t seem to start properly, but even starting it manually still didn’t make a difference. The logs still complained:

Okt 17 06:58:53 XPS13 NetworkManager[1064]: <info>  [1508216333.3058] device (wlan0): Activation: (wifi) access point 'MyTest' has security, but secrets are required.
Okt 17 06:58:53 XPS13 NetworkManager[1064]: <info>  [1508216333.3062] device (wlan0): state change: config -> need-auth (reason 'none') [50 60 0]
Okt 17 06:58:53 XPS13 NetworkManager[1064]: <warn>  [1508216333.3062] device (wlan0): No agents were available for this request.

Finally I found the solution in an askubuntu question. Nearly half a year ago I installed Flatpak so I could install FeedReader. One of the dependencies was dbus-user-session. This package seems to have problems with the gnome-keyring-daemon in 16.04 rendering it defective. Purging the dbus-user-session package and its dependencies solved my problem and the Wi-Fi password dialogue appeared once again.

apt purge dbus-user-session xdg-desktop-portal xdg-desktop-portal-gtk

I still had a problem with the NetworkManager applet in the tray, but this could be fixed with an apt install --reinstall network-manager-gnome and a reboot afterwards.

Nearly two months ago I published my OpenSSL scribblings post. This one is the spiritual successor, addressing Java Keystore handling this time. There are already a lot of good web sites on how to handle the keytool, so I will limit myself to the issues I encounter from time to time which are more difficult to figure out. Similar to the last post I will use COMODO as CA and ssl.example.org as domain.

Adding a new certificate to a keystore

Requirements:

• The full certificate chain
• The certificate itself
• The certificate private key

First concatenate the cert chain if not already in one file. A Comodo speciality is the occasional inclusion of Windows line breaks, so we use sed for output to substitute any occurence of these. Additionally we ensure that the certificate starts on a newline:

sed -e 's/\r$/\n/g' root-ca.pem intermediate-ca.pem > cabundle.pem

I’m currently running a couple of tests with Docker swarm mode on Scaleway. For those who don’t know Scaleway, it’s a PaaS provider which is part of online.net. Due to capped maximum prices per month and no Ingress/egress prices it’s good for smaller projects.

But small prices often also mean a couple of limitations as well. In my case I wasn’t able to run Docker swarm mode properly. I tried running a stack with a couple of web servers and Traefik as Reverse Proxy, but for some reason this didn’t work. When running a Traefik container manually in Docker, everything worked fine. But as soon as I tried using it in swarm mode context, there was no connectivity. Dockers logs showed some strange errors similar to these:

Apr 14 20:39:40 <hostname> docker[15787]: time="2017-04-14T20:39:40Z" level=error msg="Failed to write to /proc/sys/net/ipv4/vs/conntrack: open /proc/sys/net/ipv4/vs/conntrack: nno such file or directory"
Apr 14 20:39:40 <hostname> docker[15787]: time="2017-04-14T20:39:40.154260407Z" level=error msg="Failed to add firewall mark rule in sbox ingress (ingress): reexec failed: exit status 8"
Apr 14 20:41:17 <hostname> docker[15787]: time="2017-04-14T20:41:17.432619182Z" level=error msg="Failed to delete real server 10.255.0.3 for vip 10.255.0.2 fwmark 259 in sbox ingress (ingress): no such process"
Apr 14 20:41:17 <hostname> docker[15787]: time="2017-04-14T20:41:17.432762944Z" level=error msg="Failed to delete service for vip 10.255.0.2 fwmark 259 in sbox ingress (ingress): no such process"

From time to time I need to test the connectivity of applications listening on a port which has not yet been opened in the firewall. Therefore I use iptables to redirect an open port to the port the application is listening on. Lets assume I want to redirect port 80 to 8080 and port 443 to port 8443. Here’s how to do it:

First enable IP Forwarding

sysctl -w net.ipv4.ip_forward=1

Afterwards enable the redirection for said ports

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8443

Optional: If you also want to redirect the port on the local machine, you have to set an additional iptables rule

iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-port 8443

This is of course not reboot safe. For reboot safety you need to set ip_forward in the /etc/sysctl.conf or a respective /etc/sysctl.d/ file and use the iptables-restore functionality of your distribution.

PS: This could of course also be used to circumvent firewall restrictions, e.g. to connect to SSH via another port without reconfiguring sshd. Do this at your own risk!

Just a quick writeup from my notes so I know where to look it up if I ever search for it again. In my examples I use Comodo as the certificate authority and ssl.example.org as domain.

Certificate chain verification

There are two scenarios I normally encounter, either verify if the certificate chain is complete or find out where the certificate chain breaks.

Verifying the whole chain

1. Concatenate the certificate chain including the root certificate in one file. From the top of my head I’m not quite certain if order is important, leaf to root worked for me.
2. Do an openssl verify with -CApath /dev/null to prevent taking the systems trust stores into account:

openssl verify -verbose -CApath /dev/null -CAfile concatenated-chain-file.pem ssl.example.org.crt

If the output of the command contains ‘OK’, the chain is complete.