Support for self-signed certificates

[LauKr]

Is your feature request related to a problem? Please describe.
To my understanding the project doesn't support self-signed certificates.
The only support for TLS on the node side I know of is insecure = false, i.e. verifying the certificate against the normal root chains, or insecure = true, i.e. not verifying the certificate at all. Furthermore, I found no documentation on that matter and all examples just use insecure = true.

Describe the solution you'd like
Ideally, when setting up the provider, on the same level as insecure another optional argument should exist which takes either a path to a certificate or the certificate itself. The corresponding certificate should be used to verify the node's identity.

Describe alternatives you've considered
Only providing the SHA256sum of the certificate might be enough, however, I'm not sure if the TLS library can handle that input.

Additional context

The relevant place in the code:

terraform-provider-proxmox/proxmox/api/client.go

Lines 87 to 94 in 9d166b9

	var transport http.RoundTripper = &http.Transport{
	Proxy: http.ProxyFromEnvironment,
	TLSClientConfig: &tls.Config{
	// deepcode ignore InsecureTLSConfig: the min TLS version is configurable
	MinVersion: version,
	InsecureSkipVerify: insecure, //nolint:gosec
	},
	}

To my understanding, this only sets true or false according to the value given here:

terraform-provider-proxmox/proxmoxtf/provider/provider.go

Line 100 in 9d166b9

conn, err = api.NewConnection(endpoint, insecure, minTLS)

I think it's important to be able to use TLS, especially outside of purely testing environments.
As a default Proxmox install comes with a self-signed certificate, this should, in my opinion, be the first point to start.
Especially, as not everyone set's up a proper certificate chain with an approved root certificate.

[bpg]

Hey @LauKr 👋🏼

Ideally, when setting up the provider, on the same level as insecure, another optional argument should exist which takes either a path to a certificate or the certificate itself. The corresponding certificate should be used to verify the node's identity.

Thanks for your suggestion! While I understand the convenience of directly specifying a certificate, the more robust approach would be to add the self-signed root CA to the host's certificate store and mark it as trusted.

In case of PVE, you'd need to add pve-root-ca.pem:

By doing so, all existing TLS mechanisms can operate seamlessly without requiring additional configuration or custom code changes in the provider. This approach aligns with standard practices for managing self-signed certificates and ensures better maintainability and security.

Let me know your thoughts or if you'd like further clarification!