Archive for the ‘security’ Category

Working with JKS SSL Keystores…….

Friday, October 25th, 2013

When working with a Java Key Store (JKS) make sure to keep the initial .jks keystore file that you create the certificate signing request from (CSR).

When you create a JKS, it gets seeded with the private key (which you cannot really see or get at it, except with 3rd party tools/utilities). This private key is used to create the CSR, they are related. You cannot use the signed public certificate you get back with any other JKS ! Soemthing like this:

keytool -genkey -alias mystuff -keyalg RSA -keysize 2048 -keystore mystuff.jks -validity 1095 -dname CN=*,OU=IT,O=MyOrg,L=London,T=London,C=GB

The CN= part of the -dname parameters is the url that you wish to encrypt/protect with SSL, make sure you get it correct or your SSL cert will be useless. Provided the above is all good, it will prompt you for a password of at least x6 characters, and then again to confirm. It will then prompt you twice for a password for the -alias that you specified. This should match the password you just used for the JKS keystore. It will then create a file ‘mystuff.jks’ that contains the embedded private key.

From the above JKS keystore, you will need to create a CSR to send away for use to sign your public key cert. Something like this:

keytool -certreq -alias mystuff -keystore mystuff.jks -file mystuff.csr

The -alias must match the -alias used when creating the JKS keystore. Again, this will prompt for the JKS keystore password. When complete, this will produce a CSR file called ‘mystuff.csr’ that you can send to a vendor to sign an SSL cert.

When the signed public key cert comes back, it *may* have chain trust certificated with it. If so, you should simply paste the plain text contents of all the certificates into a single plain ASCII file using an text editor. You should paste them in the order below:

your public key in Base-64 encoded X.509

primary chain cert in Base-64 encoded X.509

secondary chain cert in Base-64 encoded X.509

Save the file as something like mystuff.cer

When you import the public cert, you must supply the same alias name that you used to create the private key and CSR, and the passwords for the JKS and the alias must all match. To import use:

keytool -import -alias mystuff -file mystuff.cer -keystore mystuff.jks

If all goes well, you should have x1 certificate in the store with a chain length of 3. To verify:

keytool -list -keystore mystuff.jks -alias mystuff -v
Enter keystore password:
Alias name: mystuff
Creation date: 21-Oct-2013
Entry type: PrivateKeyEntry
Certificate chain length: 3

The -v output should make it print out the details for all x3 certificates.

If you don’t like command line methods, then this tool is rather good


Check SSL Key Files Match…….

Wednesday, September 4th, 2013

Came across the following commands to check that CSR, PRIV and PUB SSL keys all relate to each other.

Works by extracting the modulus and then MD5’ing it for comparison.

-bash-3.00# openssl rsa -noout -modulus -in priv_key.txt | openssl md5                                    

-bash-3.00# openssl req -noout -modulus -in csr.txt | openssl md5                                         

-bash-3.00# openssl x509 -noout -modulus -in _pub.txt | openssl md5                                   

IE8 Does Not Like SSL Cache-Control Headers…….

Wednesday, July 11th, 2012

Hit a problem today with one of the few Tomcat systems we host on (there are only a handful thankfully).

Now that I know what the issue is, the message makes sense, but at the time I was pretty confused.

The actual site/application on the system hosts PDF files that can be downloaded. All had been going fine, until the client requested that the whole site be made secure with SSL (see previous post). Now for some reason, when attempting to access any PDF from the site (which only works in IE) I was getting the following.

Was quite confused as none of the log files indicated a problem of any sort, the files definitely existed, and if I ran the same test from my non SSL copy of the system, the PDF files opened just fine.

A bit of research led to the following MS articles:


Some digging with Fiddler, and it started to make sense. The site/app was setting the caching headers to no-cache, and because of the SSL, IE8 was enforcing this to the letter and preventing the streaming/buffering/storing of the file to the temp disk location. When the app was called the file did not exist in the local cache directory, and there’s the confuins alert about being unable to read a file (technically correct, could not read a file from the local file system, not the remote server !)

The fix would seem to be to permit a small cache validation period to allow the document to be stored locally for a time (as opposed tot he IE8 registry hack suggested on the second link, as we could not enforce this on public users browsers).

Adding this to the content.xml top level config file soved the problem

<Valve className="org.apache.catalina.authenticator.BasicAuthenticator"
  disableProxyCaching="false" />

Incidentally, this problem does not happen in IE9.

Apache Header Byte Range DoS Exploit…….

Saturday, September 3rd, 2011

Grrrrr, looks like there’s an unpatched exploit in *all* versions of Apache web server.

Is to do with using header byte ranges which allow http responses to be broken into smaller chunks before sending. You can read about them here and here.

There are multiple workarounds for mitigating the issue that can be read here and here.

And as of 30th August, version 2.2.20 of Apache was released which has mitigation built in (If the sum of all ranges in a request is larger than the original file, ignore the ranges and send the complete file.)

Guess what I’m going to be doing all next week ? :-/…….

Over Zealous Registry Editing…….Damn !

Wednesday, April 21st, 2010

The company where I work produces a web site. In order to make sure it looks ok on as many browsers as possible, we have to keep a few machines around with older OS and broswers versions installed.

