Re: [stunnel-users] public domain [Patch] Support multiple X509 client certificates with same CN
Hi Michal,
What license do you need the patch to be?
Preferably public domain, but any GPL-compatbile and non-copyleft license should be fine.
I hereby release my patches to stunnel for support of muliple client certificates with the same CN into the public domain. Best regards, Leon Winter
On 2014-03-27 12:15, Leon Winter wrote:
I hereby release my patches to stunnel for support of muliple client certificates with the same CN into the public domain. Thank you very much. Could you please test my implementation? https://www.stunnel.org/downloads/beta/stunnel-5.01b2.tar.gz
It should be thread-safe, as X509_STORE_get1_certs() synchronizes X509_STORE operations with CRYPTO_LOCK_X509_STORE locks. It also doesn't use any pointers to internal OpenSSL data structures, so it should be able to survive updates of the OpenSSL shared libraries. Mike
Hi Michal, thanks for the fast integration.
Thank you very much. Could you please test my implementation? https://www.stunnel.org/downloads/beta/stunnel-5.01b2.tar.gz
due to other changes in the code like the ui_* refactoring I could not compile these exact version but in the end I managed to compile a modified stunnel 5.00 version[1] with your modified src/verify.c which contains the relevant logic and I can confirm it is working. It correctly iterates over the set of client certificates with the given CN and then also correctly identifies a matching one.
It should be thread-safe, as X509_STORE_get1_certs() synchronizes X509_STORE operations with CRYPTO_LOCK_X509_STORE locks. It also doesn't use any pointers to internal OpenSSL data structures, so it should be able to survive updates of the OpenSSL shared libraries.
As I am not very familiar with the OpenSSL API I cannot comment on that, however not using the lowlevel interfaces certainly is cleaner and the way to go. However this way only more current versions of stunnel with a recent OpenSSL version will support this functionality while using the other 'non-clean' way would also add support for users with older OpenSSL versions. Since I have the latest version of OpenSSL I am perfectly fine with the change though ;) One minor note, in line 291 of verify.c is a blank at the EOL, but since this was just a beta release you might clean up the code later before the actual release. Best regards, Leon Winter [1] http://anonscm.debian.org/gitweb/?p=collab-maint/stunnel.git;a=summary
participants (2)
-
Leon Winter -
Michal Trojnara