Verify a certificate chain using openssl verify

Question

I m building a own certificate chain with following componenents   Root Certificate - Intermediate Certificate - User Certificate   Root Cert is a self signed certificate  Intermediate Certificate is signed by Root and User by Intermediate    Now I want to verify if a User Certificate has its anchor by Root Certificate   With  openssl verify -verbose -CAfile RootCert pem Intermediate pem   the validation is ok  In the next step I validate the User Cert with  openssl verify -verbose -CAfile Intermediate pem UserCert pem   and the validation shows  error 20 at 0 depth lookup unable to get local issuer certificate   What is wrong

User · Answer

You can easily verify a certificate chain with openssl. The fullchain will include the CA cert so you should see details about the CA and the certificate itself.

openssl x509 -in fullchain.pem -text -noout

User · Answer

The problem is  that openssl -verify does not do the job   As Priyadi mentioned  openssl -verify stops at the first self signed certificate  hence you do not really verify the chain  as often the intermediate cert is self-signed      I assume that you want to be 101  sure  that the certificate files are correct before you try to install them in the productive web service   This recipe here performs exactly this pre-flight-check    Please note that the answer of Peter is correct  however the output of openssl -verify is no clue that everything really works afterwards   Yes  it might find some problems  but quite not all   Here is a script which does the job to verify a certificate chain before you install it into Apache   Perhaps this can be enhanced with some of the more mystic OpenSSL magic  but I am no OpenSSL guru and following works      bin bash   This Works is placed under the terms of the Copyright Less License    see file COPYRIGHT CLL   USE AT OWN RISK  ABSOLUTELY NO WARRANTY       COPYRIGHT CLL can be found at http   permalink de tino cll    CLL is CC0 as long as not covered by any Copyright   OOPS     echo  OOPS       gt  amp 2  exit 23     PID  kick       -n   PID     amp  amp  kill   PID   amp  amp  sleep  2  PID     trap  kick  0  serve     kick PID  openssl s server -key   KEY  -cert   CRT       -www  amp  PID    sleep  5      give it time to startup    check     while read -r line do     case   line  in      Verify return code  0  ok      return 0        Verify return code         return 1           echo       line            esac done  lt   lt  echo   openssl s client -verify 8 -CApath  etc ssl certs   OOPS  Something failed  verification output not found   return 2    ARG    1     KEY   ARG key  CRT   ARG crt  BND   ARG bundle   for a in   KEY    CRT    BND  do       -s   a       OOPS  missing  a  done  serve check  amp  amp  echo                gt  CA-Bundle is not needed   lt           echo serve -CAfile   BND  check ret    kick  echo case  ret in 0   echo  EVERYTHING OK      echo  SSLCertificateKeyFile  KEY      echo  SSLCertificateFile     CRT      echo  SSLCACertificateFile   BND             echo                gt  something is wrong  verification failed   lt            ret     esac  exit  ret      Note that the output after EVERYTHING OK is the Apache setting  because people using NginX or haproxy usually can read and understand this perfectly  too      There is a GitHub Gist of this which might have some updates  Prerequisites of this script    You have the trusted CA root data in  etc ssl certs as usual for example on Ubuntu Create a directory DIR where you store 3 files    DIR certificate crt which contains the certificate DIR certificate key which contains the secret key for your webservice  without passphrase  DIR certificate bundle which contains the CA-Bundle   On how to prepare the bundle  see below   Now run the script    check DIR certificate  this assumes that the script is named check in the current directory  There is a very unlikely case that the script outputs CA-Bundle is not needed   This means  that you  read   etc ssl certs   already trusts the signing certificate   But this is highly unlikely in the WWW  For this test port 4433 must be unused on your workstation   And better only run this in a secure environment  as it opens port 4433 shortly to the public  which might see foreign connects in a hostile environment    How to create the certificate bundle file   In the WWW the trust chain usually looks like this    trusted certificate from  etc ssl certs unknown intermediate certificate s   possibly cross signed by another CA your certificate  certificate crt    Now  the evaluation takes place from bottom to top  this means  first  your certificate is read  then the unknown intermediate certificate is needed  then perhaps the cross-signing-certificate and then  etc ssl certs is consulted to find the proper trusted certificate   The ca-bundle must be made up in excactly the right processing order  this means  the first needed certificate  the intermediate certificate which signs your certificate  comes first in the bundle   Then the cross-signing-cert is needed   Usually your CA  the authority who signed your certificate  will provide such a proper ca-bundle-file already   If not  you need to pick all the needed intermediate certificates and cat them together into a single file  on Unix    On Windows you can just open a text editor  like notepad exe  and paste the certificates into the file  the first needed on top and following the others   There is another thing   The files need to be in PEM format   Some CAs issue DER  a binary  format   PEM is easy to spot   It is ASCII readable   For mor on how to convert something into PEM  see How to convert  crt to  pem and follow the yellow brick road   Example   You have    intermediate2 crt the intermediate cert which signed your certificate crt intermediate1 crt another intermediate cert  which singed intermediate2 crt crossigned crt which is a cross signing certificate from another CA  which signed intermediate1 crt crossintermediate crt which is another intermediate from the other CA which signed crossigned crt  you probably will never ever see such a thing    Then the proper cat would look like this   cat intermediate2 crt intermediate1 crt crossigned crt crossintermediate crt  gt  certificate bundle   And how can you find out which files are needed or not and in which sequence   Well  experiment  until the check tells you everything is OK   It is like a computer puzzle game to solve the riddle   Every   Single   Time   Even for pros   But you will get better each time you need to do this   So you are definitively not alone with all that pain   It s SSL  ya  know   SSL is probably one of the worst designs I ever saw in over 30 years of professional system administration   Ever wondered why crypto has not become mainstream in the last 30 years   That s why    nuff said

User · Answer

From verify documentation   If a certificate is found which is its own issuer it is assumed to be the root CA   In other words  root CA needs to self signed for verify to work  This is why your second command didn t work  Try this instead  openssl verify -CAfile RootCert pem -untrusted Intermediate pem UserCert pem  It will verify your entire chain in a single command

User · Answer

After breaking an entire day on the exact same issue   with no prior knowledge on SSL certificates  i downloaded the CERTivity Keystores Manager and imported my keystore to it  and got a clear-cut visualisation of the certificate chain   Screenshot

User · Answer

I ve had to do a verification of a letsencrypt certificate and I did it like this     Download the root-cert and the intermediate-cert from the letsencrypt chain of trust  Issue this command     openssl verify -CAfile letsencrypt-root-cert isrgrootx1 pem txt -untrusted letsencrypt-intermediate-cert letsencryptauthorityx3 pem txt  etc letsencrypt live sitename tld cert pem   etc letsencrypt live sitename tld cert pem  OK

User · Answer

If you only want to verify that issuer of UserCert pem is actually Intermediate pem do the following  example uses  OpenSSL 1 1 1    openssl verify -no-CAfile -no-CApath -partial chain -trusted Intermediate pem UserCert pem   and you will get   UserCert pem  OK   or   UserCert pem  verification failed

User · Answer

That s one of the few legitimate jobs for cat   openssl verify -verbose -CAfile  lt  cat Intermediate pem RootCert pem  UserCert pem     Update   As Greg Smethells points out in the comments  this command implicitly trusts Intermediate pem  I recommend reading the first part of the post Greg references  the second part is specifically about pyOpenSSL and not relevant to this question    In case the post goes away I ll quote the important paragraphs      Unfortunately  an  intermediate  cert that is actually a root   self-signed   will be treated as a trusted CA when using the recommended command given   above         openssl verify -CAfile  lt  cat geotrust global ca pem rogue ca pem    fake sometechcompany from rogue ca com pem   fake sometechcompany from rogue ca com pem  OK   It seems openssl will stop verifying the chain as soon as a root certificate is encountered  which may also be Intermediate pem if it is self-signed  In that case RootCert pem is not considered  So make sure that Intermediate pem is coming from a trusted source before relying on the command above

[openssl] Verify a certificate chain using openssl verify

Examples related to openssl

Examples related to certificate