Hi Alexey, Comments inline. There's a lot to break down.
On Mon, Nov 04, 2024 at 10:03:12PM -0000, Alexey Filimonov via FreeIPA-users wrote: > Well, I want to add SAN::UPN (as LDAP's krbPrincipalName), > This is supported already. FreeIPA validations every UPN otherName value in the SAN extension in the CSR against the subject principal's `krbprincipalname` attribute. > SAN::DN (as in LDAP, `fqdn=...,cn=computers,...) > This is not supported, but it is easy to implement. In fact, I made a PR some years ago: https://github.com/freeipa/freeipa/pull/228. But there was no specific request for this behaviour at the time, and it was not accepted. If you want this feature, please file an RFE. > and SAN::UUID (as in LDAP's ipaUniqueID) to issue many > short-living certs for workstations that don't get written to > userCertificates. > Reflecting my response to our discussion on the Dogtag users@ mailing list last month: this is not supported, but... it would be easy to add support for this. You could assert the UUID as a uniformResourceIdentifier SAN value, using the `urn:uuid:<uuid-string>` embedding per https://datatracker.ietf.org/doc/html/rfc9562#section-4. The value would be checked against the subject pricipal's `ipaUniqueId` attribute. If this approach meets your requirements, please file an RFE. > Currently I found that UPN value is provided from host in CSR, and > DN and ipaUniqueID are not provided at all. > What program generates the CSR? Most programs don't provide a convenient way to add DirectoryName and UUID SAN values. But where there is a will, there is a way. > Are those values MUST be provided in CSR generated on host side, > or FreeIPA or DogTag can fill them by themselves? Is it possible > to make DogTag to get those props from LDAP? I found the > `DomainController.cfg` profile which has genericInputImpl which, I > assume stands for some king of "generic input" and > nsTokenUserKeySubjectNameDefaultImpl which has something about > ldap . > Because of the way the Dogtag/IPA integration works, all data must be supplied via the CSR (so FreeIPA cannot modify them). The Dogtag profile copies the SAN extension to the final cert "as is", trusting that FreeIPA has verified the values. From Dogtag's point of view, FreeIPA is a trusted *Registration Authority (RA)*. Re-engineering Dogtag to build the certificate dynamically based on the subject principal's LDAP attributes (or other external data) is technically feasible. But it is a huge investment and I can all but guarantee it won't happen. > > And I didn't find anything related CSR validation in IPA the code, please > point me. > Here is the relevant code: https://github.com/freeipa/freeipa/blob/release-4-12-2/ipaserver/plugins/cert.py#L731-L936 Cheers, Fraser -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
