mosquitto-users team mailing list archive

[Duncan Stokes <duncan.stokes@xxxxxxxxxxxxx>]

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.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.