How to verify whether a private key matches with the SSL certificate ?

This is a very common question that comes to our mind while setting up SSL in our applications. How to verify whether the key matches with the SSL certificate ?

A very easy way to verify that is given below.

We need to compare the modulus of the certificate against the modulus of the private key.

Execute the below command to get the modulus of a certificate.

openssl x509 -noout -modulus -in mycertificate.crt | openssl md5

This will generate the modulus something like e091f305089662689d62126d49910031 

Execute the below command to get the modulus of a private key.

openssl rsa -noout -modulus -in mykey.key | openssl md5

This will generate the modulus of the private key. You should get the key modulus as same as certificate modulus above. i.e e091f305089662689d62126d49910031

If both the modulus are same, we can say that the certificate and the key are matching.


Creating Private key in PPK using Private Key in PEM

When we create Amazon instances, we will get key as .pem file. But for logging in to the instances directly using putty, we need the private key in .ppk format.
For creating the private key in ppk, we need puttygen. Puttygen is available with the full bundle of putty. The steps are mentioned below.

1) Be ready with the private key in .pem format

2) Open the Puttygen and click on the top left option File and import the private key in .pem format.

3) Then it will be opened.

4) Choose a passphrase if required (optional)

5) Click on save private key option and save it as .ppk format.




Accessing Unix Server through Putty using Private Key

Type hostname or ipaddress


Then in the left side part of putty, click on SSH and expand.


Then you can see a section auth

Click on auth


There you will get a window with browse button.


Load your private key file (.ppk) and press open.

Then enter username and passphrase-key (if given) and login

This is the method we usually use to login to unix  cloud instances .

Creating a Public and Private Key using PuttyGen

On a Windows machine, you can use PuttyGen to generate a public/private key pair.

PuttyGen can be downloaded from

The private key is what you need on the client machine – for use with Putty for example. The public key goes to the host machine.

Open PuTTY Key Generator (puttygen.exe in the putty folder) which should look something like this.


PuTTYGen supports 3 key types:

  1. SSH-1 (RSA),
  2. SSH-2 RSA, and
  3. SSH-2 DSA

SSH-2 contains more features than SSH-1. SSH-1 has some design flaws which make it more vulnerable than SSH-2. Only choose SSH-1 if the server/client you want to connect to does not support SSH-2. The default SSH-2 RSA is probably better than SSH-2 DSA.

The Number of bits in a genereted key sets the size of your key, and thus the security level. For SSH-2 RSA, it’s recommended to set this at a minimum of 2048. PuTTYGen defaults to 1024. Setting this to 4096 would provide an even stronger key, but is probably overkill for most uses.


Click Generate to start the key generation. You will see something like the figure below ( move your mouse as suggested above the progress bar):


The result of the key generation is shown below. (in the box labelled Public key for pasting into OpenSSH authorized_keys file).


The Key comment enables you to generate multiple keys and easily tell them apart. It’s general recommended to set this to username@hostname, where the username is the username used for login, and hostname is, as it says on the tin, the name of the host machine. For example, for a user ‘amal’ on domain ‘’, set this to

The Key passphrase is an additional way to protect your private key, and is never transmitted over the internet. The strength of your key is not affected by the passphrase in any way. If you set one, you will be asked for it before any connection is made via SSH . Setting it might gain you a few extra moments if your key falls into the wrong hands, as the culprit tries to guess your passphrase. Obviously if your passphrase is weak, it rather defeats the purpose of having it.

If you don’t want the passphrase key, you can leave it empty.

Note that if your set a passphrase and forget it, there is no way to recover it. When you reload a previously saved private key (using the Load button), you will be asked for the passphrase if one is set.

Here is what PuTTYGen looks like after editing the key comment and the passphrase.


Now save your keys – one private and one public – using the Save private key and Save public key buttons respectively. You can save the public key in any format – *.txt is good. The private key is saved in PuTTY’s format – *.PPK. PuTTY will need this private key for authentication.



The public key in the highlighted box is all in one line as expected by OpenSSH, and is in the correct format (unlike the version you just saved). If you are using OpenSSH, this is what you paste in your .ssh/authorized_keys file.

SSH Key based access to Unix Servers

Access to Linux and Unix systems via Secure Shell (SSH) is standard practice.  It offers encrypted access to enable you to administer your server which is vital over the big bad internet.

There are different ways to access SSH: password, user keys and host-based keys.  Passwords are the most common but are less secure than key-based access.  Passwords are susceptible to keylogger attacks, as well as more likely to fool users into a “man-in-the-middle” attack (one where you think you’re logging onto your server, but you are actually proxying your connection through another server which has been compromised and is recording every keystroke and data transfer.)

Key based access is more secure as it requires two parts of a key to be present before access is granted.  When dealing with cloud based services such as Rackspace and Amazon Web Services, key based access is enabled by default.  Key based access is also known as “passwordless access” as access is granted by your key, not by asking for any passwords.  The exception to this is if you put a password on your key (but you can enable services that ask for this password once and it is cached for the rest of your session).

Setting this up on your Linux server is very simple, and most installations of SSH (OpenSSH) enable both password and key-based access by default.  Let’s assume user@client needs to access user@server

Ensure OpenSSH is installed on your Linux server (server)


sudo apt-get install openssh-server

CentOS/Fedora/RedHat/Oracle Enterprise Linux

sudo yum install openssh-server

Ensure the following lines has been uncommented from /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes

Restart OpenSSH


sudo /etc/init.d/ssh restart

CentOS/Fedora/RedHat/Oracle Enterprise Linux

sudo /etc/init.d/sshd restart

On your Linux client (desktop or other server you’ll be using to connect to the server configured in steps 1-3)

Generate your public and private keys

ssh-keygen -t rsa

You will see output like the following:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory ‘/home/user/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/
The key fingerprint is:
79:e1:08:77:c2:0d:c4:ff:35:22:64:9a:4d:03:b8:67 user@client
The key’s randomart image is:
+–[ RSA 2048]—-+
|       ++.                      |
|      …o=                    |
|      ..+O+.                 |
|      .oE*+.. o             |
|       oS oo o .            |
|         .  .                     |
|                                  |
|                                  |
|                                  |

This produces two important pieces of data.  Your PRIVATE KEY (~/.ssh/id_rsa) and your PUBLIC KEY (~/.ssh/  You must keep your PRIVATE KEY safe.  Your public key can be given to anyone.  Without your private key your public key is just a string of characters and you can’t generate a private key from a public key.  Equally, you can’t generate a public key from a private key.  Together they make your key-pair.
To enable your private key to access the server running SSH configured in steps 1-3 (server) you simply copy the contents of your public key onto the server.
Copy the public key from your client machine to server

scp .ssh/ user@server:
(enter your password)

Login to server

ssh user@server
(enter your password)

Copy the public key to authorized_keys

cat .ssh/ >> .ssh/authorized_keys

Change the permission of authorized_keys file to 600 (rw——-)

chmod 0600 .ssh/authorized_keys

This creates the directory .ssh/ and relevant authorized_keys file with the correct permissions (anything less strict will not work).  You can put in a number of public keys in here, line-by-line.  When there are multiple entries it allows multiple people to connect to that account using their keys.  This becomes useful when a team of system administrators require access to systems with minimal accounts installed, but each are accountable for audit purposes as to who logged onto the system.

Log out of that session and log back in again and you shouldn’t be asked for a password.