I am trying to connect Uchiwa to Sensu API via SSL. The Sensu API is behind haproxy which handles SSL termination. Therefore, Uchiwa connects to haproxy via SSL port 8443 which then forwards the connect via non-SSL to port 4567 on the Sensu API.
The Datacenters Configuration in uchiwa.json looks like below:
“sensu”: [
{
“name”: “Sensu”,
“host”: “10.0.3.22”,
“port”: 8443,
“url”: “https://10.0.3.22:8443”,
“path”: “”,
“ssl”: true,
“user”: “admin”,
“pass”: “admin”,
“timeout”: 10
}
]
``
Is there something I need to change in the above configuration to get past this, or something that needs to be handled on the haproxy side?
The logs are usually a good place for any piece of software to get hints for why something may not be working. Have you looked at the uchiwa logs?
Is “url” a valid thing in that config file? The docs don’t reference it:
https://docs.uchiwa.io/getting-started/configuration/
Is the SSL on 8443 signed? If not then you will need insecure: false to make it ignore SSL validation errors.
···
On Fri, Oct 28, 2016 at 7:09 PM, Alex Rodrigues rodrigues.alex@gmail.com wrote:
I am trying to connect Uchiwa to Sensu API via SSL. The Sensu API is behind haproxy which handles SSL termination. Therefore, Uchiwa connects to haproxy via SSL port 8443 which then forwards the connect via non-SSL to port 4567 on the Sensu API.
The Datacenters Configuration in uchiwa.json looks like below:
“sensu”: [
{
“name”: “Sensu”,
“host”: “10.0.3.22”,
“port”: 8443,
“url”: “https://10.0.3.22:8443”,
“path”: “”,
“ssl”: true,
“user”: “admin”,
“pass”: “admin”,
“timeout”: 10
}
]
``
Is there something I need to change in the above configuration to get past this, or something that needs to be handled on the haproxy side?
Thanks for the response Kyle!
url used to be a valid option, but looks like it isn’t any longer and was just ignoring it. I removed it and restarted the uchiwa service and still get the same error. I forgot to paste in the error from the Uchiwa logs in my last post, so here it is:
{“timestamp”:“2016-10-29T03:06:05.502789389Z”,“level”:“warn”,“message”:“GET https://10.0.3.22:8443/stashes returned: Get https://10.0.3.22:8443/stashes: x509: cannot validate certificate for 10.0.3.22 because it doesn’t contain any IP SANs”}
``
An yes, post 8443 is signed
···
On Friday, October 28, 2016 at 10:55:36 PM UTC-4, Kyle Anderson wrote:
The logs are usually a good place for any piece of software to get hints for why something may not be working. Have you looked at the uchiwa logs?
Is “url” a valid thing in that config file? The docs don’t reference it:
https://docs.uchiwa.io/getting-started/configuration/
Is the SSL on 8443 signed? If not then you will need insecure: false to make it ignore SSL validation errors.
On Fri, Oct 28, 2016 at 7:09 PM, Alex Rodrigues rodrigu...@gmail.com wrote:
I am trying to connect Uchiwa to Sensu API via SSL. The Sensu API is behind haproxy which handles SSL termination. Therefore, Uchiwa connects to haproxy via SSL port 8443 which then forwards the connect via non-SSL to port 4567 on the Sensu API.
The Datacenters Configuration in uchiwa.json looks like below:
“sensu”: [
{
“name”: “Sensu”,
“host”: “10.0.3.22”,
“port”: 8443,
“url”: “https://10.0.3.22:8443”,
“path”: “”,
“ssl”: true,
“user”: “admin”,
“pass”: “admin”,
“timeout”: 10
}
]
``
Is there something I need to change in the above configuration to get past this, or something that needs to be handled on the haproxy side?
Well, the error is the smoking gun. The cert may be signed, but for what name?
You can either use the hostname the cert is signed for (and not the ip address) or use the ip directly as you have it configured (and set insecure: true)
···
On Fri, Oct 28, 2016 at 8:07 PM, Alex Rodrigues rodrigues.alex@gmail.com wrote:
Thanks for the response Kyle!
url used to be a valid option, but looks like it isn’t any longer and was just ignoring it. I removed it and restarted the uchiwa service and still get the same error. I forgot to paste in the error from the Uchiwa logs in my last post, so here it is:
{“timestamp”:“2016-10-29T03:06:05.502789389Z”,“level”:“warn”,“message”:“GET https://10.0.3.22:8443/stashes returned: Get https://10.0.3.22:8443/stashes: x509: cannot validate certificate for 10.0.3.22 because it doesn’t contain any IP SANs”}
``
An yes, post 8443 is signed
On Friday, October 28, 2016 at 10:55:36 PM UTC-4, Kyle Anderson wrote:
The logs are usually a good place for any piece of software to get hints for why something may not be working. Have you looked at the uchiwa logs?
Is “url” a valid thing in that config file? The docs don’t reference it:
https://docs.uchiwa.io/getting-started/configuration/
Is the SSL on 8443 signed? If not then you will need insecure: false to make it ignore SSL validation errors.
On Fri, Oct 28, 2016 at 7:09 PM, Alex Rodrigues rodrigu...@gmail.com wrote:
I am trying to connect Uchiwa to Sensu API via SSL. The Sensu API is behind haproxy which handles SSL termination. Therefore, Uchiwa connects to haproxy via SSL port 8443 which then forwards the connect via non-SSL to port 4567 on the Sensu API.
The Datacenters Configuration in uchiwa.json looks like below:
“sensu”: [
{
“name”: “Sensu”,
“host”: “10.0.3.22”,
“port”: 8443,
“url”: “https://10.0.3.22:8443”,
“path”: “”,
“ssl”: true,
“user”: “admin”,
“pass”: “admin”,
“timeout”: 10
}
]
``
Is there something I need to change in the above configuration to get past this, or something that needs to be handled on the haproxy side?
Thanks again … that was it!!
The cert was signed for a hostname and I was using an IP address, so changing to the hostname allowed me to successfully connect Uchiwa to the API using a secure connection.
···
On Saturday, October 29, 2016 at 1:30:01 AM UTC-4, Kyle Anderson wrote:
Well, the error is the smoking gun. The cert may be signed, but for what name?
You can either use the hostname the cert is signed for (and not the ip address) or use the ip directly as you have it configured (and set insecure: true)
On Fri, Oct 28, 2016 at 8:07 PM, Alex Rodrigues rodrigu...@gmail.com wrote:
Thanks for the response Kyle!
url used to be a valid option, but looks like it isn’t any longer and was just ignoring it. I removed it and restarted the uchiwa service and still get the same error. I forgot to paste in the error from the Uchiwa logs in my last post, so here it is:
{“timestamp”:“2016-10-29T03:06:05.502789389Z”,“level”:“warn”,“message”:“GET https://10.0.3.22:8443/stashes returned: Get https://10.0.3.22:8443/stashes: x509: cannot validate certificate for 10.0.3.22 because it doesn’t contain any IP SANs”}
``
An yes, post 8443 is signed
On Friday, October 28, 2016 at 10:55:36 PM UTC-4, Kyle Anderson wrote:
The logs are usually a good place for any piece of software to get hints for why something may not be working. Have you looked at the uchiwa logs?
Is “url” a valid thing in that config file? The docs don’t reference it:
https://docs.uchiwa.io/getting-started/configuration/
Is the SSL on 8443 signed? If not then you will need insecure: false to make it ignore SSL validation errors.
On Fri, Oct 28, 2016 at 7:09 PM, Alex Rodrigues rodrigu...@gmail.com wrote:
I am trying to connect Uchiwa to Sensu API via SSL. The Sensu API is behind haproxy which handles SSL termination. Therefore, Uchiwa connects to haproxy via SSL port 8443 which then forwards the connect via non-SSL to port 4567 on the Sensu API.
The Datacenters Configuration in uchiwa.json looks like below:
“sensu”: [
{
“name”: “Sensu”,
“host”: “10.0.3.22”,
“port”: 8443,
“url”: “https://10.0.3.22:8443”,
“path”: “”,
“ssl”: true,
“user”: “admin”,
“pass”: “admin”,
“timeout”: 10
}
]
``
Is there something I need to change in the above configuration to get past this, or something that needs to be handled on the haproxy side?