rabbitmq error log "SSL: certify: ssl_handshake.erl:1341:Fatal error: unknown ca"

[mach...@gmail.com]

I have a rabbitmq install that is part of a Sensu server install. It was installed via a Chef recipe. Sensu was working fine until about 1-2 months back when suddenly w/o any changes I'm aware of (that doesn't mean someone else didn't touch something although I doubt it) Sensu stopped working. On investigation I am suspicious of something I see in the rabbitmq logs. This started close to the time Sensu stopped working. I'm not sure if they are exactly coincident or not tho.

=ERROR REPORT==== 6-Nov-2015::03:49:19 ===

Error on AMQP connection <0.20573.1>:

{ssl_upgrade_error,{tls_alert,"unknown ca"}}

=ERROR REPORT==== 6-Nov-2015::03:49:19 ===

SSL: certify: ssl_handshake.erl:1341:Fatal error: unknown ca

I took a look at the rabbitmq ssl troubleshooting page here https://www.rabbitmq.com/troubleshooting-ssl.html. No dice. The pem key and cert all check out fine. Erlang is installed with SSL support. I can make local client connections. Yet the SSL error persists. At this point I'm not sure if the error is actually even real. I do know however that this was working at one point with what should be the exact same Chef recipe. So I'm very perplexed. 

[Michael Klishin]

This means the server doesn't trust the CA certificate used by a client. There are many similar discussions in list archives.

--
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 email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mach...@gmail.com]

The similar discussions haven't helped me yet. I tried ensuring permissions on the SSL crts and making sure they are owned and viewable by the rabbitmq user. I tried verifying SSL support in erlang. I tried remaking and testing the key/cert from scratch. I'm currently trying various combinations of different versions of installed packages. Extremely frustrating.

[Michael Klishin]

On 6 November 2015 at 07:38:21, mach...@gmail.com (mach...@gmail.com) wrote:
> The similar discussions haven't helped me yet. I tried ensuring
> permissions on the SSL crts and making sure they are owned and
> viewable by the rabbitmq user. I tried verifying SSL support
> in erlang. I tried remaking and testing the key/cert from scratch.
> I'm currently trying various combinations of different versions
> of installed packages. Extremely frustrating.

The issue is neither of those. If you're seeing this error at all, your Erlang build *does* support
TLS and it is used.

