On Tue, Aug 26, 2025 at 09:15:27AM -0500, Harry G Coin wrote: > > On 8/26/25 00:54, Fraser Tweedale wrote: > > On Tue, Aug 26, 2025 at 03:40:47PM +1000, Fraser Tweedale wrote: > > > Hi Harry, > > > > > > Here are the rules for validation of iPAddressName values in the SAN > > > extension: > > > > > > 1. Each iPAddressName value must be the result of resolving at least > > > one of the dNSName values. > > > > > > 2. Each iPAddressName value must have a PTR record that returns a > > > name that resolves back to that IP address. > > > > > > 3. Only the IPA DNS records are consulted, because only data in the > > > IPA database is trusted for CSR validation. > > > > > > > Would freeipa be able to issue IPs in certificates if I enabled > > > > freeipa's > > > > dns system but pointed it off-host for all resolutions? Or is it > > > > required > > > > the DNS records be in local LDAP 'no matter what'. > > > Yes, that is required. There is no "force" option. Trusting > > > external DNSSec is something that could be considered, but we are > > > unlikely to implement this unless there is a compelling driver. > > > > > > Feel free to file an RFE, especially if you or your organisation may > > > be able to help deliver it. (These are not empty words - the > > > current SAN IP support was also a community contribution). > > I should mention one more thing: there is a ticket to add support > > for the IP identifier type to the Dogtag ACME server: > > https://issues.redhat.com/browse/IDM-2313. If ACME could work for > > your use case feel free to add a comment to that ticket. > > > > Cheers, > > Fraser > > Hi Fraser > > Thanks for the focus here. > > Consider whether it is in keeping with the intent of the RFC's to, with a > flag making the request, allow certificates with IP addresses in the SAN for > non-routable IPs to confirm via whatever DNS is configured in the host. In > the alternative, a flag to check against /etc/hosts before failing SAN IPs > not in DNS.
It's a policy question more than an RFC conformance question. FreeIPA CSR validation policy is quite strict, by design. We would welcome a detailed and proposal to relax or extend the validation rules. But we must consider not only the legitimacy of the use case but also how widespread it is, the implementation complexity, resourcing the work, and how easy it will be to support users. I encourage you to create an RFE ticket, provide as much detail as possible there, and let's continue the discussion there. A further note/clarification: the FreeIPA cert-request command command validates all names/IPs/etc in the CSR against a nominated subject principal (host/service/user). Any validation heuristic for IP address SAN values must verify a strong association between the IP address(es) and the subject principal. Any proposal that does not do that would probably be a non-starter. Cheers, Fraser -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
