Mutual TLS configuration from plugin
by Paul Cuzner
Hi,
I have a https (self signed) RESTAPI running in a container on
localhost(uses host networking) that I'm trying to access from my
cockpit plugin. However, despite numerous changes, I can't get it to
work.
Can someone tell me what I'm doing wrong?
I've confirmed that the crt and key files work against the API with curl
curl -i -k --key /etc/ansible-runner-service/certs/client/client.key
--cert /etc/ansible-runner-service/certs/client/client.crt
https://localhost:5001/api/v1/playbooks
HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Thu, 09 May 2019 05:43:05 GMT
Content-Type: application/json
Content-Length: 183
Connection: keep-alive
The client crt and key files start with "----BEGIN CERTIFICATE-----",
and "-----BEGIN RSA PRIVATE KEY-----" respectively - so I believe the
format is OK. they also are readable
[root@rh460p client]# ls -al
total 32
drwxr-xr-x. 2 root root 4096 May 9 16:37 .
drwxr-xr-x. 5 root root 4096 May 9 17:16 ..
-rw-r--r--. 1 root root 1424 May 9 12:39 client.crt
-rw-r--r--. 1 root root 891 May 9 12:39 client.key
(The client key was created with 1024bits)
My plugin has this defined for the http interaction;
const apiPort = 5001;
const apiHost = 'localhost';
const http = cockpit.http({
"address": apiHost,
"port": apiPort,
"tls": {
"certificate": {
"file": "/etc/ansible-runner-service/certs/client/client.crt",
},
"key": {
"file": "/etc/ansible-runner-service/certs/client/client.key",
},
"validate": false // localhost isn't tls validated anyway
}
});
export function checkAPI(svcToken) {
console.log("checking API is there @ " + now());
return http.get("api"); // , null, {Authorization: svcToken});
}
When checkAPI gets called the connection to the API fails. In the
client browser I get
error {"status":400,"reason":"Bad Request","message":"Bad
Request","problem":null}
In nginx's log within the container, I see
[info] 19#0: *72 client sent invalid request while reading client
request line, client: 127.0.0.1, server: , request: "GET api HTTP/1.1"
I get the same result with and without selinux enabled (couldn't see
any denied messages in the audit.log anyway!)
Hopefully this makes some sense...
5 years
