-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Certificates generated by the cluster signer are missing SANs #341
Comments
For what its worth, I have raised this issue directly to AWS Technical Support as well. |
is there any idea when this will be fixed ? |
Any updates on this? |
This was originally reported in kubernetes/kubernetes#77092 (from April 19) which was supposedly caused by the same as #244. |
EKS is not adding the Subject Alternative Name (SAN) when signing the CSR. This means that we cannot use service name without specifying the namespace and `.svc` suffix. As you can see from the apiserver error message, the TLS certificate validation is checking only the CN. x509: certificate is valid for newrelic-metadata-injection-svc, not newrelic-metadata-injection-svc.default.svc This is a known issue in EKS: awslabs/amazon-eks-ami#341 This changes revert to using {service}.{namespace}.svc for the CN but check the length to be withing the limit of 64 characters defined on the x509 specification.
EKS is not adding the Subject Alternative Name (SAN) when signing the CSR. This means that we cannot use service name without specifying the namespace and `.svc` suffix. As you can see from the apiserver error message, the TLS certificate validation is checking only the CN. x509: certificate is valid for newrelic-metadata-injection-svc, not newrelic-metadata-injection-svc.default.svc This is a known issue in EKS: awslabs/amazon-eks-ami#341 This changes revert to using {service}.{namespace}.svc for the CN but check the length to be withing the limit of 64 characters defined on the x509 specification.
EKS is not adding the Subject Alternative Name (SAN) when signing the CSR. This means that we cannot use service name without specifying the namespace and `.svc` suffix. As you can see from the apiserver error message, the TLS certificate validation is checking only the CN. x509: certificate is valid for newrelic-metadata-injection-svc, not newrelic-metadata-injection-svc.default.svc This is a known issue in EKS: awslabs/amazon-eks-ami#341 This changes revert to using {service}.{namespace}.svc for the CN but check the length to be withing the limit of 64 characters defined on the x509 specification.
EKS is not adding the Subject Alternative Name (SAN) when signing the CSR. This means that we cannot use service name without specifying the namespace and `.svc` suffix. As you can see from the apiserver error message, the TLS certificate validation is checking only the CN. x509: certificate is valid for newrelic-metadata-injection-svc, not newrelic-metadata-injection-svc.default.svc This is a known issue in EKS: awslabs/amazon-eks-ami#341 This changes revert to using {service}.{namespace}.svc for the CN but check the length to be withing the limit of 64 characters defined on the x509 specification.
I have had this issue previously on eks 1.14, and is still an issue after upgrading to 1.15 i raised with aws support they told me to keep watching this ticket for updates |
We are working on this as part of 1.16 support in EKS |
Same issue here. |
This now supported on EKS for Kubernetes 1.16 and above clusters. https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-1.16 |
Great, thanks @mikestef9 for following up. |
I can confirm that EKS 1.16 fixed this issue. |
We're facing an issue that was reported before as part of another issue (#244 (comment)) but since the original issue was about something different which is fixed by now I'm extracting this into a new one.
What happened:
Certificates generated using the cluster signer are missing the request SANs. Just following the example steps from https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/ will show this behavior:
CSR:
Certificate:
What you expected to happen:
I'd expect the generated certificate to include the requested alternative names.
How to reproduce it (as minimally and precisely as possible):
Follow the steps described at https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/
Anything else we need to know?:
Environment:
The text was updated successfully, but these errors were encountered: