Fraser Tweedale wrote: > On Mon, Jun 20, 2022 at 07:49:16PM +0000, Charles Hedrick wrote: >> Keeping our own certificates up to date on the various types of >> clients is messy enough that we gave up on that. >> >> The only thing we would actually use it for is kinit -n, to >> bootstrap kinit for OTP. While kinit -n would be the most elegant >> way to do it, we have several other approaches. >> >> Documentation seems to say that if pkinit_eku_checking is set to >> kpServerAuth, we don't need the extension. I've found that kinit >> -n actually does work when the client sets this. However I have to >> install the certificates manually on the KDC, since the command >> won't do it. > > This approach substitutes a certificate distribution requirement > with a config distribution requirement. Every client would have to > accept the certificate with id-kp-serverAuth instead of > id-pkinit-KPKdc** - non-default behaviour which does not conform to > RFC 4556. Some client implementations might not have a workaround. > > This workaround might be acceptable for your environment. In > general, accepting certificates that do not conform to the > requirements of RFC 4556 introduces a substantial risk of FreeIPA > administrators misconfiguring their environment. > > Rob & Michal, perhaps this can be considered as an RFE: to relax > this requirement via a flag, accompanied by ample warnings? > > ** id-pkinit-KPKdc is not required if the krbtgt/REALM principal > name appears in a id-pkinit-san otherName SAN value. But public > CAs will not include that either.
I'm hesitant because of the risks you outline. This appears to have been added to the RFC to support AD 2000/2003 which is legacy at best at this point. The first time an admin hits this problem they're going to disable the check and move right along. It's human nature. rob > > Thanks, > Fraser > >> ________________________________ >> From: Fraser Tweedale <[email protected]> >> Sent: Sunday, June 19, 2022 11:34 PM >> To: Charles Hedrick <[email protected]>; Rob Crittenden via FreeIPA-users >> <[email protected]> >> Cc: Rob Crittenden <[email protected]> >> Subject: Re: [Freeipa-users] Re: ipa-server-certinstall -k >> >> On Wed, Jun 15, 2022 at 04:23:30PM -0400, Rob Crittenden via FreeIPA-users >> wrote: >>> Charles Hedrick via FreeIPA-users wrote: >>>> the error is >>>> >>>> The KDC certificate in cert.pem, privkey.pem is not valid: invalid for a >>>> KDC >>> >>> A PKINIT certificate needs an EKU extension, >>> https://datatracker.ietf.org/doc/html/rfc4556 >>> >>> When generating the key with OpenSSL you need to include "-extensions >>> kdc_cert" >>> >> It's unlikely that publicly trusted CAs will issue certs with >> id-pkinit-KPKdc in EKU. CABForum Baseline Requirements[1] >> 7.1.2.3(f) says: >> >> Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth >> [RFC5280] or both values MUST be present. id-kp-emailProtection >> [RFC5280] MAY be present. Other values SHOULD NOT be present. >> >> [1]: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.4.pdf >> >> Charles, you might need to use a certificate issued directly by the >> IPA CA for your KDC, or else do without PKINIT. >> >> Thanks, >> Fraser >> >>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Charles Hedrick via FreeIPA-users >>>> <[email protected]> >>>> *Sent:* Wednesday, June 15, 2022 3:39 PM >>>> *To:* [email protected] >>>> <[email protected]> >>>> *Cc:* Charles Hedrick <[email protected]> >>>> *Subject:* [Freeipa-users] ipa-server-certinstall -k >>>> >>>> ipa-server-certinstall works fine for http and ldap. But I can't get the >>>> -k option to work. >>>> >>>> I've tried cert.pem and privkey.pem with and without chain.pem, as well >>>> as fullchain.pem and privkey.pem (fullchain has both the cert and the >>>> chain). >>>> >>>> The certs were issued by Internet2, which chains up to addtrust. >>>> >>>> kinit -n works fine if I install the pem files manually, so presumably >>>> my files are valid. >>>> >>>> >>>> _______________________________________________ >>>> 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 on the list, report it: >>>> https://pagure.io/fedora-infrastructure >>>> >>> _______________________________________________ >>> 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 on the list, report it: >>> https://pagure.io/fedora-infrastructure >> > _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
