New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tsh 14.0 from macOS Sonoma cannot connect with certificate issues #32531
Comments
Which version of |
I'm experiencing the same issue: Version Informationtsh version
edit: this is the Debug Outputtsh -d ls
Downgrading to tsh v13 works around the issue for now. |
Side note: the key error message seems to be
but I don't know which standards this refers to. (Is tsh v14 FIPS by default or something?) |
No, this message comes from macOS if it doesn't like a certificate. Still looking in to what certificate it doesn't like and why. |
I had another think of my certificates but it might be good to also note that the clusters are all running CentOS 7 with a letsencrypt certificate in front that is not issued through teleport but separately and served by nginx. |
I had problem with tsh Login was ok ,but when I tried
When I downgraded |
So tsh v13 would first attempt to connect with the new gRPC API that's supported in teleport 14, and would fall back to the old SSH connection method if the gRPC one failed. In tsh v14 the fallback was eliminated. I suspect this certificate issue has also been present on tsh v13 for you and it went unnoticed due to the fallback behavior. (We could confirm this with a trace) I'm not sure that the Sonoma upgrade has anything to do with this, and it might just be coincidence that the macOS update happened around the same time teleport was upgraded to v14. @vietvudanh's experience on Monterey seems to back this up. |
I may have narrowed down the issue a little. My company's setup uses a Load Balancer (w/TLS termination) for the initial connection, but Teleport also generates a self-signed cert internally. It looks like the self-signed cert is what's failing the MacOS CT Policy (at least according to this tool). Excerpt from ...
proxy_service:
enabled: yes
listen_addr: 0.0.0.0:3023
ssh_public_addr: tp-alpha-trunk.verygoodsecurity.io:3023
tunnel_listen_addr: 0.0.0.0:3080
tunnel_public_addr: tp-alpha-trunk.verygoodsecurity.io:3080
web_listen_addr: 0.0.0.0:3080
public_addr: tp-alpha.verygoodsecurity.io:443 Where Interestingly, setting The cert in question is the auto-generated |
Thanks @coltonparsons-vgs - that was just enough to help me identify the issue. Fix is on the way. |
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
As per https://support.apple.com/en-in/HT210176: > TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID. We were not specifying this EKU. Validated by checking with the old self-signed certs: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem Cert Verify Result: Invalid Extended Key Usage for policy And then repeating the process after this change: $ security verify-cert -c webproxy_cert.pem -p ssl -r webproxy_cert.pem ...certificate verification successful. Closes #32531
Curious, any word on when this will be released? |
I have the same issue. Only downgrading to teleport 13.x solved it for me. |
This should be in 14.0.3 which will be released this week. |
I just downloaded tsh 14.0.3 and tested it, I'm still getting this error on macOS Ventura 13.6:
Like the person earlier in this thread, we use a load balancer with TLS termination. |
I can confirm I'm having the same issue as keenan-v1 (tsh 14.0.3 on MacOS Ventura 13.6). I'll see if I can get a Sonoma box going to test it there. edit: issue persists after updating the Teleport servers to 14.0.3 and regenerating |
Can't reopen it, but after updating the proxy host and my local tsh install to 14.0.3 and restarting teleport on the proxy host I now get it on |
Could someone having this issue share the full output of their |
Replaced the target host with ~ $ tsh ssh --debug --cluster m2mobi host1.m2mobi.com
2023-10-12T13:59:02+02:00 INFO [CLIENT] ALPN connection upgrade required for "bastion.m2mobi.com:443": true. client/api.go:723
2023-10-12T13:59:02+02:00 DEBU [CLIENT] Skipping connection to the local ssh-agent. client/keyagent.go:137
2023-10-12T13:59:02+02:00 DEBU [KEYSTORE] Reading certificates from path "/Users/sean.molenaar/.tsh/keys/bastion.m2mobi.com/sean-ssh/m2mobi-cert.pub". client/keystore.go:355
2023-10-12T13:59:02+02:00 DEBU [KEYSTORE] Teleport TLS certificate valid until "2023-10-12 18:43:42 +0000 UTC". client/client_store.go:106
2023-10-12T13:59:02+02:00 INFO [KEYAGENT] Loading SSH key for user "sean" and cluster "m2mobi". client/keyagent.go:196
2023-10-12T13:59:02+02:00 DEBU [KEYSTORE] Teleport TLS certificate valid until "2023-10-12 18:43:42 +0000 UTC". client/client_store.go:106
2023-10-12T13:59:02+02:00 DEBU [KEYSTORE] Teleport TLS certificate valid until "2023-10-12 18:43:42 +0000 UTC". client/client_store.go:106
2023-10-12T13:59:02+02:00 DEBU [KEYSTORE] Teleport TLS certificate valid until "2023-10-12 18:43:42 +0000 UTC". client/client_store.go:106
2023-10-12T13:59:02+02:00 DEBU [KEYSTORE] Teleport TLS certificate valid until "2023-10-12 18:43:42 +0000 UTC". client/client_store.go:106
2023-10-12T13:59:02+02:00 DEBU ALPN connection upgrade for bastion.m2mobi.com:3023. client/alpn_conn_upgrade.go:187
2023-10-12T13:59:02+02:00 DEBU [KEYSTORE] Reading certificates from path "/Users/sean.molenaar/.tsh/keys/bastion.m2mobi.com/sean-ssh/m2mobi-cert.pub". client/keystore.go:355
2023-10-12T13:59:02+02:00 DEBU [KEYSTORE] Teleport TLS certificate valid until "2023-10-12 18:43:42 +0000 UTC". client/client_store.go:106
2023-10-12T13:59:02+02:00 DEBU [CLIENT] Attempting to issue a single-use user certificate with an MFA check. client/cluster_client.go:135
ERROR REPORT:
Original Error: transport.ConnectionError connection error: desc = "transport: Error while dialing: failed to dial: unable to establish proxy stream\n\trpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: tls: failed to verify certificate: x509: “7b5563ef-4099-494e-b21f-29476f71046f.m2mobi” certificate is not standards compliant\""
Stack Trace:
github.com/gravitational/teleport/api@v0.0.0/client/client.go:1630 github.com/gravitational/teleport/api/client.(*Client).GenerateUserSingleUseCerts
github.com/gravitational/teleport/lib/client/cluster_client.go:271 github.com/gravitational/teleport/lib/client.(*ClusterClient).performMFACeremony
github.com/gravitational/teleport/lib/client/cluster_client.go:136 github.com/gravitational/teleport/lib/client.(*ClusterClient).SessionSSHConfig
github.com/gravitational/teleport/lib/client/api.go:1738 github.com/gravitational/teleport/lib/client.(*TeleportClient).connectToNodeWithMFA
github.com/gravitational/teleport/lib/client/api.go:1619 github.com/gravitational/teleport/lib/client.(*TeleportClient).ConnectToNode.func2
runtime/asm_arm64.s:1197 runtime.goexit
User Message: connection error: desc = "transport: Error while dialing: failed to dial: unable to establish proxy stream\n\trpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: tls: failed to verify certificate: x509: “7b5563ef-4099-494e-b21f-29476f71046f.m2mobi” certificate is not standards compliant\"" |
@greedy52 Do you think this could be related to connection upgrades somehow? |
Notice the port is different. Same thing here.
So I am assuming TLS routing is not enabled. Connection upgrade should NOT be applied to 3023. I am setting up this (separate port env with webport behind ALB), will update this comment with my findings. -- update
I can confirm that |
Just popping back to say everything is working now. Thank you! |
I just tried, same for me. Thanks everyone! |
I can confirm as well, tsh |
Thank team, working well with tsh |
Expected behavior:
tsh ssh --cluster cluster-x server-y
will start an SSH session on a serverCurrent behavior:
After login in and authenticating with touchID
Bug details:
tsh ssh
from the latest macOS version.The text was updated successfully, but these errors were encountered: