Useful email addresses to setup on your new domain

Through the years there have been many new domains and I have learned that the email addresses below is really helpful to setup on all your domains. One example is when you need to purchase an SSL certificate. Many providers uses email validation and they do not let you set the email address (naturally). They only use the addresses below for the validation process, so having them already setup can save a lot of time

 
administrator@domain.se
hostmaster@domain.se
postmaster@domain.se
webmaster@domain.se
admin@domain.se

Setup IBM MQ v9 AMQP with Java MQLight client over SSL

This “tutorial” will show how I set up a IBM MQ v9 AMQP channel with two-way self-signed SSL certificate. Since it was quite the pain to get to work I will describe the steps here so that I do not have to figure them out again later. Through this tutorial I will use the iKeyman program (<mqserver>/java/jre64/jre/bin/ikeycmd) for handling keystores and certificates. iKeyman is bundled with IBM MQ v9 (and other versions).

A. We start with creating the keystore and certificate needed for the MQ server.
NOTE: The place for the kdb file can be found (and set) in the queue manager setting SSLKEYR (default: /var/mqm/qmgrs/<queue manager name>/ssl/key)

1. ikeycmd -keydb -create -db key.kdb -type cms -pw mysecret -stash
2. ikeycmd -cert -create -db key.kdb -pw mysecret -label ibmwebspheremqmyqm01 -dn "CN=server,O=IBM,C=US" -size 2048
3. ikeycmd -cert -extract -db key.kdb -pw mysecret -label ibmwebspheremqmyqm01 -target server.arm

A word about the label and the keystore name above.The label the server uses can be found in the CERTLABL setting on the channel OR queue manager depending on your setup. I used used the label on the queue manager for this. Default CERTLABL follows the pattern: ibmwebspheremq<queue manager name> all lower case (labels are case-sensitive)
The keystore name comes from the last part of the SSLKEYR setting. In my case the last part is “key” which gives us that the “kbd” file should be named “key.kbd”

B. Create client SSL key and certificate

1. ikeycmd -keydb -create -db client.jks -type jks -pw mysecret -stash
2. ikeycmd -cert -create -db clinet.jks -pw mysecret -label user -dn "CN=user,O=IBM,C=SE" -size 2048
3. ikeycmd -cert -extract -db client.jks -pw mysecret -label user -target client.arm

C. Exchange certificates between client and server

1. ikeycmd -cert -add -db client.jks -pw mysecret -label server -file server.arm
2. ikeycmd -cert -add -db key.kdb -pw mysecret -label user -file client.arm

D. Time to create a new user that the client can use to connect with
* This user needs to be created on OS level since this is what IBM MQ uses to authorise users
* This user should NOT be a member of the mqm group since it would make him a privileged user and privileged users are blocked by default. It is also a good practise to have users that can only interact with specific objects
* The user DOES NOT need login privileges on OS level (/sbin/nologin)

For this example I create a user:

Login 'client1' 
Password: 'password1'

E. Now we need to grant this user some basic privileges, like connect and pub/sub
I am here going to use the setmqaut program but you can also use MQExplorer if you like a GUI

setmqaut -m MYQM01 -t topic -n TOP.CLIENT1.ACCOUNT.PROCESS.SRV0112 -p client1 -all +pub +sub
setmqaut -m MYQM01 -t qmgr -p client1 -all +connect

Now it is time to set up the AMQP service and the channel to access it

F. Start the AMQP service (using runmqsc <queue manager>)

START SERVICE(SYSTEM.AMQP.SERVICE)

G. Create a AMQP channel to use

DEFINE CHANNEL(AMQP.CLIENT1) CHLTYPE(AMQP) MCAUSER('client1') PORT(9090) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA)

This creates a AMQP enabled channel. The channel allows only one user and for this example I will use port 9090 instead of the default 5672. I have also defined the cipher to use for SSL

H. Start the newly created channel

START CHANNEL(AMQP.CLIENT1)

Time to test the setup. For this I use one of the sample programs in the MQLight bundle, namely the ‘Send’ program. Use the following options

mqlight-samples/send -s "amqps://client1:password1@localhost:9090" -t "Account/" --keystore=client.jks --keystore-passphrase=mysecret --no-verify-name

Explanation
* the -s option is simply the connection string. Note that I am using amqps. The ‘s’ at the end enables SSL protected transport using the cipher set earlier and the certificates created
* the -t options defines that we are publishing to a topic called ‘Account’
* then we simply point out the jks to use
* –no-verify-name is needed because of the self-signed certificate

A few troubleshooting tips

* List user personal and signer certificates in jks
  - ikeycmd -cert -list personal -db client.jks -pw mysecret
  - ikeycmd -cert -list ca -db client.jks -pw mysecret
  - ikeycmd -cert -list personal -db key.kdb -pw mysecret
  - ikeycmd -cert -list ca -db key.kdb -pw mysecret
* Make sure all kdb and jks files have 660 rights
* Make sure to restart the AMQP service if changing chiper
* If you have problem with more users able to access the channel then that one specified in MCUSER, check so that CHLAUTH is enabled on the queue manager
* If passwords are not checked by MQ, check the SYSTEM.DEFAULT.AUTHINFO.IDPWOS setting CHCKCLNT - this needs to be REQUIRED for password checks on unprivileged users

Tested on Red Hat Enterprise Linux Server release 7.5 (Maipo), IBM MQ v9.0.5.0 and MQLight library v1.0.2016062300

Telnet in OSX High Sierra?

Yes they decided to remove the Telnet client in High Sierra (10.13). So, what to do? I have found 3 solutions that have worked for my machines

  • Move your old telnet client from /usr/bin on a Sierra machine and to /usr/local/bin on you High Sierra machine
  • Install the ‘inetutils’ package from Macports (sudo port install inetutils) . This contains a Telnet client, among other utilities
  • Switch to the built in nc (netcat) client on High Sierra. Netcat seems to be similar to Telnet but I have only done some simple tests like connecting