[36201] in Kerberos
Re: krb5-1.12.1, pkinit, and openssl ca
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Jun 9 23:55:55 2014
Message-ID: <539681B9.4080804@mit.edu>
Date: Mon, 09 Jun 2014 23:55:37 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: "squidmobile@fastmail.fm" <squidmobile@fastmail.fm>, kerberos@mit.edu
In-Reply-To: <1402266905.5146.126538997.47F9A17E@webmail.messagingengine.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On 06/08/2014 06:35 PM, squidmobile@fastmail.fm wrote:
> KRB5_TRACE=/dev/stdout kinit \
> -X X509_user_identity=DIR:/home/test/.krb5.id my/principal
I think I know why this is. When you created the client certificate,
you presumably set the environment variable CLIENT to "my/principal".
OpenSSL does not recognize the / as a principal component separator, so
it created a principal SAN with one component containing "my/principal",
instead of two components "my" and "principal".
If you look at extensions.kdc, you can see how its [kdc_principals]
section creates two components in its principal SAN. Following the same
pattern, you could create an extensions.client2 which ends with:
[principals]
princ1=GeneralString:${ENV::CLIENT1}
princ2=GeneralString:${ENV::CLIENT2}
and then set CLIENT1 to "my" and CLIENT2 to "principal".
I have filed an issue noting that we should discuss this in the PKINIT
documentation. (Really, we should have better tools for creating and
examining PKINIT X.509 certificates; it's just a matter of resources.)
> i originally made my private key require a password. that seemed
> to make the kinit process fail with a message
Password-protected keys should work via a password prompt from kinit.
(I haven't personally tried this, but it's covered by our automated
tests.) After you have solved the other issues, you might try
reintroducing the password.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
