Hi,
Yes, you found the right place where ocaml-ssl in maintained. Actually, I
wrote this binding a long time ago, and haven't used it for a long time, so
it's not really a high priority for me. However, I am willing to make
necessary modifications if someone (like you) needs more features, or
better: integrate provided patches ;)
1. I thing that you are using the "get_verify_result" function. A better
alternative is to use the "verify" function which returns unit but raise an
exception of type "verify_error" which is pretty informative. Is it what you
were looking for?
2. This should be easy. Please provide me with the exact list of things that
you would like to see, and ideally with how you would do this in C (I only
added issuer and and subject because these are the only provided examples in
man SSL_CTX_set_verify...).
3. The verify_callback is really a hack, where you can only use the provided
client_verify_callback: this it why it should change in the future, in order
to allow caml functions. Actually, the problem is that SSL_CTX_set_verify is
waiting for a C function and there is no custom data which is passed in
which I could pass a pointer to the caml function to call (ideally I should
be able to put the pointer to the caml function insinde X509_STORE_CTX which
is passed to the callback but this does not seem to be possible). Maybe do
you have an idea of how I could design the bindings?
++
Sam.
2011/3/16 Jehan Pagès <jehan.marmott...@gmail.com>
> Hi,
>
> I am using ocaml-ssl for a project. Though it is not a lot advertized
> on your main website, I got it from your Sourceforge files section, so
> I guess you are the maintainers (note that I also doubted because the
> Caml Hump, first link in a Google search for "ocaml-ssl", list a now
> dead link for the ocaml-ssl project. You might want to update this!
> :-).
>
> Anyway I was wondering if you were planning to make significant
> improvement on this binding or this is too low a priority (I can see
> you have quite a huge list of modules to maintain indeed!).
>
> Limitations are found in particular on the certificate validation part
> which is not very flexible.
> For instance when it is not validated automatically by the library, I
> want to provide useful data to the user in order to allow him to
> manually validate or refuse a certificate. But the current binding
> simply has not all this part:
> 1/ the error is returned in an unprocessed integer form (I had to map
> values with "man 1 verify". Without this, you cannot do much).
> 2/ The only 2 fields I can get on the cert through ocaml-ssl are the
> issuer and the subject. I would like to have the expiration date, the
> start date or other fields (because as a user, when a cert is expired
> from just today, but is good otherwise, I would say that for a
> non-highly sensible website, I would say ok, but not a cert expired
> for 3 years for instance!)...
> 3/ Also the verify_callback with the following warning: "Warning: this
> might change in the future."... I would actually like for it to
> change, because in its current form, I don't really see what we can do
> with it! It is a private type with no construction function. We are
> stuck with the only one defined callback (or there is something I
> didn't get in how to use this).
>
> So here I am... just wondering if you have plans for ocaml-ssl, which
> otherwise works nice. I had a few workarounds so I have been able to
> bypass some of the current limitations of the current API to give
> users the possibility to accept a problematic cert, but some data like
> dates would be really nice too (being able to get all the fields
> without restriction would be even better). :-)
>
> Thanks.
>
> Jehan
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Savonet-devl mailing list
> Savonet-devl@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/savonet-devl
>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Savonet-devl mailing list
Savonet-devl@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-devl
