[39438] in Kerberos
Re: recent certificate failure for pkinit
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Mon Jul 8 21:30:00 2024
Message-Id: <202407090129.4691TVGd021792@hedwig.cmf.nrl.navy.mil>
To: kerberos@mit.edu
In-Reply-To: <ca4ed132-8911-49ed-95bd-ba24e0f4d47d@taltos.org>
MIME-Version: 1.0
Date: Mon, 08 Jul 2024 21:29:32 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>> KDC:
>> KDC_RETURN_PADATA:WELLKNOWN/ANONYMOUS@EXAMPLE.COM for krbtgt/
>> EXAMPLE.COM@EXAMPLE.COM, Failed to verify own certificate (depth 0): unable
>> to get local issuer certificate
>
>I've run into this error before. MIT's KDC, for some bizarre reason,
>insists that its server cert validate against the same set of CAs used
>to authorize client PKINIT certs. This is insecure and a terrible idea,
>but oh well. So make sure that the KDC server cert validates against the
>set of CAs you've specified in the config file.
The full chain is needed on the KDC side so intermediate certificates
can be sent in the CMS object, and the easiest way to get the full chain
with OpenSSL is to call X509_verify_cert().
However, I disagree with your assertion that this is insecure. In my
experience certificates used by the KDC and clients are all issued by
the same PKI, so there's nothing insecure about trusting the same set
of certificates for both (and in the above example if you are using
anonymous PKINIT you're not using a client certificate anyway).
If I was in the situation where client certificates were issued by a
different PKI than the KDC certificate and I didn't trust the PKI
that was issuing the KDC certificate I would probably write a certauth
plugin to reject client certificates signed by the "wrong" PKI.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
