On 8/12/25 12:43, Rob Crittenden wrote:
Harry G Coin via FreeIPA-users wrote:
Found a discussion of this here:
https://frasertweedale.github.io/blog-redhat/posts/2019-02-18-freeipa-san-ip.html
Summary: Unless freeipa's DNS is in use, even if the sysadmins know the
IPS to be correct owing to dnssec supported resolvers, freeipa can't
issue certificates with IP's in the SAN. There exists no --force
option for instances where the sysadmins do know the off-host resolvers
are complete and correct. It also appears freeipa won't even allow
freeipa dns to be installed but to use forwarders in this case.
According to the 2019 blog entry, there MUST be dns records in the LDAP
or freeipa can't issue certs with IP's in the SAN.
I think either a --permit-offhost-resolver or --skip-san-ip-check flag
for ipa-cert-request would put appropriate control in the local
sysadmin's hands.
The alternative is either to migrate away from freeipa for certificates,
leaving it only a kerberos/ldap Idm provider, or to create some cron job
that populates freeipa's dns from the authoritative offhost source (a
reverse-double-bind-dyn-ldap??)?? Or hack a custom
ipaserver/plugins/cert.py
If we knew a flag in ipa-cert-request to allow local judgement to
control this situation was in the works, the temporary hack to
ipaserver/plugins/cert.py would be the best approach. The alternatives
are not very attractive.
Has all this been fixed in some newer version? Hopefully?
Thanks
Harry
---
Hi Freeipa Team
Am I correct that only if freeipa's internal DNS is active and current
that freeipa can issue certificates if IP addresses are in the SAN part
of the cert? Even if DNSSec supported resolvers with accurate info are
on the same RFC1918 subnet as freeipa and nslookup / dig report proper
answers?
I hit a wall trying to re-issue a certificate. We had freeipa's DNS
running a few years ago, when the certs were first issued. then migrated
to another resolver with better HA dnssec support.
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'.
Or perhaps a 'force because I actually do know what I'm doing' command
to issue such certificates with IPs in the SAN?
I feel like I'm missing something obvious here, so please help me out.
A certificate means that IPA (the CA) says that this system is to be
trusted. How can IPA make that promise if it doesn't know who owns the
IP, or SAN or whatever?
Any type of force flag will become muscle memory and never be validated
again. Someone will write a blog or post somewhere mentioning --force
and search engines will suggest it forever without people understanding
what they are forcing, and how bad it could be.
That is why IPA is so strict.
If you really need this you could disable the check in IPA, but
remembering to do so on every server after every update would get
tiresome I'd imagine.
rob
Hi Rob
I do appreciate the need to protect the reputation of freeipa re your
muscle memory thought above.
Is it IPA making a promise of the correctness of the IP in the SAN, or
is it the sysadmin who is responsible for the CA using freeipa making
the promise? If IPA had the liability for the decision I think a case
could be made for IPA restricting the sysadmin's judgement. However,
being as it is the sysadmin using freeipa that's responsible, while
having the current method be the default, there should be some option
for the sysadmin to take at least partial responsibility.
Might a reasonable middle ground be a flag which if present only has an
effect with there is no freeipa DNS, and uses dns.resolver.resolve for
SAN IPs, requires dnssec on the query response, and limits acceptance to
RFC1918 & private ipv6 non-routeable addresses. At least my use case
has no need for routable ips in the SAN.
And, while you're at it, you might consider allowing ipa-ca a/aaaa PTR
records coincide with ipa a/aaaa PTR records.
Harry
--
_______________________________________________
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