The issue is that the Certificate Authority (CA) that signed your client's certificate and key pair
is not trusted by the server. This has been explained before on the list (and this list is not about TLS or
PKI or anything of that nature) but a very brief version:

 * Every certificate/key pair, whether used by client or server, is signed by some CA,
   which form a chain, going all the way up to "trusted CAs" (e.g. Verisign, or your company's top level CA)
 * Both server and client, when it receives a CA certificate, verifies it against a list of CAs it trusts.
 * Verification in the step above can walk up the chain of certificates, see "Certificate Chains and Verification Depth" on http://www.rabbitmq.com/ssl.html.
 * Clients and servers alike will reject certificates signed by unknown/untrusted (terms used interchangeably)
   CAs.

Your server is unaware of the CA that signed your client's certificate. You need to add the *client* CA
to the list of trusted CAs in your server OS (how that is done depends on the OS) or generate both
server and client certificates using *the same* CA.

Yes, TLS/PKI can be frustrating. Please invest a bit of time into understanding how it works, because
there is nothing RabbitMQ-specific about the root cause and you likely will have to use TLS again in
the future. 
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[mach...@gmail.com]

I took my crt (in pem format) and convert to crt. Copy to /usr/local/share/ca-certificate and run update-ca-certificates. Still no dice. Exact same error. I think I might start crying soon. Literally been at this for about 12 hours now. This is the exact same ca, cert, and key (I compared file times and md5s with s3 backups) that have been working on this exact same server for over 1 year w/o issue. If you are right that the CA is not trusted, then how the heck did this ever work period? I've used SSL/TLS with Apache httpd, Tomcat, Mongo, MySQL, nginx, lighttpd, and others. I won't claim to be an expert on SSL, but I'm not inexperienced either. Remember all of this is all installed via Chef so it's not like the install process is different. The only thing I can think of that can be different is the version of packages apt-get installs. If the rabbitmq ssl troubleshooting page says that this error is "generic" (see here https://www.rabbitmq.com/ssl.html), and if there are threads like this one that are similar to mine (https://github.com/sensu/sensu/issues/683) then why can't my issue be something other than the crt? 

I'm going to have to put this to rest for a few hours and try again with a fresh set of eyes tomorrow. Maybe retrace every single step from the ground up. Might give erlang 18 a shot as well. If there's anything else you can think of I'm all ears. I appreciate the time your donated thus far.

[Michael Klishin]

On 6 November 2015 at 10:35:47, mach...@gmail.com (mach...@gmail.com) wrote:
> I'm going to have to put this to rest for a few hours and try again
> with a fresh set of eyes tomorrow. Maybe retrace every single
> step from the ground up. Might give erlang 18 a shot as well. If
> there's anything else you can think of I'm all ears. I appreciate
> the time your donated thus far.

Some specific things to try:

 * openssl s_client and s_server (as mentioned in http://www.rabbitmq.com/troubleshooting-ssl.html) to test both client and server
 * CA chain verification depth (configurable for both clients and servers) and concatenation. This is what can differ from tool to tool,
   e.g. in Nginx you must provide a single concatenated file with certificates
 * a different Erlang/OTP version, although a couple of known Erlang issues are all in the crypto module 

[mach...@gmail.com]

Thanks again for helping me on this. I can't say that loud enough.

1)  * openssl s_client and s_server....

Done. Checks out fine. I get "Verify return code: 0 (ok)" on the client. 

2) CA chain verification depth

I set this to {depth, 2}, on rabbitmq server. Also set it in the client. No change.

3) I'm a bit out of my normal realm on this one. Erlang is totally new to me. dpkg -s erlang-nox says "Version: 1:16.b.3-dfsg-1ubuntu2.1". You're saying go to erlang site, download version 17 or 18, and compile from source. Correct?

[Michael Klishin]

On 7 November 2015 at 00:23:23, mach...@gmail.com (mach...@gmail.com) wrote:
> I'm a bit out of my normal realm on this one. Erlang is totally
> new to me. dpkg -s erlang-nox says "Version: 1:16.b.3-dfsg-1ubuntu2.1".
> You're saying go to erlang site, download version 17 or 18, and
> compile from source. Correct?

No need to compile from source. See 

 * https://www.erlang-solutions.com/downloads/download-erlang-otp
 * http://www.rabbitmq.com/releases/erlang/ (if you run on a RHEL-derivative) — our package is zero dependency and much less finicky to install. Note that it also provides just enough to run RabbitMQ but not the entire Erlang/OTP. Crypto and TLS are included, of course.

Only RabbitMQ 3.5.6 can run on Erlang 18.1 but for most people 17.5 is just as good as 18.0 or 18.1. 

[m@]

Out of frustration I decided to take another approach. I started completely over from scratch. Fully brand new AWS instance using Amazon Linux (CentOS 6 like) instead of Ubuntu (my preference anyways). Installed everything from scratch. Currently I have Sensu/RabbitMQ/Uchiwa/Redis running, and the UI served via Apache my using ProxyPass for Uchiwa 3000 <-> 443. SSL in the browser is working fine. And so far no glaring errors in any of the logs. 

Next step is to install a remote client and then if that works give SSL a shot. What a pain in the neck this has been. I have to take a break for a bit, but will follow up soon on whether or not this works. 

[mach...@gmail.com]

Well, I didn't figure out my problem. I don't think I've ever had such a frustrating SSL error. All I care about now is working around it. In order to do that I installed everything from scratch on a new server and used a SSL cert signed by an authority. I ditched the self signed cert. I know that's not an answer but wanted to let the community know that at least got me a bit further. Now when I start rabbitmq I get a different error (tls_handshake.erl:114:Fatal error: insufficient security) which feels like I'm getting somewhere on the surface. I'll open up the new error in a new thread. If anyone hits my old error in the future here is what I'd do...

self signed certs that work in other software (Apache, Mysql, Mongodb, Tomcat...) may be problematic in Erlang/RabbitMQ. Use a cert signed by a 3d party authority instead. Seems like silly overkill for local internal traffic behind a VPN, but whatever. I'm sure there is a better solution here, and if anyone finds it please let me know. I suspect this has something to do with Erlang/Ubuntu, not rabbitmq. 

On Friday, November 6, 2015 at 4:01:31 PM UTC-8, m@ wrote:

Out of frustration I decided to take another approach. I started completely over from scratch. Fully brand new AWS instance using Amazon Linux (CentOS 6 like) instead of Ubuntu (my preference anyways). Installed everything from scratch. Currently I have Sensu/RabbitMQ/Uchiwa/Redis running, and the UI served via Apache my using ProxyPass for Uchiwa 3000 <-> 443. SSL in the browser is working fine. And so far no glaring errors in any of the logs. 

Next step is to install a remote client and then if that works give SSL a shot. What a pain in the neck this has been. I have to take a break for a bit, but will follow up soon on whether or not this works. 

> I'm a bit out of my normal realm on this one. Erlang is totally
> new to me. dpkg -s erlang-nox says "Version: 1:16.b.3-dfsg-1ubuntu2.1".
> You're saying go to erlang site, download version 17 or 18, and
> compile from source. Correct?

[Michael Klishin]

On 9 November 2015 at 22:38:08, mach...@gmail.com (mach...@gmail.com) wrote:
> tls_handshake.erl:114:Fatal error: insufficient security

This means RabbitMQ and client could not agree on a cipher suite, see
http://erlang.org/pipermail/erlang-questions/2015-January/082786.html to find out what suites are
supported by your runtime.

[mach...@gmail.com]

Here is the output of the two commands.

5> io:format("~p", [ssl:cipher_suites(openssl)]).

["ECDHE-ECDSA-AES256-SHA384","ECDHE-RSA-AES256-SHA384",

 "ECDH-ECDSA-AES256-SHA384","ECDH-RSA-AES256-SHA384","DHE-RSA-AES256-SHA256",

 "DHE-DSS-AES256-SHA256","AES256-SHA256","ECDHE-ECDSA-AES128-SHA256",

 "ECDHE-RSA-AES128-SHA256","ECDH-ECDSA-AES128-SHA256",

 "ECDH-RSA-AES128-SHA256","DHE-RSA-AES128-SHA256","DHE-DSS-AES128-SHA256",

 "AES128-SHA256","ECDHE-ECDSA-AES256-SHA","ECDHE-RSA-AES256-SHA",

 "DHE-RSA-AES256-SHA","DHE-DSS-AES256-SHA","ECDH-ECDSA-AES256-SHA",

 "ECDH-RSA-AES256-SHA","AES256-SHA","ECDHE-ECDSA-DES-CBC3-SHA",

 "ECDHE-RSA-DES-CBC3-SHA","EDH-RSA-DES-CBC3-SHA","EDH-DSS-DES-CBC3-SHA",

 "ECDH-ECDSA-DES-CBC3-SHA","ECDH-RSA-DES-CBC3-SHA","DES-CBC3-SHA",

 "ECDHE-ECDSA-AES128-SHA","ECDHE-RSA-AES128-SHA","DHE-RSA-AES128-SHA",

 "DHE-DSS-AES128-SHA","ECDH-ECDSA-AES128-SHA","ECDH-RSA-AES128-SHA",

 "AES128-SHA","ECDHE-ECDSA-RC4-SHA","ECDHE-RSA-RC4-SHA","RC4-SHA","RC4-MD5",

 "EDH-RSA-DES-CBC-SHA","ECDH-ECDSA-RC4-SHA","ECDH-RSA-RC4-SHA","DES-CBC-SHA"]ok

