[39608] in Kerberos
Re: ldap tls question
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Thu Apr 16 14:27:46 2026
Message-Id: <202604161827.63GIRXt0011266@hedwig.cmf.nrl.navy.mil>
To: kerberos@mit.edu
In-Reply-To: <5009a24a-25c2-4f32-81d8-495c31d98667@taltos.org>
MIME-Version: 1.0
Date: Thu, 16 Apr 2026 14:27:33 -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
>Using the "usual place" is questionable, as it includes the mass of
>Internet CAs. If you trust them to never issue certs for your LDAP
>server name, fine. I'm less sanguine about the security of random CAs
>(and there have been multiple past incidents of bogus certs being issued).
It's a fair point, but ... what we've found is that if you DON'T put your
private PKI certificates into the OS store, then a whole LOT of stuff
doesn't work (e.g, curl, your favorite package download tool, etc etc),
especially if you are a large organization and use your private PKI for
a lot of services (e.g., the Department of Defense). It just becomes
untenable in practice.
I am aware of rogue certificates being issued, but the CAs that
participate in most OS trusted root programs seem to have coalesced
around a common set of requirements for issuance that seem hard to
defeat without a serious compromise. At least with CT logs you can
see if someone has issued a certificate for your site that you didn't
authorize. It's not perfect but I am not sure what is when it comes
to PKI.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
