On 09/05/2015 02:53 AM, Russ Allbery wrote:
>>> Sep 4 22:48:34 mithrandir krb5kdc[12868]: AS_REQ (6 etypes {18 17 16 23 25
>>> 26}) 127.0.0.1: KDC_RETURN_PADATA: WELLKNOWN/anonym...@eyrie.org for
>>> krbtgt/eyrie....@eyrie.org, Cannot create cert chain: certificate signature
>>> failure
> This is anonymous PKINIT, though... I'm not sure what leaf certificate is
> in play. The KDC's itself? So the problem here is that attempting to
> return the chain of the KDC cert and the signing cert is failing? I guess
> I'm confused about what operation is failing.
Your error is occurring in return_padata, which happens after the KDC
has successfully verified the client request and is constructing a
reply. We do verify the KDC's certificate during this step, I believe
in order to construct the certificate chain for the CMS message we're
sending to the client.
> Yeah, sorry, that sounded way more critical than I'd actually intended. I
> know it's really hard to get useful information out of OpenSSL sometimes
> when operations fail.
It looks like we can repeatedly call ERR_get_error() after a failure,
and then ERR_error_string_n() to convert those into trace-log-style
messages from the OpenSSL library. We do that in the new HTTPS proxy
code, but not in PKINIT.
> BTW, is there a way to get the equivalent of KRB5_TRACE out of a KDC? It
> looks like it normally turns this off (or at least I wasn't seeing much
> when running a KDC with that set).
KRB5_TRACE functions for a KDC like it does for anything else, but there
aren't very many tracing points there, except when the KDC calls a
libkrb5 function. And of course, for any trace points we might consider
adding to the KDC, we'd have to think about whether they make more sense
as just KDC log messages.
I am wondering if we should add something similar to
src/plugins/tls/k5tls/openssl.c:flush_errors() to PKINIT, dumping the
OpenSSL error queue into the trace log. The messages generated by
ERR_error_string_n() appear to be developer-centric, containing function
names and line numbers, which makes them feel more appropriate for trace
logs, and it's also a little hard to do regular KDC logging from the
PKINIT module; invoking com_err() works for a kdcpreauth module, but in
this case the failure happens inside code shared between the kdcpreauth
and clpreauth modules, and we wouldn't want to invoke com_err() from the
clpreauth module. Ideally we would just get more informative messages
from X509_verify_cert_error_string() and similar, and I guess OpenSSL
might get to that point eventually, but it's not there now.
> BTW, a slightly different question: what's the correct way to detect, in a
> GSS-API application, that the client has authenticated anonymously? I see
> that GSS_C_NT_ANONYMOUS exists (the project wiki mentions it without the
> _C), but I'm not entirely sure how to use it. It looks like the naive
> approach of calling gss_display_name returns the string version of the
> anonymous principal, so I could do a krb5_parse_name and then do a
> krb5_principal_compare, but that feels inelegant and like a layering
> violation.
Looking at the code, GSS_C_NT_ANONYMOUS should appear in the
output_name_type return parameter of gss_display_name() if the client
authenticated anonymously.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
