Hi,
I can see in the docs that there is http based support for cockpit to interact with HTTP endpoint, which works fine.
Could anyone clarify the approach when the endpoint that the plugin needs to interact with is https instead of http (I'm assuming most REST interfaces will be secure at least over the wire!)?
Any info appreciated.
Thanks,
PC
On 08/10/2018 22:24, Paul Cuzner wrote:> Hi,
I can see in the docs that there is http based support for cockpit to interact with HTTP endpoint, which works fine.
Could anyone clarify the approach when the endpoint that the plugin needs to interact with is https instead of http (I'm assuming most REST interfaces will be secure at least over the wire!)?
Whoops, looks like documentation for the HTTPS part of cockpit.http() is missing. I've opened a pull request to document each option:
https://github.com/cockpit-project/cockpit/pull/10249
The pull request includes an example that looks something like this:
http = cockpit.http({ "address": "localhost", "headers": { "Authorization": "Basic dXNlcjpwYXNzd29yZA==" }, "port": 443, "tls": { "validate": true, "authority": { "file": "/etc/pki/tls/certs/ca-bundle.crt", }, "certificate": { "data": "-----BEGIN CERTIFICATE-----\nMIIDsDCCA..." }, "key": { "data": "-----BEGIN RSA PRIVATE KEY-----\nMIIEogIBA..." } } });
Hope that helps,
Stef
Excellent.
Will this also work with self-signed, or would you simply specify validate false?
Cheers,
PC On Tue, Oct 9, 2018 at 7:38 PM Stef Walter swalter@redhat.com wrote:
On 08/10/2018 22:24, Paul Cuzner wrote:> Hi,
I can see in the docs that there is http based support for cockpit to interact with HTTP endpoint, which works fine.
Could anyone clarify the approach when the endpoint that the plugin needs to interact with is https instead of http (I'm assuming most REST interfaces will be secure at least over the wire!)?
Whoops, looks like documentation for the HTTPS part of cockpit.http() is missing. I've opened a pull request to document each option:
https://github.com/cockpit-project/cockpit/pull/10249
The pull request includes an example that looks something like this:
http = cockpit.http({ "address": "localhost", "headers": { "Authorization": "Basic dXNlcjpwYXNzd29yZA==" }, "port": 443, "tls": { "validate": true, "authority": { "file": "/etc/pki/tls/certs/ca-bundle.crt", }, "certificate": { "data": "-----BEGIN CERTIFICATE-----\nMIIDsDCCA..." }, "key": { "data": "-----BEGIN RSA PRIVATE KEY-----\nMIIEogIBA..." } } });
Hope that helps,
Stef
On 09/10/2018 08:47, Paul Cuzner wrote:
Excellent.
Will this also work with self-signed, or would you simply specify validate false?
The latter. The following for self-signed:
{ "tls": { "validate": false } }
In particular self-signed certificates do not have anything appropriate to put under "authority" in order to make them validate.
Stef
On Tue, Oct 9, 2018 at 7:38 PM Stef Walter swalter@redhat.com wrote:
On 08/10/2018 22:24, Paul Cuzner wrote:> Hi,
I can see in the docs that there is http based support for cockpit to interact with HTTP endpoint, which works fine.
Could anyone clarify the approach when the endpoint that the plugin needs to interact with is https instead of http (I'm assuming most REST interfaces will be secure at least over the wire!)?
Whoops, looks like documentation for the HTTPS part of cockpit.http() is missing. I've opened a pull request to document each option:
https://github.com/cockpit-project/cockpit/pull/10249
The pull request includes an example that looks something like this:
http = cockpit.http({ "address": "localhost", "headers": { "Authorization": "Basic dXNlcjpwYXNzd29yZA==" }, "port": 443, "tls": { "validate": true, "authority": { "file": "/etc/pki/tls/certs/ca-bundle.crt", }, "certificate": { "data": "-----BEGIN CERTIFICATE-----\nMIIDsDCCA..." }, "key": { "data": "-----BEGIN RSA PRIVATE KEY-----\nMIIEogIBA..." } } });
Hope that helps,
Stef
cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahoste...
On Tue, Oct 9, 2018 at 4:56 AM Stef Walter swalter@redhat.com wrote:
On 09/10/2018 08:47, Paul Cuzner wrote:
Excellent.
Will this also work with self-signed, or would you simply specify validate false?
The latter. The following for self-signed:
{ "tls": { "validate": false } }
In particular self-signed certificates do not have anything appropriate to put under "authority" in order to make them validate.
Tangentially related: I'd recommend using a signed certificate rather than a self-signed one, even in testing environments. You'd be surprised how often people get into the habit of doing "validate: false" everywhere and then get into trouble. I wrote a handy little tool a while ago (packaged on Fedora and EPEL) called sscg (the Simple Signed Certificate Generator) that will create a safe certificate for the same use-cases as self-signed, except that it contains a certificate authority you can import in your clients that will validate only this service.
See https://sgallagh.wordpress.com/2016/05/02/self-signed-ssltls-certificates-wh... for details on how it works and http://github.com/sgallagher/sscg for the source.
Thanks Stephen, I'll check it out. On Wed, Oct 10, 2018 at 5:10 AM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Oct 9, 2018 at 4:56 AM Stef Walter swalter@redhat.com wrote:
On 09/10/2018 08:47, Paul Cuzner wrote:
Excellent.
Will this also work with self-signed, or would you simply specify validate false?
The latter. The following for self-signed:
{ "tls": { "validate": false } }
In particular self-signed certificates do not have anything appropriate to put under "authority" in order to make them validate.
Tangentially related: I'd recommend using a signed certificate rather than a self-signed one, even in testing environments. You'd be surprised how often people get into the habit of doing "validate: false" everywhere and then get into trouble. I wrote a handy little tool a while ago (packaged on Fedora and EPEL) called sscg (the Simple Signed Certificate Generator) that will create a safe certificate for the same use-cases as self-signed, except that it contains a certificate authority you can import in your clients that will validate only this service.
See https://sgallagh.wordpress.com/2016/05/02/self-signed-ssltls-certificates-wh... for details on how it works and http://github.com/sgallagher/sscg for the source.
cockpit-devel@lists.fedorahosted.org