-
Notifications
You must be signed in to change notification settings - Fork 27
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
added both LB IP and hostname to sans #391
base: main
Are you sure you want to change the base?
Conversation
@sed-i I'm going to need you to double-check this, and help clarify that this isn't breaking anything important. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would generally discourage from using IP addresses in your certificates, especially in Kubernetes because:
- IP addresses change, you will need to make sure that when your pod reschedules and you get a new IP address, you also ask for a new certificate
- Let's Encrypt does not generate certificates for IP addresses and would reject such a request with an error like
acme: error: 400 :: POST :: https://acme-staging-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:unsupportedIdentifier :: NewOrder request included invalid non-DNS type identifier: type "ip", value "1.2.3.4"
Plus if you want to use IP addresses, you should likely use the sans_ip
field instead of sans_dns
.
OK. How do we test TLS when doing development locally?
The conversion is done in CertHandler. |
I think setting a sans_ip when Apart from being a valid use case (cf. 1.1.1.1), it makes testing much simpler, as we won't need to update the CI machine's |
|
||
# If all else fails, we'd rather use the bare IP | ||
return [target] if target else [] | ||
return targets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a couple of test cases? I'm thinking:
- When external_hostname is set, then the CSR should be for the external hostname.
- When external_hostname is unset, then the CSR should be for the loadbalancer IP.
For local development, I think sans_ip's are fine. You would likely need to be careful in how users can impact what ends up in their certificate.s |
Issue
the current logic in
server_cert_sans_dns
returns the external host provided by metallb if it is a hostname, else, if it's an IP, returns the "true hostname" returned bysocket.gethostbyaddr(IP)
.On certain environments (such as my local development one) that means that ``server_cert_sans_dns` returns the name of my computer, and none of the cos-lite components will be able to use TLS over traefik because traefik's IP address has nothing to do with my computer's name.
Solution
Solution is adding the true hostname to the SANS instead of replacing the IP with it.
Traefik will get a cert valid for both the IP and the hostname.