6> io:format("~p", [ssl:cipher_suites(erlang)]).

[{ecdhe_ecdsa,aes_256_cbc,sha384},

 {ecdhe_rsa,aes_256_cbc,sha384},

 {ecdh_ecdsa,aes_256_cbc,sha384},

 {ecdh_rsa,aes_256_cbc,sha384},

 {dhe_rsa,aes_256_cbc,sha256},

 {dhe_dss,aes_256_cbc,sha256},

 {rsa,aes_256_cbc,sha256},

 {ecdhe_ecdsa,aes_128_cbc,sha256},

 {ecdhe_rsa,aes_128_cbc,sha256},

 {ecdh_ecdsa,aes_128_cbc,sha256},

 {ecdh_rsa,aes_128_cbc,sha256},

 {dhe_rsa,aes_128_cbc,sha256},

 {dhe_dss,aes_128_cbc,sha256},

 {rsa,aes_128_cbc,sha256},

 {ecdhe_ecdsa,aes_256_cbc,sha},

 {ecdhe_rsa,aes_256_cbc,sha},

 {dhe_rsa,aes_256_cbc,sha},

 {dhe_dss,aes_256_cbc,sha},

 {ecdh_ecdsa,aes_256_cbc,sha},

 {ecdh_rsa,aes_256_cbc,sha},

 {rsa,aes_256_cbc,sha},

 {ecdhe_ecdsa,'3des_ede_cbc',sha},

 {ecdhe_rsa,'3des_ede_cbc',sha},

 {dhe_rsa,'3des_ede_cbc',sha},

 {dhe_dss,'3des_ede_cbc',sha},

 {ecdh_ecdsa,'3des_ede_cbc',sha},

 {ecdh_rsa,'3des_ede_cbc',sha},

 {rsa,'3des_ede_cbc',sha},

 {ecdhe_ecdsa,aes_128_cbc,sha},

 {ecdhe_rsa,aes_128_cbc,sha},

 {dhe_rsa,aes_128_cbc,sha},

 {dhe_dss,aes_128_cbc,sha},

 {ecdh_ecdsa,aes_128_cbc,sha},

 {ecdh_rsa,aes_128_cbc,sha},

 {rsa,aes_128_cbc,sha},

 {ecdhe_ecdsa,rc4_128,sha},

 {ecdhe_rsa,rc4_128,sha},

 {rsa,rc4_128,sha},

 {rsa,rc4_128,md5},

 {dhe_rsa,des_cbc,sha},

 {ecdh_ecdsa,rc4_128,sha},

 {ecdh_rsa,rc4_128,sha},

 {rsa,des_cbc,sha}]ok

[Chris]

Fnord.
Now I got the very same issue, almost 2 years later.

Short summary:
Trying to TLS with my RabbitMQ-server.
Config looks nice - i think.
Certs are all proper.
openssl s_server / s_client works perfectly but I get

SSL: certify: ssl_handshake.erl:1625:Fatal error: unknown ca

on the server when I try to talk with RabbitMQ.

I thought the ssl-depth setting was interesting and set it to 5, but that was not it :(

config is:

        {ssl_listeners, [{"127.0.0.1", 5671}, {"10.x.y.z", 5671}]},
        {ssl_options, [{cacertfile, "/var/lib/rabbitmq/certs/ca-chain.pem"},
                   {certfile, "/var/lib/rabbitmq/certs/dssweb-dev-cert.pem"},
                   {keyfile, "/var/lib/rabbitmq/certs/dssweb-dev-key.pem"},
                   {versions, ['tlsv1.2']},
                   {depth, 5},
                   {ciphers,  [
                                      {ecdhe_ecdsa,aes_256_gcm,null,sha384},
                                      {ecdhe_rsa,aes_256_gcm,null,sha384},
                                      {ecdh_ecdsa,aes_256_gcm,null,sha384},
                                      {ecdh_rsa,aes_256_gcm,null,sha384},
                                      {dhe_rsa,aes_256_gcm,null,sha384},
                                      {rsa,aes_256_gcm,null,sha384},
                                      {ecdhe_ecdsa,aes_128_gcm,null,sha256},
                                      {ecdhe_rsa,aes_128_gcm,null,sha256},
                                      {ecdh_ecdsa,aes_128_gcm,null,sha256},
                                      {ecdh_rsa,aes_128_gcm,null,sha256},
                                      {dhe_rsa,aes_128_gcm,null,sha256},
                                      {ecdh_rsa,aes_128_gcm,null,sha256}
                                     ]},
                               {honor_cipher_order,   true},
                               {honor_ecc_order,      true},
                               {secure_renegotiate,   true},
                   {password, "************************"},
                   {verify, verify_peer},
                   {fail_if_no_peer_cert,true}]}
    ]}

