PS: Thank you Ganesh and Paolo for taking the time to help me on this issue. I
would never have found it without your help! :)
Do you think it could be worth submitting a Jira issue for clearer error
messages?
Regards,
Adel
> From: adelbout...@live.com
> To: users@qpid.apache.org
> Subject:
Solved it!!
The order of the certificates in the chain file ca-chain.cert.pem is
important. I inverted the order of the certificates by putting the root
certificate before the intermediate and it worked.
Nevertheless, the error messages are not helpful...
Regards,
Adel
> From:
Following your lines :
SUCCESS
--> qdstat -c
--ssl-trustfile=PATH_TO_CERT_DIR/ganesh/ca-certificate.pem
--ssl-certificate=PATH_TO_CERT_DIR/ganesh/client-certificate.pem
--ssl-key=PATH_TO_CERT_DIR/ganesh/client-private-key.pem -b
amqps://machine:10397
FAILURE --> qdstat -c
Yes, everything is ran on the same machine. I had configured a single
dispatcher with 2 ports (1 for the "success" and one for the "failure") as
detailed in one of my previous mails.
Regards,
Adel
> From: ppatie...@live.com
> To: users@qpid.apache.org
> Subject: RE: [Qpid-Dispatch] SSL/SASL
Sorry I mean for the failure case both qdstat and router are on the same
machine but ... comparing "success" and "failure" are they executed on the same
machine ?
I see "machine" in the success case and "green-lx-slave1" for the failure.
Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
Nope, I
am using the same machine "green-lx-slave1". You can see from the
image the src and destination have the same ip (10.25.8.35)
I have
just exported the display of Wireshark on my local Windows machine. (sudo
wireshark &)
Could it be that my certificate or key are corrupt and that
Having no traffic in the failure case means that the tool doesn't send any
packets (it should be the first to send something with the "Server Hello"
message).
At least we should see the TCP handshake ... before the SSL handshake !
In this case the server configuration isn't playing any role in
Paolo,
There is no traffic in the case of the failure. So I cannot provide a pncap
file :(
> From: adelbout...@live.com
> To: users@qpid.apache.org
> Subject: RE: [Qpid-Dispatch] SSL/SASL configuration on a listener
> Date: Fri, 24 Jun 2016 17:35:56 +0200
>
> It seems like attachments are not
It seems like attachments are not really working. You can check the images
here: http://imgur.com/a/WlssO
Adel
From: adelbout...@live.com
To: users@qpid.apache.org
Subject: RE: [Qpid-Dispatch] SSL/SASL configuration on a listener
Date: Fri, 24 Jun 2016 17:31:45 +0200
Wireshark Pictures
Sorry Adel I can't see the pictures.
Having the pncap files could be better. I'll load them into Wireshark here and
filter the traffic.
Thanks.
Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor
Twitter : @ppatierno
Linkedin :
Success
===
Failure
> From: adelbout...@live.com
> To: users@qpid.apache.org
> Subject: RE: [Qpid-Dispatch] SSL/SASL configuration on a listener
> Date: Fri, 24 Jun 2016 17:26:44 +0200
>
> I fixed the CN part (Thanks Paolo)
>
> I also ran
I fixed the CN part (Thanks Paolo)
I also ran Wireshark and it seems that the failure is way before establishing a
connection as I have no packets being transfered in the case of the failing
certificate.
I filtered on the tcp ports of the success and the failure. I have 0 packets in
the
So the typo on CN can't be the problem for Adel issue :-(
Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor
Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience
> Date: Fri, 24 Jun 2016 11:17:18 -0400
> From:
Good catch Paolo, I should note here that qdstat and qdmanage commands do *not*
do hostname verification by default. I submitted a pull request for
https://issues.apache.org/jira/browse/DISPATCH-401 which is not in master yet.
Thanks.
- Original Message -
> From: "Paolo Patierno"
Hi Adel,
is this just a typo or the real CN you are using ?
/CN=CN=127.0.0.1
In this case the CN is "CN=127.0.0.1" that is different from 127.0.0.1 so the
verify host name could fail.
It should be :
/CN=127.0.0.1
Paolo.
Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
Microsoft MVP on
Hi Adel,
can you use a tool like Wireshark in order to sniff the SSL handshake traffic
and share the pncap file with use. Just to see where the handshake fails.
Paolo
Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor
Twitter
Thanks for the clarification Paolo.
Adel,
There are two cases here -
1. if you are using a root CA and intermediate CA - You will have to create a
cert chain file which establishes a chain of trust and set the chain file to
certDb. Here is a good explanation of certificate chain -
Hello Ganesh,
Thank you for your guide.
I followed this guide to have a proper CA with a root and and an intermediate
certificate
(https://jamielinux.com/docs/openssl-certificate-authority/index.html)
I then wanted to do as you proposed in the configuration.
What would be the certDb in my
18 matches
Mail list logo
