Groups | Search | Server Info | Login | Register
Groups > comp.protocols.kerberos > #5340
| From | Ken Hornstein <kenh@cmf.nrl.navy.mil> |
|---|---|
| Newsgroups | comp.protocols.kerberos |
| Subject | Re: recent certificate failure for pkinit |
| Date | 2024-07-08 21:29 -0400 |
| Organization | TNet Consulting |
| Message-ID | <mailman.111.1720488591.2322.kerberos@mit.edu> (permalink) |
| References | <CAOLfK3XsL_QKci34mgeWdpra6Fr3AbDfiMPm+ufd0P2L4-DshA@mail.gmail.com> <ca4ed132-8911-49ed-95bd-ba24e0f4d47d@taltos.org> <202407090129.4691TVGd021792@hedwig.cmf.nrl.navy.mil> |
>> 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
Back to comp.protocols.kerberos | Previous | Next | Find similar
Re: recent certificate failure for pkinit Ken Hornstein <kenh@cmf.nrl.navy.mil> - 2024-07-08 21:29 -0400
csiph-web