After getting a satellite contact via SO-50 the next thing was to get it in the log correctly. I followed the instructions from Logging Satellite QSOs with Logbook of the World - Amsat, logging the contact in the tqsl program, uploading that log to Logbook of the World and importing the logfile (ADIF) into CQRLOG later.

But later I found out that CQRLOG now supports satellite logging after enabling it in the preferences. Since version 2.3.0 satellite support is included.

This evening I checked 'Sky at a glance' in gpredict and saw a nice SO-50 pass come up. It was a southwest - northeast pass with a very high maximum elevation. So a good chance to listen to the satellite for a while. I took the Arrow antenna together with the Wouxun handheld radio outside, which I programmed for the SO50 frequencies when I started with amateur satellites years ago.

I started hearing the satellite right after it got above the houses. I heard one familiair callsign: Peter 2M0SQL. In a silent moment I answered his call, he heard me fine and we had a contact.

My first satellite contact since August 2014 and directly someone in the log who I really wanted to get in the log.

Saudisat 1c / SO-50

Tuesday evening we had a good presentation at our radio club about getting active on the QO-100 geostationary amateur satellite. This was a very technical presentation by René Stevens PE1CMO. This amateur satellite is actually a transponder on the Es'Hail2 satellite. The transponder is active on amateur bands: 2.4 GHz up and 10 GHz down.

A very interesting and good presentation. And for now I find it very interesting but I'm not going to invest the time and money to get on that satellite.

This did remind me that I wanted to get back into amateur satellites as planned for several years. Looking back I see a clear moment when the satellite activity stopped: The last successful amateur satellite contact was 2014-08-10: Success with the new radio and the SO-50 amateur satellite and the first HF contact was 2014-08-29: First PSK31 on HF contacts. It's easier to make a lot more contacts on HF for the same amount of work as one satellite contact.

As a first step I took out the arrow antenna and a handheld radio just to listen to some passes. And that showed the well-known problem with satellite passes: They have to fit in your schedule or otherwise you will miss them completely. But there are a lot of amateur satellites to listen to. I had two Fox-1A (AO-85) passes not higher than 23 degrees elevation. And I heard nothing on those passes, but that wasn't a big surprise given earlier experiences and what people have shared. I had one pass of Saudisat (SO-50) which went up to 29 degrees elevation and I heard at least a few callsigns on that pass. And no really bad behaviour, but maybe a Wednesday daytime is better in that regard.

With all the automated updates of certificates as described in Enabling Server Name Indication (SNI) on my webserver and Automating Let's Encrypt certificates further I wondered about what would happen when some things got corrupt, most likely as a result of a full disk. And a simple test showed out that the checkcert utility would happily say two empty files are a match because the sha256sum of two empty public keys is the same.

Solution, do something with the errorlevel from openssl. New version of checkcert:

#!/bin/sh

# check ssl private key 1 with ssl pem encoded x509 certificate 2 public key

SUMPRIVPUBKEY=`openssl pkey -in $1 -pubout -outform pem || echo privkey | sha256sum`
SUMCERTPUBKEY=`openssl x509 -in $2 -noout -pubkey -outform pem || echo pubkey | sha256sum`

if [ "${SUMPRIVPUBKEY}" = "${SUMCERTPUBKEY}" ]; then
        exit 0
else
        exit 1
fi

And now:

koos@gosper:~$ /usr/local/bin/checkcert /dev/null /dev/null
unable to load key
139636148224064:error:0906D06C:PEM routines:PEM_read_bio:no start line:../crypto/pem/pem_lib.c:686:Expecting: ANY PRIVATE KEY
unable to load certificate
139678825668672:error:0906D06C:PEM routines:PEM_read_bio:no start line:../crypto/pem/pem_lib.c:686:Expecting: TRUSTED CERTIFICATE
koos@gosper:~$ echo $?
1

Just seen in an e-mail with a virus, looking like it's something from a bank:

Security tips

1. Install virus detection software and personal firewall on your computer. This software needs to be updated regularly to ensure you have the latest protection.
2. To prevent viruses or other unwanted problems, do not open attachments from unknown or non-trustworthy sources.
3. If you discover any unusual activity, please contact the remitter of this payment as soon as possible. 

But the attachment has malware.

While making a lot of my websites available via HTTPS I started wondering about enabling Server Name Indication (SNI) because the list of hostnames in the one certificate (subjectAltName parameter) keeps growing and they aren't all related.

So on a test system with haproxy I created two separate private keys, two separate certificate signing requests and requested two separate certificates. One for the variants of camp-wireless.org and one for most of the idefix.net names. The whole requesting procedure happened on the system where my automated renewal and deployment of LetsEncrypt certificates with dehydrated happens so the request went fine. For the configuration of haproxy I was following HAProxy SNI where 'terminating SSL on the haproxy with SNI' gets a short mention.

So I implemented the configuration as shown in that document and got greeted with an error:

haproxy[ALERT] 123/155523 (3435) : parsing [/etc/haproxy/haproxy.cfg:86] : 'bind :::443' unknown keyword '/etc/haproxy/ssl/webserver-idefix-main.pem'.

And found out that the crt keyword has to be repeated.

This is why I like having a test environment for things like this. Making errors in the certificate configuration on the 'production' server will give visitors scary and/or incomprehensible errors.

So the right configuration for my test is now:

frontend https-in
    bind :::443 v4v6 ssl crt /etc/haproxy/ssl/webserver-campwireless.pem crt /etc/haproxy/ssl/webserver-idefix-main.pem

And testing it shows the different certificates in use when I use the -servername parameter for openssl s_client to test things.

$ openssl s_client -connect testrouter.idefix.net:443 -servername idefix.net -showcerts -verify 3
..
Server certificate
subject=/CN=idefix.net
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
..
Verification: OK
$ openssl s_client -connect testrouter.idefix.net:443 -servername camp-wireless.org -showcerts -verify 3
..
Server certificate
subject=/CN=www.camp-wireless.org
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
..
Verification: OK

The certificates are quite separate. Generating the certificate signing requests with a separate private key for each request works fine.

So if I upgrade my certificate management to renew, transport, test and install multiple certificate for the main webserver it would work.

I participated in the British amateur radio teledata group RTTY Sprint75 contest 2019. The special thing with the 75 is that this is 75baud RTTY and not the normal 45baud RTTY.

This is a relatively short contest (4 hours) on a Sunday evening and I did not participate in the contest the whole time, I also watched some television with my family. All a matter of priorities.

I made 27 contacts on the 20 and 40 meter bands. Since I now have an RF power meter I was able to make sure my output power was right below 100 watts so I could enter in the '100 watts' category and not 'high power'.

We hebben nu net een regenachtige dag achter de rug, waarop we ook nog de oven gebruikt hebben voor zowel de lunch als het avondeten. Over deze dag hebben we nog steeds wel wat teruggeleverd, maar niet zo veel als op een echt zonnige dag, en het gebruik over de hele dag was ook relatief hoog.

Ondanks de regen was het niet echt donker overdag, dus dat kan nog voor minder opbrengst zorgen.