mosquitto-users team mailing list archive

[Roger Light <roger@xxxxxxxxxx>]

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.stokes@xxxxxxxxxxxxx> 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.