Hi Roger, as it turns out, yes it does... both server1.stokesnz.net AND www.server1.stokesnz.net (hadn't noticed before - not sure why the CA has done that).
Regards, Duncan. On 05/09/13 22:00, Roger Light wrote: > Hi Duncan, > > Do your problem certificates use a subjectAltName? If you're not sure, > you can use: > > openssl x509 -in server.crt -noout -text > > to print out the certificate details and search for a line like " > X509v3 Subject Alternative Name". > > Cheers, > > Roger > > > > On Thu, Aug 22, 2013 at 10:44 PM, Duncan Stokes > <duncan.sto...@eyemagnet.com> wrote: >> Hi Roger, thanks for replying so quickly. >> >>> Hi Duncan, >>> >>> Thanks for the detailed email. First off, I can say that this should >>> work. The broker and client library tests for SSL use a >>> root->intermediate->server/client chain for signing. >> You're welcome, and good to hear that is *should* be being catered for. >> >>> I suppose that's >>> a good place to start - if you download the 1.2 tarball and run "make >>> test" in the extracted directory, does it segfault? The test don't use >>> mosquitto_pub/sub themselves so doesn't exactly match your case, but >>> it's a good start. >> Tarball downloaded, extracted and 'make test' run WITHOUT any apparent >> errors, so that's a good start (openssl-devel required - but we all knew >> that). >> >>>> Error #2 - intermediary CA certificate supplied: >>> This is also anticipated, you should pass (and should only need to >>> pass) the root CA certificate. The server should provide the other >>> certificates in the chain. >> Agreed, and I meant to add that this was expected behaviour (but clearly >> overlooked this). >> >>>> Error #3 - primary CA certificate supplied (or a file with both >>>> intermediary and primary CA certs present): >>>> [tester@f19-client ~]$ mosquitto_pub -i mosq_pub_dunc -h >>>> server1.stokesnz.net -p 8883 -t test/msg/2 -m "Test to 8883 q2 #1" -d -r >>>> -q 2 --tls-version tlsv1.2 --cafile AddTrustExternalCARoot.crt >>>> Client mosq_pub_dunc sending CONNECT >>>> Segmentation fault (core dumped) >>> This is bad, obviously. >>> >>> I'll try and reproduce this myself on Fedora, but it might be a few >>> days because I've got a work deadline on Monday and am working all >>> hours. >> No rush - we have a functional solution for in-house use (i.e., >> self-signed non-intermediary). >> >> I can confirm that the segfault is still evident subsequent to removing >> the mosq-client and library (via yum remove) then performing 'make >> install' (FYI - I had to add /usr/local/bin to the path and >> /usr/local/lib to /etc/ld.so.conf then ldconfig - but that was on a >> recently rebuilt F19 box). So, it does not appear to be an rpm creation >> issue (and as rpmbuild performs the make and package tasks consistent >> with this approach that isn't particularly surprising). >> >>>> Thoughts!? Whilst I'm happy enough to use self-signed SSL certificates >>>> I thought it wise to air this issue as CA certificate chains are >>>> becoming more and more prevalent. >>> Agreed, it should definitely work with chains. It definitely shouldn't >>> segfault, either way! >> Indeed, segfaults are sub-optimal! >> >> Regards, >> Duncan.
-- Mailing list: https://launchpad.net/~mosquitto-users Post to : mosquitto-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~mosquitto-users More help : https://help.launchpad.net/ListHelp