Last week, the machine used to test IE6 (now dead and unsupported by Microsoft, but unfortunately while it’s use has stedily been declining since January 2010, there are still over 8% of people using it, so we have to test to make sure it will look right) got infected with the XP Malware 2010 virus.

The virus itself has been well written with a very sincere and genuine looking application interface (see here for pictures etc.). Normally for most computer viri I simply remove their entries from the /Software/Microsoft/Windows/Current Version/Run registry section, delete the binaries and reboot.

But this one went a little further (some do unfortunately). It actually modifies the registry entries that deal with how windows launches .exe binaries. It essentially modified the default open shell open entry to launch itself, with the program you wanted to open as an argument. So if you tried to run notepad.exe, AV.EXE would get launched instead, but AV.EXE would know to run notepad.exe after itself.

I followed to instructions on the site, but not to the letter. I was in a rush and sort of deleted the .exe entries completely. Result, I could no longer launch apps that ended in .exe :o(

I didn’t fancy trying to manually put the correct entried back in, so I had a quick search on google for ‘XP .exe file association’ and found this page.

The whole site is pretty cool with a lot of utils, tips and fixes. Admittedley it seems to all be for XP, but I’m sure some of it could be of use for later Windows versions, or at least provide a starting point.

Doug Knox, I thank you for saving me from having to rebuild an old XP system (hours alone in just trying to find the OS istall disks !!)


Genuine looking interface :o(

Refreshingly Secure…….Part 3

Monday, January 4th, 2010

For the final part of reminding myself how to secure a linux website, I need to include the bit on how to force unsecure traffic to be secure. This is done using rewrite rules to rewrite the url path from http:// to https:// you can make the whole site redirect to secure, or just certain subsections of the site.

To force the whole site secure, you first need to run x2 versions of the site, a secure version listening on port 443 and a non-secure version listening on port 80. You then need a rewrite rule on the port 80 site that basically say if this url is http:// rewrite the url to be https://

The config to do this is below and needs to be included between your <VirtualHost> tags on the non-secure site config

RewriteEngine On
RewriteCond %{SERVER_PORT} !443
RewriteRule (.*) [R]

This basically says if the url is not on port 443 then rewrite the url to be https://blah

As the re-write rules are written using regular expressions, you can actually do some pretty complex stuff, examplex of which you can find here and also here


Refreshingly Secure…….Part 2

Tuesday, December 22nd, 2009

So we now have our private key .key and our public key .crt (or something to that effect).

Now we need include the files in the apache config. place the .key and .crt files where you can find them (I use /etc/apache/ssl-certs/). now you need to edit your apache config file. I’ve included a dummy version below to show you what to add and where.

You will need to add ‘SSLRequieSSL’ in between the <Directory> </Directory> tags to tell apache that the content from this directory should be encrypted, you will also need to alter the port from :80 to :443

You then need to include

SSLEngine on
SSLOptions +StrictRequire
SSLCertificateFile /etc/apache/ssl-certs/
SSLCertificateKeyFile /etc/apache/ssl-certs/
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

to provide the location details for the private key and the certificate to be used.

The whole thing should look something like this


DocumentRoot /var/www/

<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

ErrorLog /var/log/apache/
CustomLog /var/log/apache/www.sporticia.com_access_log common

SSLEngine on
SSLOptions +StrictRequire
SSLCertificateFile /etc/apache/ssl-certs/
SSLCertificateKeyFile /etc/apache/ssl-certs/
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown


Restart Apache (using either ‘apachectl restart’ or ‘/etc/init.d/apache restart’) and you should now be able to browse the site using ‘https://sitename’ and you should have the little padlock icon to indicate the site is secured with an SSL certificate.

Note that while this will permit you to browse the site using https, it will not force the browser to https, if anyone tries to access the site using http they will get a 403 forbidden page.

Next post will show how to force the broswer to use the secure version of the site


Refreshingly Secure…….Part 1

Friday, December 18th, 2009

Grrrrrr, some of our SSL certificates had expired on a linux server today. And, like very time I have to renew an SSL on a linux machine, there was a bit of trial and error as I tried to remember how I did it the last time.

So here’s a refresher for me and notes for anyone doing this for the first time.

SSL uses x2 keys for encryption and decryption. you create the private key on your linux server, and then use this to create a certificate signing request (csr). you then use the csr with a 3rd party certificate authority to create your certificate or public key.

the math involved is pretty heavy but this guy explains it really well using a tiny prime number so you can follow (hopefully).

First, generate your private key on the server using

openssl genrsa -out <sitename>.key 2048

replace <sitename> with the name of your site, this will help you to tell different keys apart. The 2048 at the end says how many bits in size you want the key to be, no smaller than 2048.

Next, we use the private key to create the certificate signing request (csr)

openssl req -new -key <sitename>.key -out <sitename>.csr

openssl will ask you some questions about the csr, important notes:

The country code is ‘GB’ for the United Kingdom, not ‘UK’ !!!!

The ‘Common Name’ is the url for the site you are securing (i.e.

Remember the password you use when you create the csr, you will need it to install the certificate you create from the csr

BACKUP YOUR .key and .crt files
! if you loose them, you will have to start all over again

You can now take your .csr file along to a 3rd party certificate authority (Thwate, Go Daddy, VeriSign etc. etc.) and use it to generate your private key (.crt or certificate file).

Next post will explain how to use the keys with apache to secure the site.