When kcp start is used with the --external-hostname flag, serving certificates are not signed for that hostname
Describe the bug When kcp start is used with the --external-hostname flag, serving certificates are not signed for that hostname
To Reproduce Steps to reproduce the behavior:
- run
kcp start --external-hostname=<hostname> - verify that
.kcp/admin.kubeconfigis using the external hostname in the server URL - Run
KUBECONFIG=.kcp/admin.kubeconfig kubectl get ns - Get error
Unable to connect to the server: x509: certificate is valid for localhost, not <hostname>
Expected behavior Command should work for specified hostname
Additional context Add any other context about the problem here.
@sttts is there any harm in this, or do we want to direct people to a topology that requires a front proxy that is aligned with a serving cert w/the external hostname?
@csams
Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
@kcp-ci-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.