Imperva Cyber Community

 View Only
  • 1.  How does "Validate Server Certificate" work?

    Posted 04-01-2022 00:32
    Dear community. Please explain me how does the "Validate Server Certificate" function work for the following cases:
    1)If the server will use a self-signed certificate, how will the certificate be validated?
    2)If the server will use a certificate signed by an internal certification authority, how will the certificate be validated?
    3)If the server will use a certificate issued by a public (external) certificate authority for example (GeoTrust, Thawte, VeriSign, RapidSSL etc.), then how will the certificate be validated?

    What load (in percent) will the inclusion of the "Validate Server Certificate" functionality for Imperva Gateway create?

    Sincerely yours,
    Rustam Abdullin
    #On-PremisesWAF(formerlySecuresphere)

    ------------------------------
    Rustam Abdullin
    Chief Expert
    Astana
    ------------------------------


  • 2.  RE: How does "Validate Server Certificate" work?

    Community Manager
    Posted 04-14-2022 05:21

    Hi Rustam,

    Thanks for posting.

    Could you provide some more information please? What mode of WAF are you running: KRP/TRP or NGRP?

    Thanks,


    Sarah



    ------------------------------
    Sarah Lamont(csp)
    Digital Community Manager
    ------------------------------



  • 3.  RE: How does "Validate Server Certificate" work?

    Posted 04-14-2022 07:16
    Hi Sarah
    We are using KRP mode for WAF

    ------------------------------
    Rustam Abdullin
    Chief Expert
    Astana
    ------------------------------



  • 4.  RE: How does "Validate Server Certificate" work?

    Community Manager
    Posted 04-14-2022 12:42

    Hi @Rustam Abdullin
    I checked in with our knowledge team on this one and they were able to provide the following info...

    Server certificate validation process

    KRP/TRP high level difference 

    KRP/TRP

    In these mods we evaluate the certificate's chain as a whole and for each certificate in the chain, from bottom up, we look for it issuer in our database(what user uploaded to MX),

    If not found we move to the next certificate in the chain, we will do this until we found a certificate's issuer in our database or we will reach to the end of the certificates chain.

    For each certificate, before look for the issuer we validate the date validity range and if we are on the first(bottom) certificate we also validate SNI(if feature is enabled) and if not first cert we check also the previous certificate signature.

    once found we check the founded certificate's signature, check if the serial is revoked, and make up a final decision about the all chain. 

    meaning: In one scenario, in which for the first certificate in the chain we find the issuer in our database(what user uploaded to MX) we will only examine the first certificate and if all tests are successful we will allow the chain without examine the rest of the certificates in the chain. 

    KRP/TRP low level difference 


    KRP

    we get the certificate chain as sent by the server for validation.

    For example, "www. x y z .com" send its certificate, and the certificate authority which issued the server certificate, the CA also tells who's the root, but not sending the root's certificate.

    We iterate over the certificates in the chain from bottom up, meaning starting with depth 0 which is the server certificate.

    For depth 0 we parse the certificate and check the time validity, and compare the requested SNI with the certificate's server name or subject alternative names(if needed).

    next we search for the certificate's issuer in our trusted certificate authorities as the user uploaded to MX.

    IF FOUND we will run some tests to validate the certificate, first we run "checkCertificateSignature" with the ca->rsa_key and the certificate's sign_input, signature and sign_algo

    If valid we'll check if the certificate's serial is revoked Then we will have a final decision, we will break the chain and get a conclusion.

    If one of the steps is failed, we will not allow the certificate.

    IF NOT FOUND, we save data from the certificate like: sign_algo, signature and sign_input and then move on to the next certificate in the chain.

    On the next certificate we will check the time validity and then call to "checkCertificateSignature" with the current certificate's (which is CA) rsa_key and the last known sign_algo, signature and sign_input as saved in previous step.

    Then we will look up again for the certificate's issuer in our trusted certificate authorities as the user uploaded to MX.

    And repeat…

    I hope this helps. Thanks,

    ​​

    ------------------------------
    Sarah Lamont(csp)
    Digital Community Manager
    ------------------------------