Any new methods for troubleshooting in the meantime?

Thanks for your work so far and I hope we can figure this out together.
Cheers!
chris :)

[Michael Klishin]

"unknown ca" is fairly unambiguous: the CA that signed the certificate used
by a client connection is not trusted on the RabbitMQ host. Certificate

chain traversal depth only makes a difference when you have, well, chains of certificate

authorities involved.

Are all CAs bundled into client's CA certificate file? Was the root (or at least one of the certificates in that chain)

added to the trusted certificate directory on RabbitMQ's node? [1][2]

This is a fairly generic TLS question (nothing particularly specific to RabbitMQ) and has been discussed many times in the past:

https://groups.google.com/forum/#!searchin/rabbitmq-users/unknown$20CA%7Csort:relevance

1. https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/

2. http://gagravarr.org/writing/openssl-certs/others.shtml

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

[Chris]

Hello MIchael,

thanks for answering. I understand that it seems basic. But I had hoped that my mentioning of "openssl s_client vs s_server works" would raise some alarm bells. Because that would basically prove that the certs are all okay - yet it still does not work with RabbitMQ, as it was not working for the person who started this thread.

Can anyone devise a very basic Erlang SSL server, which we can try to limit the components used? I have already done so on my client-side by using a bare-bones python ssl-socket and openssl from the CLI (both fail). Can anyone look at the Erlang code and figure out what it is doing there that might upset it with our certs? Is there a debug option on the Erlang ssl lib?

If anyone's time allows, I'd be happy to do a screen-share to forego lengthy, written back and forths. Just use my machine to hack your way through the problem. I'd gladly be proven wrong here.

Cheers!

chris :)

To post to this group, send email to rabbitm...@googlegroups.com.

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

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

--
You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rabbitmq-users/NK9gZeFOTwQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rabbitmq-users+unsubscribe@googlegroups.com.

[Luke Bakken]

Hi Chris,

I suggest using the openssl verify command as well. This is the method I most frequently use to verify certs with CA certs.

Luke

[Michael Klishin]

`openssl s_client` and `openssl s_server` can be used in different ways. They usually only prove that certificates are

sane but those tools are absolutely oblivious of how those certificates are used.

For example, if the client doesn't provide all certificates in the chain or none of them are trusted on the server end

or verification depth is insufficient, OpenSSL tools are not guaranteed to catch them *unless you replicate

the exact connection and trust store environment*.

Your config file limits TLS version, cipher suites, requires a client certificate and performs peer verifications.

That's all well and good but each of those increases the chances of client connection being rejected.

Start with allowing TLSv1 though 1.2, not limiting the cipher suite, not requiring client certificates and gradually

add them.

Again, "unknown CA" is fairly unambiguous, at least as far as TLS alarms go. And as far as I can tell it is the server that logs it,

so you need to focus on investigating your client's configuration and whether *client* CA is trusted, not look

at the Erlang code.

TLS handshake and peer verification has two parties involved. What makes you believe it is RabbitMQ that's at fault?

[Michael Klishin]

a few specific questions I have not seen a clarification on : what's client certificate chain is like?

