SSL/TLS connection issue: unable to get issuer certificate

[pfc.c...@gmail.com]

I'm trying to activate SSL/TLS on my RabbitMQ server (hosted on Windows).

I succesfully installed a Let's encrypt certificate on my IIS web server hosted on the same Windows server. (https://www.raptordev.ch)

This certificate is stored in the Windows certificate store. (It has been installed by Letsecrypt_Win_Simple.exe utility downloaded from here: https://github.com/Lone-Coder/letsencrypt-win-simple)

My "www.raptordev.ch" certificate is signed by the Let's encrypt intermediate CA "Let's Encrypt Authority X3"

To configure RabbitMQ I need the www.raptordev.ch certificate as a .pem file as well as the private key and the CA certificate as a .pem file too. 

So I exported my "www.raptordev.ch" certificate (with the private key) from the Windows certificate store as a RaptordevCertificate.pfx file using mmc.exe. (I had to choose a password to encrypt the private key in the .pfx file)

I then used openssl.exe to convert my .pfx certificate to a .pem file (as RaptordevCertificate.pem) this way:

> openssl pkcs12 -in c:\Certificates\RaptordevCertificate.pfx -out c:\Certificates\RaptordevCertificate.pem -nodes

I also downloaded the Let's encrypt X3 intermediate certificate as a .pem file from https://letsencrypt.org/certificates/ ( Let’s Encrypt Authority X3 (Signed by ISRG Root X1) as letsencryptauthorityx3.pem )

I configured the ssl_listener and sss_options of my RabbitMQ server with my www.raptordev.ch certificate (as server certfile and keyfile) and the Let's Encrypt Authority X3 certificate as cacertifile this way:

[
 {rabbit,
  [
           {ssl_listeners, [5671]},
           {ssl_options, [{cacertfile,"C:/certificates/letsencryptauthorityx3.pem"},
                          {certfile,  "C:/certificates/RaptordevCertificate.pem"},
                          {keyfile,   "C:/certificates/RaptordevCertificate.pem"},
                          {password,  "myprivatekeyprotectingpassword"},
                          {verify,verify_peer},
                          {fail_if_no_peer_cert,false}
                         ]}
  ]}
].

(Notice that I gave the password to access my private key from my RaptordevCertificate.pem file with the {password} option.)

I restarted the RabbitMQ server and found the following info reports lines in the log, meaning that the ssl listener was succefully started on port 5671:

=INFO REPORT==== 30-Mar-2017::17:30:59 ===
started SSL Listener on [::]:5671

=INFO REPORT==== 30-Mar-2017::17:30:59 ===
started SSL Listener on 0.0.0.0:5671

Unfortunately my RabbitMQ client application was unable to reach the broker when configured for an ssl connection. (It raised an UnreachableBrokerException)

I also tried to access the ssl port directly from a browser on the server with the following url https://localhost:5671 but got no answer. (I expected to get the four AMQP letters.)

I then tried to proceed with the troubleshooting proposed at https://www.rabbitmq.com/troubleshooting-ssl.html and typed the following openssl s_client -connect command from a command prompt on my server:

>openssl s_client -connect localhost:5671 -cert c:/Certificates/RaptordevCertificate.pem -key c:/Certificates/RaptordevCertificate.pem -CAfile c:/Certificates/letsencryptauthorityx3.pem

And I got the following response with an error "unable to get issuer certificate":

CONNECTED(0000013C)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=2:unable to get issuer certificate
issuer= C = US, O = Internet Security Research Group, CN = ISRG Root X1
4548:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:ssl\reco
rd\rec_layer_s3.c:1385:SSL alert number 48
---
Certificate chain
 0 s:/CN=www.raptordev.ch
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFBDCCA+ygAwIBAgISA3Hwf7Qh/Pj/sP3jwOLzO7D9MA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xNzAzMjQxNTQ1MDBaFw0x
NzA2MjIxNTQ1MDBaMBsxGTAXBgNVBAMTEHd3dy5yYXB0b3JkZXYuY2gwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCaLeygia2SeAmv+9vWW6Y5mF8ddhTc
YEA6vAgNYr9FvfW3zaE4JPjahl4tkED0YQRQFJdZvC3AnwxyACCYmVEUEbBoO7bd
iHIbiphAVQ8pE+C+tZXAsOyNgcLdCeZz9x89JsSy0HnxqsQ32VD3z+pkZ6cFm9KG
qGz+WUIJWm67ny0op/cugbkG3+bnM5JXyXVj3v9VsFgCldFE52wxjwtxE9HCd3M1
AQeWxAJV2VbwtPizuZijcQ1OiWRwQHrlJLrHS5Xp2ZWAdwbN002YFYLG31Wvcrug
CHrv87r8vzER41BWpptcgL40HODYyyb9PWOW6ewENtZcMhdTtRR9ch4jAgMBAAGj
ggIRMIICDTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFPZ37nH4bHRlUGhNOISvF6vs
3u3pMB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMHAGCCsGAQUFBwEB
BGQwYjAvBggrBgEFBQcwAYYjaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0
Lm9yZy8wLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5jcnlw
dC5vcmcvMBsGA1UdEQQUMBKCEHd3dy5yYXB0b3JkZXYuY2gwgf4GA1UdIASB9jCB
8zAIBgZngQwBAgEwgeYGCysGAQQBgt8TAQEBMIHWMCYGCCsGAQUFBwIBFhpodHRw
Oi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCBqwYIKwYBBQUHAgIwgZ4MgZtUaGlzIENl
cnRpZmljYXRlIG1heSBvbmx5IGJlIHJlbGllZCB1cG9uIGJ5IFJlbHlpbmcgUGFy
dGllcyBhbmQgb25seSBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIENlcnRpZmljYXRl
IFBvbGljeSBmb3VuZCBhdCBodHRwczovL2xldHNlbmNyeXB0Lm9yZy9yZXBvc2l0
b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAMSLhUL4s2wv8Jor7TGMytFuNlolCQbVX
YMDcP/vAH0mR075qyToAkSqFDdPkQG92FB3u0Wr85xQMXxShK8v2g3XzQ23FtbWD
WepCGEdjLg8N4ZnsmYDoA1+byRlGYWlcmAgRz8MA14YjYbHxx0Y+aCyEKrXBt8gc
WgaOisLcE3UxO4zpZElt6ltF0QXAWmWpMb+LjCqIMmwuSWmWYocVDp3zM4YjGjlJ
dZr60k8//LqcD1Js+H0Kegf/N5j/mDRzyhfGgl1uHRDm5B2BL8HvZ45kFvZOYaIC
xru44dADA5D6XtWgyK1P8bIJe4Z8IoKm7wRiYKALkogo8ontRJgSOw==
-----END CERTIFICATE-----
subject=/CN=www.raptordev.ch
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
Acceptable client certificate CA names
/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Client Certificate Types: ECDSA sign, RSA sign, DSA sign
Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+SHA384:
ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA512:RSA+SHA512:ECDSA+SHA384:RSA+
SHA384:ECDSA+SHA256:RSA+SHA256:ECDSA+SHA224:RSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+S
HA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3294 bytes and written 3302 bytes
Verification error: unable to get issuer certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 99C99C4C2DD0FFD38AB621210E19784BA793530264F8C654065BF79D280E6DBD

    Session-ID-ctx:
    Master-Key: A0379C3026EF9D17DBD3EADE396A774C81ED8C1F7340B0A90F80D1B9A6E8A0DB
34C1857A1E900A8E036B0BAB7554F226
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1490907433
    Timeout   : 7200 (sec)
    Verify return code: 2 (unable to get issuer certificate)
    Extended master secret: no
---

And in the RabbitMQ server log file the following error report was logged:

=ERROR REPORT==== 30-Mar-2017::21:57:13 ===
SSL: certify: ssl_handshake.erl:1606:Fatal error: unknown ca

Do you know what could have failed and what I made wrong ?

Maybe should I use the ISRG Root X1 certificate from ISRG Root X1 (self-signed) as isrgrootx1.pem instead of the letsencryptauthorityx3.pem I configured as cacertfile ?

Or maybe the IdentTrust cross signed X3 certificate from Let’s Encrypt Authority X3 (IdenTrust cross-signed)  as lets-encrypt-x3-cross-signed.pem ?

I'm a bit confused with this certificate stuff...

Thank you for your help.

[Michael Klishin]

> unknown ca

Client provided CA is not on the trusted list on RabbitMQ's host. Peer certificate chains (you see

the server one's printed by `openssl s_client`) must contain a certificate trusted *on this machine*

(so, in this case, it's RabbitMQ that rejects the chain) in order to be accepted.

Your config enables peer verification, so both server and client will apply certain rules to ensure

that the peer certificate can be trusted. The logic can be anything but by default the client will

verify that server's hostname matches the CN (Common Name) field in the certificate.

See "TLS Peer verification: Who do you say you are?" in http://www.rabbitmq.com/ssl.html.

I tried finding a tutorial-style introduction to TLS and verfiication + chain traversal in particular,

https://blog.talpor.com/2015/07/ssltls-certificates-beginners-tutorial/ looks decently.

There is no shortage of RFCs that cover related subjects, e.g. https://www.ietf.org/rfc/rfc4158.txt,

but once you understand the concept and what both server and client do, don't spend your time on it.

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

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[pfc.c...@gmail.com]

I'm not sure to understand everithing.

But I'm wondering if the explanation is not given here: https://letsencrypt.org/certificates/ 

In the "Cross Signing" paragraph it is said:

"Our intermediate is signed by ISRG Root X1. However, since we are a very new certificate authority, ISRG Root X1 is not yet trusted in most browsers. In order to be broadly trusted right away, our intermediate is also cross-signed by another certificate authority, IdenTrust, whose root is already trusted in all major browsers. Specifically, IdenTrust has cross-signed our intermediate using their DST Root CA X3.

That means there are two certificates available that both represent our intermediate. One is signed by DST Root CA X3, and the other is signed by ISRG Root X1. The easiest way to distinguish the two is by looking at their Issuer field.

When configuring a web server, the server operator configures not only the end-entity certificate, but also a list of intermediates to help browsers verify that the end-entity certificate has a trust chain leading to a trusted root certificate. Almost all server operators will choose to serve a chain including the intermediate certificate with Subject “Let’s Encrypt Authority X3” and Issuer “DST Root CA X3.” The official Let’s Encrypt software will make this configuration seamlessly."

Does it mean that I should configure the RabbitMQ server using the intermediate certificate cross-signed by IdenTrust using their DST Root CA X3 instead of the one signed by ISRG root X1 ?

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.

[pfc.c...@gmail.com]

Or should I simply store the ISRG Root X1 certificate in the Windows Certificate Store on the RabbitMQ Host ?

[Michael Klishin]

I don't think it fully applies because RabbitMQ is not a browser and does not ship a bundled set of root CA certificates.

Operating systems do, however. So well spotted.

On Fri, Mar 31, 2017 at 2:51 PM, <pfc.c...@gmail.com> wrote:

Or should I simply store the ISRG Root X1 certificate in the Windows Certificate Store on the RabbitMQ Host ?

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