Skip to content
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

Closed
wants to merge 7 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@frasertweedale
Copy link
Contributor

frasertweedale commented Apr 23, 2018

Continuation of #1700 by @ipilcher,
adding commits by @ftweedal.

Please keep both PRs open for the time being.

@ipilcher
Copy link
Contributor

ipilcher left a comment

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.)

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented Apr 24, 2018

@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 ValidationError exceptions that get thrown, so that they provide more information.

@frasertweedale frasertweedale added the WIP label Apr 24, 2018

@ipilcher

This comment has been minimized.

Copy link
Contributor

ipilcher commented Apr 24, 2018

The debug log cannot be seen by users, so it is of no use to users. I'll restore the debug message anyway

Fair point. I should have said "administrators."

But we'll also need to rework the ValidationError exceptions that get thrown, so that they provide more information.

Hmm. The message currently includes the IP address that's being rejected. I'm not sure what else you could reasonably include.

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented Apr 27, 2018

@ipilcher I'll push an updated patch next week (hopefully early in the week).

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented May 10, 2018

@ipilcher sorry, been a bit bogged down in other issues. Will get back to this soon, I hope!

@ipilcher

This comment has been minimized.

Copy link
Contributor

ipilcher commented Aug 3, 2018

At this point, would it make sense to just use the "hacky" version in the original PR?

@BongoEADGC6

This comment has been minimized.

Copy link

BongoEADGC6 commented Oct 29, 2018

@frasertweedale This would help for users that want to have signed Kubernetes certificates.

@cjeanneret

This comment has been minimized.

Copy link

cjeanneret commented Feb 1, 2019

Hello! any news on that one? Would be really useful in many cases.... Thanks!

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented Feb 13, 2019

I'm hoping to push this over the line in the next couple of weeks. Thank you all for your patience.

@frasertweedale frasertweedale force-pushed the frasertweedale:feature/1700-san-ipaddress branch from f3540e9 to a674871 Feb 15, 2019

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented Feb 15, 2019

Kicking this off again with a rebase. I'll fix whatever needs fixing, add tests, and then we should be good to go.

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented Feb 15, 2019

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.

@frasertweedale frasertweedale force-pushed the frasertweedale:feature/1700-san-ipaddress branch 2 times, most recently from 8410a6c to c2d563a Feb 18, 2019

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented Feb 19, 2019

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.

@frasertweedale frasertweedale force-pushed the frasertweedale:feature/1700-san-ipaddress branch from c2d563a to 6826a09 Feb 19, 2019

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented Feb 19, 2019

Expanded test suite. Labels updated - this is ready for review now!

@frasertweedale frasertweedale force-pushed the frasertweedale:feature/1700-san-ipaddress branch from 6826a09 to 2c0c3a5 Feb 19, 2019

@flo-renaud flo-renaud self-assigned this Feb 20, 2019

@flo-renaud

This comment has been minimized.

Copy link
Contributor

flo-renaud commented Feb 20, 2019

Hi @frasertweedale
thanks for the PR. So far I have tried (successfully) the following:

  • request a cert for a host with the CSR containing a SAN = host's IP @, IP @ and reverse record in IPA DNS zones
  • request a cert for a host with the CSR containing a SAN = another host's IP @, IP @ and reverse record in IPA DNS zones: properly get an error, but the message is IP Address in SAN does not match any DNS name, it would be more clear with IP Address in SAN does not match the host DNS records.
  • request a cert for a host with the CSR containing a SAN = IP not defined in FreeIPA DNS, error
  • request a cert for a host with the CSR containing a SAN = IP defined in FreeIPA DNS but reverse record missing, error (but the message could be more clear with a hint to reverse DNS record missing).
  • create a kerberos principal alias for the host, add DNS record and reverse record, request a cert for a host with the CSR containing a SAN = IPalias, and DNSalias, success
  • if the DNS record or reverse record for the alias is missing, error as expected
  • if the CSR contains only the IPalias but not the DNS alias, error as expected

I will have a look at the xml tests later, but so far, so good.

@flo-renaud

This comment has been minimized.

Copy link
Contributor

flo-renaud commented Feb 20, 2019

The xml tests are good.

My only concern is that a more specific error message would help troubleshoot in case of failure:

  • IP address in SAN does not match any DNS name
  • IP address in SAN does not match any of the hostnames in SAN
  • reverse IP record missing
Allow issuing certificates with IP addresses in subjectAltName
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

frasertweedale added some commits Apr 23, 2018

cert-request: collect only qualified DNS names for IPAddress validation
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
cert-request: generalise _san_dnsname_ips for arbitrary cname depth
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

@frasertweedale frasertweedale force-pushed the frasertweedale:feature/1700-san-ipaddress branch from 2c0c3a5 to b5bf93d Feb 21, 2019

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented Feb 21, 2019

@flo-renaud thanks for the review. I pushed a new commit that causes different messages to be raised depending on the error:

  • no forward resolution from DNS names to IP address
  • no PTR record for IP address
  • asymmetric PTR and forward records for IP address

@frasertweedale frasertweedale force-pushed the frasertweedale:feature/1700-san-ipaddress branch from b5bf93d to 6753955 Feb 21, 2019

frasertweedale added some commits Feb 21, 2019

cert-request: report all unmatched SAN IP addresses
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
cert-request: more specific errors in IP address validation
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

@frasertweedale frasertweedale force-pushed the frasertweedale:feature/1700-san-ipaddress branch from 6753955 to eb707d5 Feb 21, 2019

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented Feb 21, 2019

Removing backport tags - I'll wait for relevant BZs to get ACKed before backporting this feature.

@flo-renaud

This comment has been minimized.

Copy link
Contributor

flo-renaud commented Feb 21, 2019

Hi @frasertweedale
Thanks for the update, the error messages really help. Works for me, ACK.

@flo-renaud

This comment has been minimized.

Copy link
Contributor

flo-renaud commented Mar 4, 2019

master:

  • dccb2e0 Allow issuing certificates with IP addresses in subjectAltName
  • 8ec4868 cert-request: restrict IPAddress SAN to host/service principals
  • eb70e64 cert-request: collect only qualified DNS names for IPAddress validation
  • 9c750f0 cert-request: generalise _san_dnsname_ips for arbitrary cname depth
  • e37c025 cert-request: report all unmatched SAN IP addresses
  • 474a2e6 Add tests for cert-request IP address SAN support
  • a65c12d cert-request: more specific errors in IP address validation

@flo-renaud flo-renaud added the pushed label Mar 4, 2019

@flo-renaud flo-renaud closed this Mar 4, 2019

@flo-renaud

This comment has been minimized.

Copy link
Contributor

flo-renaud commented Mar 4, 2019

@frasertweedale
A manual backport is required for ipa-4-6 and ipa-4-7 branches, can you handle it? Thanks.

@frasertweedale

This comment has been minimized.

Copy link
Contributor Author

frasertweedale commented Mar 4, 2019

@flo-renaud no worries, it's a simple backport but I intend to wait until relevant BZs have been ACKed. Thanks for merging!

@frasertweedale frasertweedale deleted the frasertweedale:feature/1700-san-ipaddress branch Mar 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.