On 23/10/2024 12:37, Alexander Bokovoy via FreeIPA-users wrote:
Thank you both for the info--I always appreciate the reassurance that
I'm not doing completely the wrong thing...
I decided to create a more complex certificate mapping rule which
matches on the certificate's Kerberos principal name as well as its
DNS-ID. The advantage of this approach is that it prevents
certificates without a Kerberos principal name from being used for
PKINIT at all, and it also stops a host and the services running on it
from using their certificates to authenticate as each other.
Local organizational policies are exactly for this, indeed!
I've done a bit more experimentation and I've now gone with
`<EKU>pkinit` in the match rule to enforce the requirement that
certificates include id-pkinit-KPClientAuth in their extended key usage
extension.
I created a new certificate profile which issues such a certificate and
it all seems to work fine:
$ diff -u caIPAserviceCert.properties pkinit.properties
--- caIPAserviceCert.properties 2024-10-24 12:02:34.198742955 +0000
+++ pkinit.properties 2024-10-24 15:49:58.658768406 +0000
@@ -89,10 +89,10 @@
policyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl
policyset.serverCertSet.7.default.name=Extended Key Usage Extension
Default
policyset.serverCertSet.7.default.params.exKeyUsageCritical=false
-policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2
+policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.2.3.4
policyset.serverCertSet.8.constraint.class_id=signingAlgConstraintImpl
policyset.serverCertSet.8.constraint.name=No Constraint
policyset.serverCertSet.8.default.class_id=signingAlgDefaultImpl
@@ -109,5 +109,5 @@
policyset.serverCertSet.9.default.params.crlDistPointsPointType_0=URIName
policyset.serverCertSet.9.default.params.crlDistPointsReasons_0=
policyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12
-profileId=caIPAserviceCert
+profileId=pkinit
visible=false
I did some testing by including various EKU extensions in my requests,
and in all cases the server issued a certificate with the EKU taken from
the profile.
I also seem to have run into a bug caused by a mismatch between the
profileId= in my certificate profile filename and the ID given on the
command line when importing the profile.
Unfortunately I'm unable to reproduce it so I'll hold off filing a bug
report until for the time being. But I have some terminal output showing
what happened...
$ ipa certprofile-import pkinit --file=pkinit-host.properties
--desc='PKINIT certificate profile'
Store issued certificates [True]:
ipa: ERROR: Request failed with status 404: Non-2xx response from CA
REST API: 404.
$ ipa certprofile-import pkinit --file=pkinit-host.properties
--desc='PKINIT certificate profile' --store=true
ipa: ERROR: Request failed with status 404: Non-2xx response from CA
REST API: 404.
$ ipa certprofile-import pkinit --file=pkinit-host.properties
--desc='PKINIT certificate profile' --store=true
ipa: ERROR: Request failed with status 409: Non-2xx response from CA
REST API: 409. Unable to create profile: Profile already exists
When I run 'ipa certprofile-find' I only see the default entries plus my
'pkinit' entry. But when I examine the pki database, there are two extra
profiles found, 'pkinit-host2' and 'pkinit-host':
# ldapvi --out -Q -s one -b ou=certificateProfiles,ou=ca,o=ipaca
'(cn=pkinit*)' dn
dn: cn=pkinit-host2,ou=certificateProfiles,ou=ca,o=ipaca
dn: cn=pkinit-host,ou=certificateProfiles,ou=ca,o=ipaca
dn: cn=pkinit,ou=certificateProfiles,ou=ca,o=ipaca
These names came from the profileId= from the file I was trying to import.
I can't find any references to the profile names in
/var/lib/pki/pki-tomcat, so do I need to do any cleanup aside from
removing these LDAP entries?
I'll keep fiddling and I'll file an issue if I'm able to reproduce the bug.
>> There's also some info about the details of the two different ways
to >> add a Kerberos principal name to certificates, and examples of using
OpenSSL to add the `szOID_NT_PRINCIPAL_NAME` type of otherName.
You can use certmonger as well. Add a host where certmonger runs as a
manager to all those hosts to be enrolled and then 'ipa-getcert request'
options can be used to add all particular extensions.
Ah yes, I've got a few certificates that I issued with the -K option and
a longstanding question I had was how to decode the subject alternative
name extension for such certificates. I discovered that 'openssl
asn1parse -dump' can be used to decode the SAN extension data and
actually view the content of the id-pkinit-san otherName. It's a shame
that OpenSSL, GnuTLS and so on are all unable to decode this type of
otherName with the usual, relatively familiar commands...
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
--
_______________________________________________
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
