Forum Discussion

HQuest_357338's avatar
HQuest_357338
Icon for Altostratus rankAltostratus
Apr 01, 2018

OCSP: Bad Request

Hello all.

I'm trying to implement OCSP stapling and OCSP monitoring for my SSL certificates. OCSP stapling is enabled but never turned on, and OCSP monitoring fails with "OCSP Connection Error: HTTP response doesn't indicate that it is an OCSP response.". A packet capture shows me a "400 Bad Request" response from the OCSP provider. I'm using certificates from Let's Encrypt on a lab environment, running BigIP 13.1.0.4.

The plan is to offload the SSL from the web servers behind the F5, and until this happens, these servers still have their SSL features fully loaded, including the OCSP stapling active and working, using these very same certificates.

Followed this article and a few other previous version hints found from the community, to no avail. I'm not sure what I'm missing at the F5 end.

Any suggestions?

Thanks!

[Edit] A few more supporting data:

From an external server, to my F5 VIP:

$ openssl s_client -connect x.x.x.x:443 -status
CONNECTED(00000003)
OCSP response: no response sent

From an external server, to my live HTTPS server:

$ openssl s_client -connect y.y.y.y:443 -status
CONNECTED(00000003)
OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
    Produced At: Mar 30 20:28:00 2018 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
      Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
      Serial Number: 03E41153079FCD7DFCECDBA6FA1C7DEA3C4E
    Cert Status: good
    This Update: Mar 30 20:00:00 2018 GMT
    Next Update: Apr  6 20:00:00 2018 GMT

As per the linked article, I changed the logging level to debug (tmsh modify sys db log.ssl.level value debug), absolutely nothing SSL related (in fact, only soap entries whenever GUI received an update) gets recorded on /var/log/ltm logfile.

root@(xxx)(cfg-sync Standalone)(Active)(/Common)(tmos) show sys crypto cert-validator ocsp LetsEncrypt_OCSP

-------------------------------
Sys::OCSP: LetsEncrypt_OCSP
-------------------------------
OCSP Requests                38
Internal Errors               0
Successful Cache Requests     0

Connection Errors
  HTTP Errors                38
  Timeouts                    0
  Other Failures              0

Response Errors
  Malformed Requests          0
  Internal Errors             0
  Try Later Errors            0
  Signature Required Errors   0
  Unauthorized Errors         0

Response Validation Errors
  Parsing Failures            0
  Verification Errors         0
  Validity Errors             0
  Other Errors                0

Certificate Status
  Good                        0
  Revoked                     0
  Unknown                     0
  • Very different POST requests... and this definitively nailed the problem.

     

    From my browser, the tbsRequest has the reqCert with issuerNameHash, issuerKeyHash and serialNumber for the certificate.

     

    From the F5, apart of the reqCert, the tbsRequest also sends a requestorName of type directoryName, and sends a copy of the certificate defined under OCSP > Request signing as optionalSignature.

     

    However this OCSP does not requires (or expects) to sign anything, and by taking it away, SSL certificate status went green instantly. And the OCSP response now contains the OCSP Response Status: successfull as it should.

     

    Seems there was one combination I didn't tried... Thanks for the hint, it was spot on.

     

  • Does your packet capture show the OCSP request that is being sent to the OCSP responder?

     

    Can you compare the working request with the failed request?

     

  • Very different POST requests... and this definitively nailed the problem.

     

    From my browser, the tbsRequest has the reqCert with issuerNameHash, issuerKeyHash and serialNumber for the certificate.

     

    From the F5, apart of the reqCert, the tbsRequest also sends a requestorName of type directoryName, and sends a copy of the certificate defined under OCSP > Request signing as optionalSignature.

     

    However this OCSP does not requires (or expects) to sign anything, and by taking it away, SSL certificate status went green instantly. And the OCSP response now contains the OCSP Response Status: successfull as it should.

     

    Seems there was one combination I didn't tried... Thanks for the hint, it was spot on.

     

  • Very different POST requests... and this definitively nailed the problem.

     

    From my browser, the tbsRequest has the reqCert with issuerNameHash, issuerKeyHash and serialNumber for the certificate.

     

    From the F5, apart of the reqCert, the tbsRequest also sends a requestorName of type directoryName, and sends a copy of the certificate defined under OCSP > Request signing as optionalSignature.

     

    However this OCSP does not requires (or expects) to sign anything, and by taking it away, SSL certificate status went green instantly. And the OCSP response now contains the OCSP Response Status: successfull as it should.

     

    Seems there was one combination I didn't tried... Thanks for the hint, it was spot on.

     

  • What is the exact setting that you changed? I cannot get this to work. I'm using version BIG-IP 13.1.0.2