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
Allow issuing certificates with IP addresses in subjectAltName (ftweedal) #1843
Allow issuing certificates with IP addresses in subjectAltName (ftweedal) #1843
Conversation
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.
CNAME chains are a valid use case in some cases (geographic load balancing, content delivery networks, etc.), so there might be a future benefit to supporting them. If you're going to do that, though, don't you need a mechanism to detect loops?
Also, I think that the debug message is fairly important. The logic of which IPs are considered acceptable is likely to be opaque so some users, so I think it's important that a mechanism exists for them to discover why an IP address was rejected. (I also think that debug messages like this tend to make code easier to understand - almost like quasi-comments.)
@ipilcher thanks for your comments. There is no CNAME loop detection, but there is a maximum depth which for practical purposes is sufficient, IMO. The debug log cannot be seen by users, so it is of no use to users. I'll restore the debug message anyway. But we'll also need to rework the |
Fair point. I should have said "administrators."
Hmm. The message currently includes the IP address that's being rejected. I'm not sure what else you could reasonably include. |
@ipilcher I'll push an updated patch next week (hopefully early in the week). |
@ipilcher sorry, been a bit bogged down in other issues. Will get back to this soon, I hope! |
At this point, would it make sense to just use the "hacky" version in the original PR? |
@frasertweedale This would help for users that want to have signed Kubernetes certificates. |
Hello! any news on that one? Would be really useful in many cases.... Thanks! |
I'm hoping to push this over the line in the next couple of weeks. Thank you all for your patience. |
f3540e9
to
a674871
Compare
Kicking this off again with a rebase. I'll fix whatever needs fixing, add tests, and then we should be good to go. |
Couple of minor tweaks to come, as well as tests. And a blog post to demo and plug the shiny new feature. Should knock this off next week @ipilcher. |
8410a6c
to
c2d563a
Compare
Some tests are added. There are more to write but I want to get some early feedback from a "big" CI run, while I continue expanding the tests for this feature. |
c2d563a
to
6826a09
Compare
Expanded test suite. Labels updated - this is ready for review now! |
6826a09
to
2c0c3a5
Compare
Hi @frasertweedale
I will have a look at the xml tests later, but so far, so good. |
The xml tests are good. My only concern is that a more specific error message would help troubleshoot in case of failure:
|
Allow issuing certificates with IP addresses in the subject alternative name (SAN), if all of the following are true. * One of the DNS names in the SAN resolves to the IP address (possibly through a CNAME). * All of the DNS entries in the resolution chain are managed by this IPA instance. * The IP address has a (correct) reverse DNS entry that is managed by this IPA instance https://pagure.io/freeipa/issue/7451
Collect only qualified DNS names for IPAddress validation. This is necessary because it is undecidable whether the name 'ninja' refers to 'ninja.my.domain.' or 'ninja.' (assuming both exist). Remember that even a TLD can have A records. Now that we are only checking qualified names for the purpose of IPAddressName validation, remove the name length hack from _san_dnsname_ips(). Part of: https://pagure.io/freeipa/issue/7451
Generalise _san_dnsname_ips to allow arbitrary cname depths. This also clarifies the code and avoids boolean blindness. Update the call site to maintain the existing behvaiour (one cname allowed). Part of: https://pagure.io/freeipa/issue/7451
2c0c3a5
to
b5bf93d
Compare
@flo-renaud thanks for the review. I pushed a new commit that causes different messages to be raised depending on the error:
|
b5bf93d
to
6753955
Compare
During SAN validation, it is possible that more than one iPAddressName does not match a known IP address for the DNS names in the SAN. But only one unmatched IP address is reported. Update the error message to mention all unmatched iPAddressName values. Part of: https://pagure.io/freeipa/issue/7451
Update the IP address validation to raise different error messages for: - inability to reach IP address from a DNS name - missing PTR records for IP address - asymmetric PTR / forward records If multiple scenarios apply, indicate the first error (from list above). The code should now be a bit easier to follow. We first build dicts of forward and reverse DNS relationships, keyed by IP address. Then we check that entries for each iPAddressName are present in both dicts. Finally we check for PTR-A/AAAA symmetry. Update the tests to check that raised ValidationErrors indicate the expected error. Part of: https://pagure.io/freeipa/issue/7451
6753955
to
eb707d5
Compare
Removing backport tags - I'll wait for relevant BZs to get ACKed before backporting this feature. |
Hi @frasertweedale |
master:
|
@frasertweedale |
@flo-renaud no worries, it's a simple backport but I intend to wait until relevant BZs have been ACKed. Thanks for merging! |
Continuation of #1700 by @ipilcher,
adding commits by @ftweedal.
Please keep both PRs open for the time being.