master: teleport --insecure doesn't actually skip cert verification on startup

[mumoshu]

What happened:

I'm unable to make teleport --insecure as expected according to its own log message.

That is, teleport --insecure fails like https://gist.github.com/mumoshu/2e345a8106704301394354155cff27d2 even though I do have the --insecure flag passed to teleport:

spec:
    containers:
    - args:
      - --insecure
      image: quay.io/gravitational/teleport-ent:2.7.0-alpha.3

Notice the part of the message that made me thing this should work:

If you know the certificate is self-signed and would like to ignore this
error use the --insecure flag.

What you expected to happen:

teleport --insecure doesn't fail to start when the proxy_service.https_cert_file is self-signed.

How to reproduce it (as minimally and precisely as possible):

Use the helm chart proposed in #2014 and install teleport by running cd example/charts/teleport; helm upgrade --install teleport ./

Environment:

• Teleport version (use teleport version): 2.7.0-alpha.3
• Tsh version (use tsh version): 2.7.0-alpha.3 (built from the HEAD of Idiomatic helm chart for Teleport #2014)
• OS (e.g. from /etc/os-release): macOS High Sierra
• kubectl: v1.10.5
• Kubernetes: v1.10.0 on minikube v0.28.0

Browser environment

• Browser Version (for UI-related issues):
• Install tools:
• Others:

Relevant Debug Logs If Applicable

• tsh --debug
• teleport --debug

[kontsevoy]

@mumoshu that "insecure" flag is not for tsh clients. This flag is used for connecting two clusters together, i.e. when one teleport daemon is connecting to another teleport daemon.

@klizhentas can confirm. If true, I propose we close this (and update the docs).

[mumoshu]

＠kontsevoy Good to know! Thanks. But anyway you can reproduce this without tsh at all, as there's no tsh involved in the reproduction steps.

[kontsevoy]

hm... that's not right. we'll take a look. thanks.

[mumoshu]

As far as I remember, it's just that I added --insecure because teleport told me to do so. teleport didn't work even though I've added --insecure as told, hence I created this issue. Now, this is marked as a documentation issue, which seems to imply that the behavior is intended, right?
Then I'm fine closing this :)

[nmcc1212]

i still have this issue and there seems to be no way to solve it