voipmeister.com voip stuff matters and more

Tech category

SSL revisited (part 1 - CAA)

A little while ago I wrote about improvements in the SSL configuration of my webserver. You can read about that here.

I decided to check my SSL configuration with Qualys’ SSL Server Test again to see if there was room for improvement. Sure enough, there was.

The report

The report was still A+. However, I noticed two items that could possibly improved upon:

  • No DNS CAA - I’ll address that in this post
  • Weak 3DES ciphers - I’ll write another post about this

The cause

I had not yet implemented Certification Authority Authorization (or CAA), since I didn’t know what it was. The link in the SSL Labs report provides more information. In short, the PKI ecosystem is provided with a new control mechanism to restrict which CA’s may issue certificates for a specific domain. All you need to do is list the CA’s that you use for a specific domain in new CAA DNS record for that domain.

As of September 8, 2017, upon issuance of a new certificate for a domain, the CA is supposed to check the CAA records for that domain. If there is no matching CAA policy for the CA, the issuance should be denied (and it MAY be reported if the domain holder has iodef CAA record(s)).

From the RFC:

If the domain name holder specifies one or more iodef properties, a
certificate issuer MAY report invalid certificate requests to that
address.  In the following example, the domain name holder specifies
that reports may be made by means of email with the IODEF data as an
attachment, a Web service [RFC6546], or both:

$ORIGIN example.com
.       CAA 0 issue "ca.example.net"
.       CAA 0 iodef "mailto:security@example.com"
.       CAA 0 iodef "http://iodef.example.com/"

For those of you who want to have more in-depth information, see RFC 6844.

The solution (or: how to implement CAA)

In my case, for voipmeister.com, I am using Let’s Encrypt as the CA for my certificates. So, if I want to implement a CAA policy, all I need to do is add DNS records like this:

The second one tells any interested party that I only use Let’s Encrypt as my CA. The first record is a request to inform me at a specific email address upon violations or problems concerning certificate issuance. I created those DNS records by hand, but you may also use the SSLMate CAA Record Helper.

After we wait a while for the recent DNS change to take effect, we can recheck with the SSL Labs Tester. The result is this:

Do notice the extra green bar pertaining to CAA, and see the DNS CAA information in the details:

Auto-renewal of Let’s Encrypt certificates

The other day, I was in the process of moving my blog to Pelican, a static site generator. Browsing for some themes I stumbled upon Pelican Alchemy, which led me to the site of the Nairobi GNU/Linux Users Group, where I found some nice blog posts.

One in particular caught my eye and I intend to investigate it later this weekend: Using systemd Timers to Renew Let’s Encrypt Certificates.

Looks nice, and very useful for my webserver on which I have a bunch of Let’s Encrypt certificates installed. Automating the renewal sounds appealing and it was already on my list of ‘things to look into’.

Switching to Pelican

I was already looking for a Wordpress and Ghost replacement. Since I started developing in Python on my Mac, I have been visiting Justin Mayer‘s site Hacker Codex. The virtual environment examples showed me how to install Pelican and curiousity got the better of me.

Today, I managed to successfully generate my first static site (yay!). I ran into some things along the way, which I will document here later. For now, I’m pleased that everything works and that I got to know how to obtain the theme I liked (thanks Justin). By the way, that theme is called Pelicanyan.

So far, I like the geekiness of Pelican, and the lack of moving parts like databases and such. I intend to move all my blog posts to Pelican, but have to figure out how it’s done best. Most of them are Wordpress posts, the latest ones have been written in Ghost. Also geeky, but I can’t get used to working with ghost under the hood…

Change the USG LAN IP before adoption

I recently bought an Ubiquiti USG and had to ‘adopt’ it into an existing network, using a 10.0.0.0/24 subnet.

This requires the default ip address on the USG of 192.168.1.1/24 change to an ip address that can be reached on the existing network. To be more precise, the Unifi controller needs to be able to reach the USG in order to be able to adopt it.

  • Connect a laptop or desktop to the USG on the LAN1 port, make sure the nic is setup to receive an ip address via DHCP
  • Ping the USG to see whether it’s reachable: ping 192.168.1.1
  • SSH into the USG with the user ubnt and the password ubnt
  • Issue the commands below to change the ip address of the USG:
configure
set interfaces ethernet eth1 address 10.0.0.1/24
delete interfaces ethernet eth1 address 192.168.1.1/24
commit
save
  • The SSH session wil drop and you can connect the USG to the existing network.

Another password manager

I was still using KeePassX 0.4.4 on my Mac. This version doesn’t support the Retina display on my Mac, but it wasn’t annoying enough to upgrade/migrate. One of my colleagues mentioned KeePassXC (https://keepassxc.org/), so I decided to give it a test drive.

Be sure to download the digest file as well and compare the digest against:

cat KeePassXC-2.2.0.dmg.DIGEST && shasum -a 256 KeePassXC-2.2.0.dmg

The result should be the same:

d5dec4a01b0fa00f36ebbd8d001ad24a1559d7f897af3d9a2fbdb339b02086bc  KeePassXC-2.2.0.dmg
d5dec4a01b0fa00f36ebbd8d001ad24a1559d7f897af3d9a2fbdb339b02086bc  KeePassXC-2.2.0.dmg