-
Notifications
You must be signed in to change notification settings - Fork 811
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OCSP stapling with HAProxy as a server #7588
Comments
I've looked on it again, so some updates from our side:
So we enter in the default case here, which does nothing :/ We've expected to enter in this So, it will be helpful for us, if you have some ideas, why finished with status_type == 0, while simply testing:
haproxy.cfg:
Kind regards, |
If I slightly change enum to make WOLFSSL_CSR2_OCSP = 0, in order that we enters to I have this output in the log:
So, could you please help us on it, otherwise it begins to long to debug. Seems that something missing in OCSP server side implementation. |
Hi @vkssv , I see your configuration command is For example, how are you building and executing haproxy? Do I need any certificates or keys to reproduce? I see the peer is openSSL s_client. Does it need a CA certificate? This might be much simpler if we can reproduce this using our Its great to see haproxy/wolfssl interest on constrained embedded devices. Lets see if we can get this working! |
Hi Anthony ! No #7593 does not fix the issue completely, it just allows to load and validate OCSP response file in DER format with HAProxy. I've provided this patch as a pull request to you to illustrate, what is probably missed/overlooked in i2d_OCSP_CERTID and in OCSP_id_cmp OpenSSL compatibility API functions.
If you could launch under GDB and put the breakpoint as:
you could follow the logic of ssl_sock_load_ocsp, which at first, calculates CertID and then loads and validates show_ocsp_server.pem.ocsp by using OpenSSL compatibility API layer. Like this you could understand better our workflow for enabling OCSP stapling.
Then you could look to my previous post, when I explain that SendCertificateStatus, which performs OCSP stapling always finishes with 0, but does not fill Certificate Status extention. This happens, when haproxy code calls SSL_do_handshake. We've noticed this comment under I'll look soon on your our Kind regards, |
Hi @vkssv , I've assigned our OCSP expert, @ejohnstown to look into this for you. Warm regards, Anthony |
Hi Anthony ! Hi John ! Thanks a lot for the support. I lastly revert my workaround for wolfSSL_i2d_OCSP_CERTID, when compiled with HAPROXY_ENABLED. And I've tried from my side this patch in our
And these changes in wolfSSL v.5.7.0:
This allows to load our OCSP file in DER format, but I still have the same problem. In the wolfSSL logs I see that there is probably the problem, while the given show_ocsp_server.pem is parsed, while we ask:
Hope this helps. |
Another questions, could you please clarify, what we suppose to supply as a Should it be issuer certificate in DER format or just a byte string created as following: As I've got from the code of ocsp.c, we need to call first I will investigate further the error with Kind regards, |
Hi guys ! I've attached a simple server program (server.c), which could be compiled and linked with either wolfSSL 5.7.0, or with OpenSSL 3.0.2 (coming from the distro package). There are also valid server certificate, corresponded to it OCSP response (DER) and corresponded issuer and intermediate certificates.
So, steps to reproduce with this server.c :
When server.c is linked with wolfSSL, we can see the following error in wolfSSL log ( no any patches in wolfSSL from our side, only stable 5.7.0 code):
openssl s_client shows:
Output, when compiled without wolfSSL_Debugging_ON();
In case, when we compile and link the server.c with OpenSSL 3.0.2 from the distro:
Hope this helps to debug, |
Hi! It's unfortunate that there doesn't seem to be much interest in making wolfssl work correctly with haproxy. I believe that many haproxy users would happily ditch quictls/openssl for wolfssl (myself included) but can't, for lack of ocsp stapling support. Is there any way users could help debug this issue? |
Hi @hpn0t0ad , thank you for the reminder about this issue. The engineer I assign is on vacation. Let me find another engineer to work on this. Thanks, David Garske, wolfSSL |
Hello @vkssv I was looking at this issue to reproduce, however it seems the certificates you provided (testocsp.irq6.net.pem) has expired. I was hoping you could provide me with details on how you created it and the ocsp file so I can test on my end. Thanks, |
Version
v5.7.0-stable
Description
Hello guys !
We have some user requests to make work OCSP stapling extension with haproxy process as a server, i.e. haproxy loads, parses by itself OCSP response for the given server certificate and provides the status to clients.
haproxy is linked with libwolfssl.so.42, compiled from v5.7.0-stable.
We have some problems to make OCSP extension work, in spite of the support, which was added in our source code via this patch 3cbf09ed6411 "MEDIUM: ssl: add minimal WolfSSL support with OpenSSL compatibility mode" in haproxy ".
We have the following workflow for processing OCSP response files in DER format:
Problems have started already, when we try to check CertID length via wolfSSL_i2d_OCSP_CERTID helper here. From the wolfSSL_i2d_OCSP_CERTID code we can see, that it uses
rawCertId
andrawCertIdSize
fields from OcspEntry structure, which are not filled by wolfSSL_OCSP_cert_to_id. Could you, please, provide some explanations on this ?When we did some workaround and started to simply check in our code the total length of
OcspEntry->issuerHash + OcspEntry->issuerKeyHash + OcspEntry->status->serial < OCSP_MAX_CERTID_ASN1_LENGTH (128 bytes)
,we could advance further and could finally call
wolfSSL_CTX_set_tlsext_status_cb
, which triggers the path:wolfSSL_CTX_EnableOCSPStapling --> wolfSSL_CertManagerEnableOCSPStapling --> cm->ocspStaplingEnabled = 1
and sets our
ssl_sock_ocsp_stapling_cbk
callback function.Then we could also successfully parse DER OCSP response, wolfSSL_d2i_OCSP_RESPONSE works as expected. So, finally we've successfully loaded and checked OCSP response data, but still no OCSP extension provided in SERVER HELLO, when a client sends CLIENT HELLO with Certificate Status Request (TLSv1.2).
From WolfSSL debug logs we see that SendCertificateStatus returns 0 in the case:
According to the code from SendCertificateStatus, it seems, that we should enter in
case WOLFSSL_CSR2_OCSP:
. Unfortunately,CreateOcspResponse
does not contain any traces to simply check where it fails.From
CreateOcspResponse
code we can see that probably it does not suppose to exit on:check, as SSL_CM(ssl)->ocspStaplingEnabled was set to one.
We have an intention to make work OCSP and we could probably investigate further, but there are some worries about the fact that
wolfSSL_CertManagerEnableOCSPStapling
along withocspStaplingEnabled = 1
also sets the built-in OCSP lookup here (EmbedOcspLookup). In this lookup you build and send OCSP request to the detected OCSP URI. This is quite same logic, that we do on our side in ssl_ocsp_update_responses.So could you please, confirm, that, if we reset
cm->ocspIOCb
andcm->ocspRespFreeCb
to NULL, as we update OCSP responses by ourselves, we do not have any other drawbacks and we are on the right way to make things work. And could you also provide to us some hints, where potentiallySendCertificateStatus
orCreateOcspResponse
may fail.Many thanks in advance,
Kind regards.
The text was updated successfully, but these errors were encountered: