How to check a certificate chain in a jks

This can be done in a number of ways. One common way is to simply but the jks in its environment and see if it works. This is however a little late for my taste. I like to check it BEFORE i put it into a running environment. I will here show 2 ways to check a certificate chain:

  1. Manually check the cert using keytool
  2. Check the chain using openSSL

1. Lets start with the manual check:

keytool -list -v -keystore my.certificate.chain.jks | grep -A 1 "Owner"

This command will list all certifications (and keys) Owner (CN) and Issuer (CN) something like this:

  1. Owner: CN=app.tankmin.se, OU=Secure Link SSL, OU=Tankmin…
    Issuer: CN=Network Solutions OV Server CA 2, O=Network Solutions L.L.C….
  2. Owner: CN=Network Solutions OV Server CA 2, O=Network Solutions L.L.C….
    Issuer: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network…
  3. Owner: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network…
    Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network…
  4. Owner: CN=AddTrust External CA Root, OU=AddTrust External TTP Network…
    Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network…

I have here rearrange them with my application certificate at the top and the root CA certification at the bottom. I have also given every entry a number to easier be able to explain the logic behind the chain.

From here it is pretty simple to see that:

  1. Issuer of my application certificate (no. 1) is Network Solutions OV Server CA 2 and
  2. Issuer of that certificate (no. 2) is USERTrust RSA Certification Authority, and
  3. Issuer of that certificate (no. 3) is AddTrust External CA Root which is the root CA (no. 4)

Since all certificates are linked together down to the root CA the chain is complete. Note: The root CA certificate will always be self-signed

2. And now, if you do not want to do all the above you can use openSSL to verify your application certificate with the following command:

openssl verify -CAfile root.pem -untrusted intermediate.pem application.pem
-CAFile is the root certificate
-untrusted is the intermidiate (if any) certificates
application.pem is your application certificate

The openSSL command above will check the chain to your application certificate and give you a:

application.pem: OK

if all is good

Tested on OpenSSL 1.0.2o 27 Mar 2018 and Java 1.8.0_121

Using netcat to catch request data from cUrl

I recently needed to compare post data from cUrl and webMethods 9.9. The cUrl request worked like a charm but the same request from the pub.client.http service failed to be recognized by the consumer. I then got a tip from a colleague to use the netcat program to catch the output from both programs and compare the results. Here is how I did:

Start a listener on an non-privileged port eg. 8000

nc -l 8000

With this running in one console window we switch to another and run a curl command eg.

curl -F attachment=@file.csv http://localhost:8000

The file.csv in this example is a MIME message

The message is now captured and written to the console like this:

POST / HTTP/1.1
Host: localhost:8000
User-Agent: curl/7.54.0
Accept: */*
Content-Length: 382
Expect: 100-continue
Content-Type: multipart/form-data; boundary=--10e698fa110003d5

----10e698fa110003d5
Content-Disposition: form-data; name="attachment"; filename="file.csv"
Content-Type: application/octet-stream

HELLO WORLD

----10e698fa110003d5--

TIP 1:
Start nc like this:

 
nc -l localhost 8000 &

Now run curl like this:

 
curl --proxy localhost:8000 --silent --max-time 1 http://blog.niklasottosson.com

And you will catch one and one only request

TIP 2:
Start nc like this:

nc -l loclahost 8000 > request.txt 

And you will catch the request in a file called request.txt

Tested on OSX 10.13.6 and cUrl 7.54.0

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