Re: connecting to multiple hosts (who have the same identical SSL cert) simultaneously using libcurl multi interface
Date: Mon, 21 Aug 2017 01:22:01 -0400
On 8/14/2017 12:15 PM, Russell Cote via curl-library wrote:
> Let me first point out that I have a stupid problem but a problem none
> the less that I'm hoping someone can recommend a work around for.
> I have several embedded systems that share the same SSL cert (baked in
> the image) that I'm trying to connect to simultaneously using
> libcurl's multi interface. The problem that I'm experiencing is that
> I'm only able to connect to one of these embedded hosts at a time
> otherwise I get the following error (35, 'You are attempting to import
> a cert with the same issuer/serial as an existing cert, but that is
> not the same cert.') when I connect to more than one host at a time.
> I've configured libcurl with CURLOPT_SSL_VERIFYPEER = 0 &
> CURLOPT_SSL_VERIFYHOST = 0 in hopes that the cert duplication will be
> ignored but I still encounter the above error. I believe this error
> is being generated by NSS and not libcurl.
> The libcurl info for the Centos 7 box that I using to connect to the
> embedded hosts:
> CentOS Linux release 7.3.1611 (Core)
> libcurl.x86_64 7.29.0-35.el7.centos installed
> libcurl-devel.x86_64 7.29.0-35.el7.centos
> curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.21 Basic
> ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
> Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL
> libz unix-sockets
> My searching of the internet on this issue did not yield much help
> other than some hints to potentially use a newer version of libcurl
> compiled with openssl instead of NSS but my concern with this route is
> that I'll break Centos' other packages and tools by changing the
> libcurl ssl library.
> Ideally, I would load a new SSL cert onto the embedded hosts but
> that's a long term solution but I'm hoping someone has some short term
> that I can work around this issue with.
Try a newer libcurl. If it's still a problem use an SSL backend other
than NSS. If you are worried about affecting your packaged libcurl
install the newer one to some non standard location and then link to it
there. If it's shared you'll need an rpath, for example installed in
/foo it's gcc a.c `/foo/bin/curl-config --cflags --libs` -Wl,-rpath,/foo/lib
Received on 2017-08-21