Unable to connect to CloudAPI using wildcard certificates

[hww3]

Encountered using hashicorp packer:

The default certs that are provided with triton are wildcards (and probably also self-signed, though the error is about the hostname not matching '*'). triton-go complains and won't connect, which means it's not possible to use this client without generating real certs. A quick look over the code suggests that the client doesn't consult SDC_TESTING... perhaps it could?

[stack72]

Morning @hww3

My most sincere apologies for not getting back to this sooner - I completely missed this. Please can you describe what you are trying to do in a little more detail? I can't quite get from the description what problem you are having

Thanks

Paul

[hww3]

Hi,

At the moment I'm not using triton-go directly, but through Hashicorp packer. I've consulted the packer source, and it's using triton-go.

Basically, when you install an on-prem Triton, you get self-signed wildcard certs on the cloudapi endpoint (among others). The go http client doesn't like that at all, and refuses to connect. It complains about the cert being a wildcard, but I suspect it also doesn't like the self signed certificate. This means it's not possible to use triton-go or anything that uses it against an out-of-the-box Triton install.

Some thinking out loud: It doesn't look like there's a way to override this through the http client via an environment variable or such, so my thinking is triton-go could expose an option that tells the go http client that this is okay, and then packer could expose that as an option (or if triton-go used the SDC_TESTING environment variable, then it wouldn't require a change to packer).

Hopefully this is a little clearer, but do me know if you'd like more background!

[stack72]

Hi @hww3

Ok, that makes more sense, we have this ability in the Terraform provider right now - it is called insecure_skip_tls_verify

I just exposed the same functionality in packer via this PR

hashicorp/packer#6039

When this is merged and released, this will give you a solution to your issue. Of course, you bring up a fantastic point that we don't actually allow you to make triton-go aware of self signed certificates. We have discussed this internally, and this is something that we need to give me thought about. Therefore, even though the packer PR will give you a work around, we need to keep this specific issue open so that we are continually aware of your problem

How does this sound?

Paul

[hww3]

Hi @stack72

I think that's a very acceptable plan... I will especially look forward to a direct solution in triton-go, I'd like to eventually be able to do demos using triton-go on fresh Triton installs where getting "proper" certs isn't warranted.

[jwreagor]

@hww3 There is a solution today but alas it isn't as straight forward of an API as one would hope. All sub-package clients have access to a InsecureSkipTLSVerify from the client in which they wrap. Here's an example...

c, err := compute.NewClient(config)
if err != nil {
    log.Fatalf("compute.NewClient: %s", err)
}

c.Client.InsecureSkipTLSVerify()

Beyond this feature we would hope to add the ability to attach a custom tls.Config to the HTTP client transport that triton-go uses for things like custom root CA paths and client certificates. That doesn't sound like what you're asking today though.