Posts Tagged ‘mismatch’

Howto Verify an SSL certificate and it private key do match

Monday, March 17th, 2025

Howto Verify an SSL certificate and it's private key do match ?

ssl-verify-pem-and-key-certificate-howto

 

In this article I'll show you how can you verify SSL generated certificate match with its private key. This is mostly useful as sometimes installing signed SSL certfificates might mismatch the key and the result is an SSL mismatch that prevents the supposed encryption of the service from end user to the service to work as expected.
 
I assume you already have properly issued and signed SSL certificate and the private key you used to issue the certificate as well as the entire certificate chain CA and root CA, as well as the certificate.

Requirements

You must have the following item :

  • the signed SSL certificate
  • the certificate's private key
  • the entire certification chain (intermediate CA and root CA)

1. Procedure to verify certificate .crt and .key file match

The following procedures can be used to ensure the given certificate/private key are valid.

Private key verification

  • compute the private key modulus

 

$ openssl rsa -in  certificate.key -modulus -noout | openssl md5

(stdin)= e5220727Acc5396139823018773d55db

 

  • compute the certificate modulus

 

$ openssl x509 – in   certificate.crt -modulus -noout | openssl md5 (stdin)= e5220727Acc5396139823018773d55db

 

  • the private key and certificate modulus md5 must match


How to verify Private key verification (one liner command)

The following command should return 'OK'

 

$ [[  "$(openssl rsa -in your_company_private_key.key -modulus -noout | openssl md5)"   ==  "$(openssl x509 -in and_your_company_private_key.crt -modulus -noout | openssl md5)"   ]] && echo OK || echo NOK

 

2. CA (Certificate Authority)  chain verification

Execute the following command, The certificate.ca should contains the entire CA chain (intermediate CA + root CA)

 

$ openssl verify -CAfile certificate_file.ca certificate.crt: OK

 

3. Expiry date verification of SSL certificate

 

$ openssl x509 – in   certificate_file.crt -noout -startdate -enddate

 

4. Verify the expiry date of a running web service online or in private net

 

$ openssl s_client -connect your-remote-service.com:443 2> /dev/null  | openssl x509 -noout -startdate -enddate

notBefore=Oct 5 00:15:00 2024 GMT
notAfter=Oct 18 23:59:59 2026 GMT

 

If the service provide several certificate with SNI you should use this command to get back the good certificate. You have to set the subject certificate you want to get back

 

$ openssl s_client -connect www.your-remote-service.com:443 -servername srv.your-remote-service.com 2> /dev/null

| openssl x509 -noout -startdate -enddate

notBefore=Oct 5 00:15:00 2024 GMT
notAfter=Oct 18 23:59:59 2026 GMT

 

Sum up what learned ?

In this short article we learned how to verify .crt and and .key file does match, how to do a chain verification of SSL cert, how to check the expire date of a certificate, as well as how to use the openssl command to verify whether installed certificate on a web service is set and working.

How to fix unfixable broken package dependencies on Debian GNU / Linux – Fix package mismatch

Wednesday, September 27th, 2017

how-to-fix-unfixable-broken-package-dependency-on-debian-ubuntu-linux-icon

I just tried to upgrade my Debian Wheezy 7 to the latest stable Debian Stretch 9 by not thinking too much and just changing the word wheezy with stretch in /etc/apt/sources.list so onwards on it looked like so:
 

cat /etc/apt/sources.list

 

deb http://ftp.bg.debian.org/debian/ stretch main contrib non-free
deb-src http://ftp.bg.debian.org/debian/ stretch main

deb http://security.debian.org/ stretch/updates main
deb-src http://security.debian.org/ stretch/updates main 

# stretch-updates, previously known as 'volatile'
##deb http://deb.debian.org/debian/ stretch-updates main
deb-src http://deb.debian.org/debian/ stretch-updates main

 

I also make sure all the defined Google Chrome / Opera / Skype and Squeeze Backports repositories existent in /etc/apt/sources.list.d directory files which in my case were like so;

 

root@noah:/etc/apt/sources.list.d# ls
google-chrome.list  opera-stable.list  squeeze-backports.list
opera.list          skype-stable.list


 were commented out because they were producing extra apt update errors …

And afterwards ran as usual:

 

apt-get update
apt-get –yes upgrade


The upgrade command executed fine and a lot of packages got downloaded and reinstalled without much issue, so I thought everything would be fine and just proceeded with the attempt to finalize the distribution major release 7 to major release 9 by running:

 

apt-get –yes dist-upgrade


But guess what now I got some dependency errors with cron and other installed packages that depend on package versions that are not going to be installed as the apt-get tool informed me.

I tried to out-smart the dpkg dependency system and removed all the packages reporting to have a missing dependencies with a short for bash loop after duming all the problematic packages showing dependency issues with commands such as:

