3 Dec 2015

Create Java Keystore Using OpenSSL and Keytool for JBOSS

Last week, I encountered an irritating issue getting JBoss to accept my Java Keystore. The .csr was OpenSSL-generated and the certs were derived from VeriSign. The error I would receive on start:

JBWEB003043: Error initializing endpoint: java.io.IOException: 
JBWEB002000: Alias name 1 does not identify a key entry

The steps below eventually got me up and running. Some parts may look counter-intuitive because instead of converting the keystores to a jks-supported format (doing so kept throwing the above error), I took the certs, put them in an OpenSSL keystore,  and then fed that keystore into the conversion.

In this process, I noticed that creating an empty JKS (JKS = Java KeyStore) would automatically create a key in the new .jks. Though I had my key as alias 1, JBoss would tell me it couldn't find what it was looking for.

If you're running into any of what I'm saying, try the below. If you're here to learn, a keystore is your bag and you want to put your certs in the bag. But there are two types of bags, there is the OpenSSL bag and there is the Java KeyStore bag. They are the two coworkers you have that pretend to like each other, one makes more of an effort to get along with the other,  and deep down, everyone in the office finds dealing with them a little touchy.

Let's start fresh:
1. Concatenate both intermediate and root certs (make sure all your certs are in text format). If you can open all your certs in a text editor and see ASCII characters, you're set. If you cannot, perform the below command on each cert.

# Convert certs from data to text (pem) replacing the values below. Keep track of their names. You need to know which cert is which:

openssl x509 -in <NonTextCert.crt> -inform der -outform pem -out <OutputTextCert.pem>

2. You may not have two intermediate certs. In most cases, you'll have one intermediate (your issuer) and the root certificate (known as the CA - Certificate Authority). In this example, there are two intermediates and a root that we will combine into one file called chain.crt:

cat Primary-Intermediate.pem Secondary-Intermediate.pem VeriSign-Root.pem > chain.crt

To ensure there are no Windows carriage returns in the file, use dos2unix to clean it up:

# Ubuntu:
sudo apt-get install dos2unix

# RedHat:
sudo yum install dos2unix

# Clean up:
dos2unix chain.crt
Here is where the fun begins!

3. Use keytool to generate a Java Keystore. Of course, you'll need the JDK to use the Java keytool. When you create the .jks, a key will be generated inside - a key that we don't want since we have existing keys we want to use. Each command is one line, but I broke the command up at whitespaces to make it easier to read. Change the values to yours.

# Use keytool to generate a jks:

./keytool -genkey -alias tempalias -keyalg RSA -keysize 2048 \
   -dname "CN=johnghawi.com, OU=IT, O=Company, L=Toronto, ST=Ontario, C=CA" \
   -keypass changeit \
   -keystore mykeystore.jks \
   -storepass changeit

4. Remove the unwanted key from mykeystore.jks.

./keytool -delete -alias tempalias -keystore mykeystore.jks -storepass changeit

5. Use 'openssl' to generate a .p12 keystore (the OpenSSL equivalent of a JKS) with all the certs that we will want in the java keystore from above. server.p12 will be the name of the OpenSSL keystore.

openssl pkcs12 -export \
   -out server.p12 \
   -inkey johnghawi-private.key \
   -in johnghawi-public.pem \
   -certfile chain.crt

6. Use keytool to import the .p12 keystore into the java keystore.

# keytool will take the srckeystore server.p12, convert its contents and store it in the 
# original .jks we created in Step 3. By default, the pkcs12 (.p12) keystore entry will be created under alias 1. Instead of supplying the below command with -alias, we will be more precise and explicitly specify the source and dest aliases, should you wish to change it in the destination keystore.

./keytool -importkeystore \
   -deststorepass changeit \
   -destkeypass changeit \
   -destkeystore mykeystore.jks \
   -srckeystore server.p12 \
   -srcstoretype PKCS12 \
   -srcstorepass changeit \
   -srcalias 1
   -destalias 1

At this point, the .jks is ready to use. Copy it to the location you want, secure those permissions and ownership if needed, and specify the keystore in the JBoss config.
# Add the new keystore into the config. Your path may differ.
vi $JBOSS_HOME/<instance>/configuration/standalone-full-ha.xml
Find the subsystem tag that contains 'connector name="https" - this will be the tag that will use the jks for web communications. Your alias in the config below needs to match the keystore alias used during the import as well as password:

<connector name="https" protocol="HTTPS/1.1" scheme="https" socket-binding="https" enable-lookups="false" secure="true" max-connections="900">

   <ssl name="ssl" key-alias="1" password="changeit" certificate-key-file="/app/certs/mykeystore.jks" protocol="TLSv1" verify-client="false"/>


Notice that the config has the keystore passwords stored in plaintext. Usually, this is not a good idea. Encrypted passwords are a topic of their own and out of scope for this tutorial. Anyone with access - legitimate or not - can read the config and password; compromising your keystore. The Vault Tool can be used to encrypt the keystore password that JBoss will use to access the keystore. Take a look at this article in the JBoss documentation: JBossAS7SecuringPasswords

17 Sept 2015

Error Installing mysql-server-5.6 on Ubuntu 14.04 [FIX]

I was trying to install MySQL on one of my VMs late last night and the installation kept failing near the end (and at start up). Eventually, I realized that this system only has 256mb RAM (I have no shame) and that was resulting in the following failure:

start: Job failed to start  
invoke-rc.d: initscript mysql, action "start" failed.  
dpkg: error processing package mysql-server-5.6 (--configure):  
 subprocess installed post-installation script returned error exit status 1  
Setting up libhtml-template-perl (2.95-1) ...  
Setting up mysql-common-5.6 (5.6.16-1~exp1) ...  
Processing triggers for libc-bin (2.19-0ubuntu6) ...  
Processing triggers for ureadahead (0.100.0-16) ...  
Errors were encountered while processing:  
E: Sub-process /usr/bin/dpkg returned an error code (1)
There are a few solutions to working around the failure, this one is the fastest and easiest. No one really wants to hack around the config when they're rushing to get something installed.

I found a simple solution at AskUbuntu and the clever trick was:

On Ubuntu 14.04, I do the following to solve the problem:
Create a 4G swap file:
 sudo fallocate -l 4G /swapfile
Change its permission to only root could access and change:
 sudo chmod 600 /swapfile
Make it swap:
 sudo mkswap /swapfile
 sudo swapon /swapfile

My VM failed at the step in red. The error:
swapon failed: Operation not permitted

But I'm root. What gives?

OpenVZ doesn't allow you to add swap. After all, you are paying by the amount of RAM made available to you. 

Then I came across this post at linux problem solver to create 'fake swap'.  This little script, will solve your MySQL installation failure. Just put the following into a file and name it fakeswap.sh:



NEW="$[SWAP*1024]"; TEMP="${NEW//?/ }"; OLD="${TEMP:1}0"

umount /proc/meminfo 2> /dev/null

sed "/^Swap\(Total\|Free\):/s,$OLD,$NEW," /proc/meminfo > /etc/fake_meminfo

mount --bind /etc/fake_meminfo /proc/meminfo

free -m
 chmod +x fakeswap.sh
Though you don't actually get the swap, MySQL will pass its installation stage. If you're running this on Ubuntu which has bash as the default shell, you'll need to make sure that at step [root@server] sh fakeswap.sh (at the original link) you actually run: