Forum Discussion

16 Replies

  • I'll add a "+1 tried and failed" with our Comodo certs. Still on the to-do list to pursue, but hasn't made it back to the top.
  • I haven't been successful either and am working with support get this to work. At the moment engineering is looking at the issues and my configuration 'seems' to be fine (at least according to support).

     

    Keep you updated with the results...

     

  • Looking for the same info, so if support has gotten back to you, I'd like to see what you ended up using (you = Ronald)

     

  • I managed to get a working environment... As I work with several partitions and routing domains I had several other issues to deal with...

    The following steps were done to finally get OCSP stapling to work:

    1. Configure a DNS resolver (forward zone: '.')
    2. Create profile OCSP Stapling (advanced settings)
      • Configure the DNS resolver from 1
      • Set Trusted CA and Trusted Responders (make sure the certificate is in the bundle [if you use the bundle]!)
      • Configure Status Age to 86400 (default 300, which resulted in errors)
    3. Create / modify the SSL Client Profile
      • Modify the certificate key chain to add the OCSP Stapling Parameters.
    4. Connect the SSL Client Profile to the Virtual Server..

    My issues:

    • Trusted CA/Responders did not contain the certificate used by the OCSP responder (signing)
    • Status Age (default value)

    Results..

    OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 42B6511E20AE925461D1611744ECB5A71A74D039
    Produced At: May  7 03:35:38 2015 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: D1F1B576F9EEC0C10F7AFC7C3124A9C3625D7C61
      Issuer Key Hash: EA4E7CD4802DE5158186268C826DC098A4CF970F
      Serial Number: 1121283877D6C3E4AD590147B7F9B0AB5A76
    Cert Status: good
    This Update: May  7 03:35:38 2015 GMT
    Next Update: May  7 15:35:38 2015 GMT
    

    Troubleshooting tips:

    1. Make sure your BigIP can resolve the OCSP Responder domain (using DNS)
    2. Make sure connectivity to and from DNS/Responder is available (usually HTTP -> see certificate -> Authority Information Access)
    3. Make sure you receive a valid response from the OCSP Responder (including valid times)
    4. Check if your configuration contains valid Trusted CA/Trusted Responder and Status Age configuration
    • Mike_Ripley's avatar
      Mike_Ripley
      Icon for Nimbostratus rankNimbostratus
      Just noticed this thread come back, and thought I should add my $.02 again. I was able to work with support to get OCSP stapling working as well. One outstanding caveat is that we were noticing periodic drop-outs of the OCSP staples. Turns out Comodo will issue OCSP replies for four days, and F5 rejects any with "This Update" older than 86400 sec. I've got an EHF queued up for next week that should allow us to relax that window.
    • Ken_Schultz_525's avatar
      Ken_Schultz_525
      Icon for Nimbostratus rankNimbostratus
      Found my answer https://support.f5.com/kb/en-us/solutions/public/16000/800/sol16810.html Beginning in BIG-IP 11.6.0 HF5 the Status Age field of the OCSP Stapling profile has a default value of 86400 seconds (1 day), and will allow a range of 0 to MAX_INT seconds to be specified.
  • I managed to get a working environment... As I work with several partitions and routing domains I had several other issues to deal with...

    The following steps were done to finally get OCSP stapling to work:

    1. Configure a DNS resolver (forward zone: '.')
    2. Create profile OCSP Stapling (advanced settings)
      • Configure the DNS resolver from 1
      • Set Trusted CA and Trusted Responders (make sure the certificate is in the bundle [if you use the bundle]!)
      • Configure Status Age to 86400 (default 300, which resulted in errors)
    3. Create / modify the SSL Client Profile
      • Modify the certificate key chain to add the OCSP Stapling Parameters.
    4. Connect the SSL Client Profile to the Virtual Server..

    My issues:

    • Trusted CA/Responders did not contain the certificate used by the OCSP responder (signing)
    • Status Age (default value)

    Results..

    OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 42B6511E20AE925461D1611744ECB5A71A74D039
    Produced At: May  7 03:35:38 2015 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: D1F1B576F9EEC0C10F7AFC7C3124A9C3625D7C61
      Issuer Key Hash: EA4E7CD4802DE5158186268C826DC098A4CF970F
      Serial Number: 1121283877D6C3E4AD590147B7F9B0AB5A76
    Cert Status: good
    This Update: May  7 03:35:38 2015 GMT
    Next Update: May  7 15:35:38 2015 GMT
    

    Troubleshooting tips:

    1. Make sure your BigIP can resolve the OCSP Responder domain (using DNS)
    2. Make sure connectivity to and from DNS/Responder is available (usually HTTP -> see certificate -> Authority Information Access)
    3. Make sure you receive a valid response from the OCSP Responder (including valid times)
    4. Check if your configuration contains valid Trusted CA/Trusted Responder and Status Age configuration
    • Mike_Ripley's avatar
      Mike_Ripley
      Icon for Nimbostratus rankNimbostratus
      Just noticed this thread come back, and thought I should add my $.02 again. I was able to work with support to get OCSP stapling working as well. One outstanding caveat is that we were noticing periodic drop-outs of the OCSP staples. Turns out Comodo will issue OCSP replies for four days, and F5 rejects any with "This Update" older than 86400 sec. I've got an EHF queued up for next week that should allow us to relax that window.
    • Ken_Schultz_525's avatar
      Ken_Schultz_525
      Icon for Nimbostratus rankNimbostratus
      Found my answer https://support.f5.com/kb/en-us/solutions/public/16000/800/sol16810.html Beginning in BIG-IP 11.6.0 HF5 the Status Age field of the OCSP Stapling profile has a default value of 86400 seconds (1 day), and will allow a range of 0 to MAX_INT seconds to be specified.
  • Hello, I have successfully configured OCSP Stapling profile with some help from F5 Support (thanks Melina)

     

    I have a:

     

    • Wildcard certificate signed by thawte (let's name it PFX)

       

    • thawte intermediate certificate (let's name it CRT-INTR)

       

    • thawte root certificat (let's name it CRT-ROOT)

       

    • No idea which Sign Hash algo is used by thawte OCSP Responders

       

    So the guide is here:

     

    • Upload to BIG-IP client certificate PFX

       

    • Upload to BIG-IP certificate bundle. First intermediate CRT-INTR, next root CRT-ROOT. If your chain is deeper, than you need to upload INTR1,INTR2,ROOT [BUNDLE]

       

    • Create default DNS Resolver in Network -> DNS Resolvers -> DNS Resolver List [DNS]

       

    • Create OCSP Stapling profile Local Traffic -> Profiles -> SSL -> OCSP Stapling [OCSP]

       

    • Use created earlier DNS Resolver [DNS], use created earlier Trusted Certificate Authorities [BUNDLE], set Status Age to 86400

       

    • Create Client SSL profile with selected created earlier OCSP Stapling profile

       

    • Test each Sign Hash algo (SHA1/SHA256) against external OCSP Stapling checker, like https://www.ssllabs.com/ssltest/

       

  • Hello! What mean it ltm log file

     

    Sep 22 16:12:23 F5-TEST-VC warning tmm[16256]: 01260024:4: OCSP failure on profile /Click/testjmb_ssl, certificate with issuer /C=US/O=thawte, Inc./OU=Terms of use at https://www.thawte.com/cps (c)06/CN=thawte Extended Validation SSL CA and serial number ffffffffffffffff: HTTP error - - 503

     

    ?

     

  • I've just done this after setting up new certs from Let's Encrypt.

     

    For anyone else hitting issues with OCSP Stapling, I ran into a few gotchas, including:

     

    a) 11.6.0 HF6 has a default Status Age value of 300. Had to up to 86400 as per previous posters recommendation.

     

    b) The default Sign Hash used to identify the certificate to check is SHA256... Let's Encrypt's OCSP responder won't accept SHA256, it needs to be SHA1.

     

    c) The Let's Encrypt's OCSP responder will not include it's own cert in the response. The "Trusted Responders" option needs to be set properly in the OCSP Stapling profile.

     

    A bit more info at the link below, including examples of debugging using openssl CLI commands.

     

    https://blog.routedlogic.net/?p=1235