apt-get -f dist-upgrade >> out.txt
for i in $(cat out.txt); awk '{ print $1 }' >> to_delete.txt; done


Before proceeding further I had to manually edit few lines in a text editor to remove some of the junk left from apt-get too.

So i was brave and just removed the dependency missing packages with following other for loop:

 

for i in $(cat to_delete.txt); do dpkg -r –force-all $i; done


Now I was hoping that rerunning:

 

apt-get autoremove

dpkg --configure -a

apt-get update -f
apt-get dist-upgrade -f


would no longer complain and I would just install the removed packages in another for shell loop once every other packages gets installed.

But guess what I was wrong … the system entered into another bunch of depedency terribly issues and messed up so badly that there were at least 50 packages reporting to have a missing / broken or uninstallable deb version depedency …

I got totally Angry, I knew already from experience that just trying to jump over while skipping a major release e.g. upgrade Debian 7 to Debian 9, instead of first upgrading to Debian 8 Linux and then upgrading Debian 8 to Debian 9 have always produced the same mess but I was lame and stupid again to f**k it up and I was out of mind swearing (a truly bad habid I'm not proud of) …

So as the notebook with Linux so far was perfectly working with Debian 7 and had a tons of old installed software and I was in a state where if I restart the system it was very likely my Thinkpad r61 laptop won't boot at all, I googled around to find a solution unfortunately without any luck, so finally I used the good old and tested method to DO IT MYSELF and Find the Fix without Uncle Google's help and by God's grace I did, after experimenting a while with the aptitude package / install / remove update tool without much success, finally I find the solution to the totally messed up Debian package dependencies and it all came to a simply reverting back my /etc/apt/source.list to look like following:

 

# deb cdrom:[Debian GNU/Linux 7.0.0 _Wheezy_ – Official amd64 CD Binary-1 20130504-14:44]/ wheezy main

##deb cdrom:[Debian GNU/Linux 7.0.0 _Wheezy_ – Official amd64 CD Binary-1 20130504-14:44]/ wheezy main

deb http://ftp.bg.debian.org/debian/ wheezy main contrib non-free
deb-src http://ftp.bg.debian.org/debian/ wheezy main

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main

# wheezy-updates, previously known as 'volatile'
##deb http://deb.debian.org/debian/ wheezy-updates main
deb-src http://deb.debian.org/debian/ wheezy-updates main
##deb http://www.deb-multimedia.org wheezy main non-free
#deb http://ftp.debian.org/debian/ wheezy-backports main
###deb http://ftp.debian.org/debian/ wheezy-backports main contrib non-free
##deb http://dl.google.com/linux/chrome/deb/ wheezy main
#deb http://ftp2.de.debian.org/debian-volatile wheezy/volatile main
###deb http://www.deb-multimedia.org wheezy main non-free


run of the following two depedency fix commands !!!!

 

aptitude upgrade –full-resolver

aptitude full-upgrade –full-resolver


After a while a Debian LinuxOS system downgrade was initated and the missing packages were found, downloaded from the correct wheezy repositories and all broken and missing dependencies packages were fixed !!! HOORAY IT WORKS AGAIN!!

 

Looser Again

Wednesday, January 31st, 2007

Got the 2 mark on Marketing Exam. Again I’m a looser. I dont’ have nor time nor desire to learn again for this exam.I think I’m not suitable for student. Today we was on a coffee with Mitko, Toto and Dido. Nothing special ordinary day.Yesterday we stayed in Mitko and was installing Gentoo Linux to his laptop. Gentoo’s grub was buggy or something,we didn’t succeeded running the kernel with GRUB, so we decided to switch to LILO. We were able to makethe maching bootable using LILO. Then there was an annying error with REAL_ROOT option. After a lot of wanderingediting of /linuxrc we found the mistake it was a mismatch in lilo a mistake we made writing in it we wrote therereal_boot instead of real_root. In the end everything worked okay. And I went home sleeping.I’m not sure where my life is going to again … I’m completely Lost in the Dark.END—–

Remember Domain Mismatch

Tuesday, March 3rd, 2009

Recently I came up to an ugly problem.The HAN university where I study isfiltering the 995 port therefore I couldnot login to gmail, via gmails POP3 SSLedconnection. Thus I configured an rdistwhich is a tiny soft which makes liveseasier when you have to set up a portforwarding. I configured my DebianIcedove to use the host where I hadrdist running. Everything workedalmost fine except an ugly messageappeared warning me that I’m acceptingcertificate from a gmail host which isdifferent from the host where Thunderbirdis connecting. The message appearing was:”Domain Name Mismatch”. I looked the netto find a solution also played a bitwith Icedove itself. Eventually I came alonga nice small thunderbird plugin which didthe trick for me. The add-on is called”Remember Mismatch Domains” and when activateddoes add a field on the window with the warningoffering a way to save the warning and thuspreventing it to occur again :)END—–