How was it produced? Is there signing root CA in that chain in the trusted certificate store on all RabbitMQ hosts? If it is, how was it added there?

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 email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

--
You received this message because you are subscribed to a topic in the Google Groups "rabbitmq-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rabbitmq-users/NK9gZeFOTwQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rabbitmq-user...@googlegroups.com.

To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

--

Staff Software Engineer, Pivotal/RabbitMQ

[Michael Klishin]

More questions :

With the current setup, does replacing your client with OpenSSL s_client produce the same outcome?

Can you post a shell transcript or OpenSSL output?

How exactly was OpenSSL s_server tested? Was it against a real client? Can we get the output?

Lastly, how is the client TLS context (connection) was set up? Can you share relevant code snippets?

[Chris]

Dear community, dear Michael,

thank you for taking the time to think about this.
During my time working with this I learned that I have no clue how TLS works and that getting something to run with openssl s_client and s_server is nice, but does not necessarily mean anything with other clients.

Having a cert with quite a long chain, it would have been nice to know from the error which one of the certs has caused the 'unknown CA' message.
Recently my coworker has changed something and now it works. I have no idea really what it was but I assume it has something to do with putting the the whole CA chain onto the client. Server and client have certs from the same CA signed by .. well. dunno. As I said I have no clue who signed what here. anymore :(
I thought the cert was signed by the first intermediate and it would have been enough to have its key in the chain - because if I trust that, then the cert is okay. But I was wrong. Maybe the cert of the last CA that signed it must be trusted. Or all of them. I don't know.

A tidbit: the Erlang SSL lib has a parameter called "depth", which a different coworker said that it was he who requested that parameter to be added, because our company has such funny certs that we need it. OMG: our certs are so strange that we even need special params made. Well. Haha. Whatever. It works now and I hope we can reproduce it again when going into production and then never have to touch it again. *frown*

Thanks again :)

In case you're wondering: this is the CA-chain which I now use on the client, it is the same as the server uses:

subject= /C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA
subject= /C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2
subject= /C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2

Here is some bits of information from the Server-cert

{'OCSP': ('http://ocsp.pca.dfn.de/OCSP-Server/OCSP',),
 'caIssuers': ('http://cdp1.pca.dfn.de/dfn-ca-global-g2/pub/cacert/cacert.crt',
               'http://cdp2.pca.dfn.de/dfn-ca-global-g2/pub/cacert/cacert.crt'),
 'crlDistributionPoints': ('http://cdp1.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.crl',
                           'http://cdp2.pca.dfn.de/dfn-ca-global-g2/pub/crl/cacrl.crl'),
 'issuer': ((('countryName', 'DE'),),
            (('organizationName',
              'Verein zur Foerderung eines Deutschen Forschungsnetzes e. '
              'V.'),),
            (('organizationalUnitName', 'DFN-PKI'),),
            (('commonName', 'DFN-Verein Global Issuing CA'),)),
 'notAfter': 'Nov 17 06:05:33 2020 GMT',
 'notBefore': 'Aug 21 06:05:33 2017 GMT',
 'serialNumber': '1DB9F5BCFBD60B1CC1F67B0D',
 'subject': ((('countryName', 'DE'),),
             (('stateOrProvinceName', 'Bayern'),),
             (('localityName', 'somewhere'),),
             (('organizationName', 'some org'),),
             (('organizationalUnitName', 'some department'),),
             (('commonName', 'someserver.de'),)),
 'subjectAltName': (('DNS', 'someserver.de'),),
 'version': 3}

I guess my take on it was: if I download what it says here 'caIssuers' I'll be fine. I was not.
Cheers!
chris :)

[Michael Klishin]

> Having a cert with quite a long chain, it would have been nice to know from the error which one of the certs has caused the 'unknown CA' message. 

All of them did. "Unknown CA" means that none of the certificates in the presented chain are trusted on the current node. "Current node"

here can be a RabbitMQ node or a client (because peer verification can work both ways).