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.
I think it would demonstrate the reality it is the local admins, not
freeipa devs, who are responsible for what use is made of Freeipa.
To manage my deadlines, I've already patched my code here to use
whatever DNS the host uses for IPs in the SAN. If the local admins want
that to be freeipa, then freeipa can accept the responsibility according
to the rationales you've mentioned above (I like the ACME add-on, but
it's not important to my use case).
Motivations:
DNS is long known to be the problem behind most admin's longest trouble
hunts. The SAN provides a way for an site-local long-term critical
subsystem or IOT device to learn the 'correct local IP for the important
thing' having only to check it against a local CA copy. And without
relying on whether DNS is up and running, correct, accessible,
hacked... It's a good middle ground between hard-coding non-routeable
IPs in such as /etc/hosts and hoping DNS isn't having a problem. The
revocation mechanism is critically important for routable IPs, but the
whole point of non-routeable IPs is the local admin is the authority.
Adding some multi-year reality to this: You might look at the history
of freeipa's dnssec, especially in terms of it's long-term stability and
robustness, especially when there's more than one freeipa host. Let a
system go down at any of many 'wrong moments' and it's 'restore from a
backup' if it's the 'master' or 'zap and rebuild the downstream host'
otherwise -- only noticeable when people complain later on.
--
_______________________________________________
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
