TLS issues with .Net Core on Linux

[Dan Bason]

Hi,

We are running EasyNetQ on the .Net Core docker image (Debian based) connecting via TLS to RabbitMQ 3.6.3.  When we turn on certificate verification in the client the connection fails, however with it off the connection is successful.  We have installed the CA we use into the container using update-ca-certificates.

We have tested with openssl s_client from in the container, and this successfully connects.  We also have EasyNetQ running on Windows (with the CA installed into the Windows Cert store), and a nodejs client connecting to the same broker and these work with no problems, so the issue seems to be confined to the .Net Core client running on Linux.

The error we get in the broker log is:

2017-02-02T00:05:53.588444400Z =ERROR REPORT==== 2-Feb-2017::00:05:53 ===
2017-02-02T00:05:53.588459700Z SSL: certify: ssl_connection.erl:456:Fatal error: handshake failure

Has anyone seen anything similar to this or do they have any advice/further troubleshooting steps?

Regards

Dan

[Michael Klishin]

No shortage of threads in list archives. RabbitMQ does not implement TLS, Erlang/OTP does.

There is a TLS troubleshooting guide on rabbitmq.com, multiple Erlang versions to try, and plenty
of archive threads.

> --
> You received this message because you are subscribed to the Google Groups "rabbitmq-users"
> group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
> To post to this group, send an email to rabbitm...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Michael Klishin]

…and server logs, obviously. 

On 2 February 2017 at 04:15:57, Dan Bason (colon...@gmail.com) wrote:

[Dan Bason]

Hi Michael,

This isn't an issue with RabbitMQ or Erlang, it's specifically the .Net Core client running on Linux.  If we turn off SSL certificate checking it connects fine so it seems to be that on Linux it's not reading the CA store correctly and doesn't believe the server certificate is trusted.  We're using a certificate signed by a private CA, but the CA is added to the trusted store.  As mentioned this works in the nodejs client, and also in the .Net client on Windows so it seems to be limited to an issue with .Net core on Linux.  Also as I stated s_client works from inside the container so this shows the private CA is correctly added to the trusted CA bundle which is why I think it's a problem with the .Net client.

There's nothing in the sasl log and nothing further in the server log.  If there's any further information I can provide please let me know.

[Michael Klishin]

By "certificate checking" you mean TLS peer verification (authentication), correct?

Some of our team members use .NET Core exclusively when working on and testing .NET
client but it rarely happens on Debian. We haven't noticed any issues on Windows and OS X with
our test suite which does test TLS connections.

It seems to me that you've done fairly extensive testing with several clients, s_client, and from different OS'es
and I don't have much left to recommend (I don't follow .NET Core development closely enough).
Thank you for moving this to the mailing list and mentioning the various tests you've done
right from the start.

We extracted tls-gen [1] from our test suites a while back to make it easier to try a different
set of certificate/key pairs. Just saying.

1. https://github.com/michaelklishin/tls-gen

[Dan Bason]

Correct - peer verification for the cert presented by the server.  The majority of our dev work is done in .Net on Windows, but we're targeting Docker for some new stuff, and the Linux .Net Core image provide by Microsoft is Debian based which is why it came up.  I will try CentOS tomorrow to see if we get the same issue as if it works on OSX I don't see why it shouldn't work on Debian (I assume .Net Core uses openssl in both).

[Karl Nilsson]

Hi,

Our ci build for the dotnet client runs in a linux container and this does successfully run the SSL test suite. I don't know how update-ca-certificates works but here is an excerpt from the ci script that installs the certificates into the openssl store directory. Perhaps it will help.

OPENSSL_STORE_DIR=/usr/lib/ssl/certs

cp $SSL_DIR/testca/cacert.pem /usr/lib/ssl/certs

ln -s $OPENSSL_STORE_DIR/cacert.pem $OPENSSL_STORE_DIR/`openssl x509 -hash -noout -in $OPENSSL_STORE_DIR/cacert.pem`.0

Cheers

Karl

[Dan Bason]

Thanks Karl and Michael

We've turned some extra debugging on in the client and it appears the issue isn't the trust chain it's the cert name matching:

AMQP Debug:     Trying to connect

AMQP Debug:     SSL Policy Errors: RemoteCertificateNameMismatch

AMQP Debug:     Server certificate subject: [CN=*.bb2qa.local, O=company, L=city, C=NZ]

AMQP Debug:     Server certificate issuer: [CN=bb2qaSubCA, DC=bb2qa, DC=local]

AMQP Debug:     Server chain status: [NoError

AMQP Debug:     Server chain certificate subject: [CN=*.bb2qa.local, O=company, L=city, C=NZ]

AMQP Debug:     Server chain certificate subject: [CN=bb2qaSubCA, DC=bb2qa, DC=local]

AMQP Debug:     Server chain certificate subject: [CN=DiligentRootCANP]

AMQP Error:     Failed to connect to Broker: 'chc01q1bbrmq02.bb2qa.local', Port: 5671 VHost: 'test'. ExceptionMessage: 'None of the specified endpoints were reachable'

AMQP Error:     Failed to connect to any Broker. Retrying in 00:00:05

It looks like it's not honouring the wildcard properly?

[Michael Klishin]

Note that wildcard matching isn't a mandatory feature (at least in some contexts, maybe there's another RFC I'm not aware of) [1].

It's possible to configure your own verification function, though.

1. https://tools.ietf.org/html/rfc6125#section-6.4.3

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.