vkssv
commented
6 months ago I've looked on it again, so some updates from our side:
SendCertificateStatus finishes with 0 as status_type here is always stays as zero, in spite that we've compiled with HAVE_CERTIFICATE_STATUS_REQUEST, HAVE_CERTIFICATE_STATUS_REQUEST_V2
./configure --enable-haproxy --enable-debug --enable-quic --prefix=/opt/wolfssl-5.7.0
So we enter in the default case here, which does nothing :/
We've expected to enter in this case WOLFSSL_CSR2_OCSP:, while calling from haproxy code SSL_do_handshake.
So, it will be helpful for us, if you have some ideas, why finished with status_type == 0, while simply testing:
/usr/bin/openssl s_client -connect localhost:1443 -status -tls1_2
haproxy.cfg:
frontend fe_ssl
...
bind *:1443 ssl crt show_ocsp_server.pemKind regards,
anhu
dgarske
hpn0t0ad
ColtonWilley
wlallemand
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
rawCertIdandrawCertIdSizefields 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 = 1and sets ourssl_sock_ocsp_stapling_cbkcallback 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,CreateOcspResponsedoes not contain any traces to simply check where it fails.From
CreateOcspResponsecode 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_CertManagerEnableOCSPStaplingalong withocspStaplingEnabled = 1also 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->ocspIOCbandcm->ocspRespFreeCbto 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 potentiallySendCertificateStatusorCreateOcspResponsemay fail.Many thanks in advance, Kind regards.