Forum Discussion

bluepet_10591's avatar
Icon for Altostratus rankAltostratus
Jun 15, 2011

SSL::verify_result = 27 what does that mean?




Firstly I apologise if this is a basic question, I did try troll around the devcentral but have not seen one that matches my issue.



Hope you guys can assist to help me understand.





- user application browse our virtual server on our bigip LTM which have a SSL profile certificate with certificate request ticked.


- connection failed and upon checking it is due to irule check below matches verify_result !=0 namely 27



if { [SSL::cert count] == 0 or [SSL::verify_result] != 0 }









the cert count = 2 and the value of verify_result = 27, which upon searching is



27 = X509_V_ERR_CERT_UNTRUSTED: certificate not trusted



The customer certificate is a valid certificate issued by thwte SGC CA - G2, I gather





- Thawte SGC CA - G2





Why would it not a trusted certificate? Do I need to install their intermediate certificate root authority into my Bigip LTM box?



please advice








10 Replies

  • hi Nitass,



    true... trying to get the client to provide me their certificate. Will tell you the output of that command once i got it from them.



  • Hi Patrick,



    This error code indicates that the cert the client presents is not chained to a root cert installed in the bundle specified in the client SSL profile's trusted CA bundle field. You do need to combine the intermediate and root cert in one bundle in your LTM config under /config/ssl/ssl.crt (or via the GUI) and then set this in the client SSL profile. You can cat the files together to combine them:



    cat file1.crt file2.crt > /config/ssl/ssl.crt/myca.bundle.crt



  • hi Aaron,



    thanks for the very prompt reply, this is what I did, have to wait for change to be approved before I can implement it. Hopefully this will resolve the issue and anyone else facing the same problem can follow the same steps.



    1. Got the customer to send me their intermediate certificate. Namely from Thawte in my case. The format they sent is thawte.cer


    2. I converted the certifcate form der/binary to standard pem, which is clear text (with begin cert end)


    3. cat converted-cert.crt > /config/ssl/ssl.crt/copy.myca.bundle.crt


    4. applied the copy.myca.bundle.crt to the client ssl profile defined for the trusted certificate authority to replace myca.bundle.crt



    Will update if it work. What I don't understand is why the client certificate suddenly not trusted when they didn't change their certificate. They did however update on their machine the intermediate certificate.



    In my log it looked like the cert count = 2, I am wondering did the client sent 2 certificates? 1st is their certificate and 2nd one is their intermediate certificate and those two are the one used by F5 to compare? Sorry for my ignorance about SSL certificate. :)
  • just wondering if this passes.



    openssl verify -purpose sslclient -CAfile (trusted ca file) (client certificate file)



    sol10167: Overview of the Client SSL profile

  • hi nitass,



    Thanks for the link, it does make it a lot clearer for me. Didn't try the command as I don't have the client cert only the trusted ca file that they gave me. The document does confirm the need to install the intermediate certificate into the bundle.



    Found out about the 2 certificate as well (ssl::cert count = 2), one is the client certificate + one more from the issuing certificate authority (thawte)



    It still puzzled me however why F5 suddenly do not trust the client certificate when they client didn't change their certificate. At least they claimed they didn't. They did however install an intermediate certificate on their server. Which looked like the second certificate sent across to F5.



    Maybe F5 did not trust the intermediate certificate authority that they use.



  • i suspect ca file which is set as trusted ca in clientssl profile is not complete (cannot make chain of trust from client certificate to root certificate) same as Aaron.



    i believe it would be easier if we can have the ca file and client certificate to check.



  • Got the client cert, test it out with the trusted bundle certificate that I had (original)



    got this error when I did this



    openssl verify -purpose sslclient -CAfile mybundle.crt client.crt


    error 20 at 0 depth lookup:unable to get local issuer certificate



    add the intermediate cert from thawte into the mybundle.crt


    openssl verify -purpose sslclient -CAfile mybundle+intermediate.crt client.crt


    error 2 at 1 depth lookup:unable to get issuer certificate



    install the verisign cert into the bundle and got it to work


    client.crt : ok



    note client cert is as follow




    -- thawte





    so looked like you need to install all the cert in the chain if it is missing in your current trusted cert namely


    paste the cert from verisign & thawte into your current bundle. Tested it and it does not matter the order of you pasted them



    namely cat verisign.crt >> mybundle.crt and then cat thawte.crt >> mybundle.crt



    You need to view and export the certificate from der format to pem first to get it into clear text. The chain certificates comes together with the client cert.
  • I have installed the int certs as issued by verisign and run the verify against the cert they issued me and I still get the


    error 2 at 2 depth lookup:unable to get issuer certificate



    no idea where I am going wrong!
  • This was a similar issue as bluepet's where the root and multiple intermediate certs needed to be combined in a bundle for openssl verification to succeed.