Cannot create cert chain: certificate signature failure

[Russ Allbery]

Thanks for the reply!

Greg Hudson <ghudson at mit.edu> writes:
> On 09/05/2015 01:57 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/ANONYMOUS at EYRIE.ORG for krbtgt/EYRIE.ORG at EYRIE.ORG, Cannot create cert chain: certificate signature failure
>>
>> Any idea what's going on?  This appears to be some failure inside OpenSSL,
>> but it looks like absolutely no information about the error is actually
>> logged anywhere?

> We're logging what OpenSSL gives us from X509_verify_cert_error_string()
> after X509_verify_cert() fails.  We could be doing more;
> X509_STORE_CTX_get_error_depth() would give us the depth where the error
> occured in the cert chain and X509_STORE_CTX_get_current_cert() would
> give us the cert that caused the failure.  In this case, I think you
> would merely find out that the error occurred verifying the leaf
> certificate against the CA's public key.

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.

> Looking inside OpenSSL, this error (X509_V_ERR_CERT_SIGNATURE_FAILURE)
> is generated when X509_verify() fails inside internal_verify().  It does
> look like X509_verify() (or rather ASN1_verify()) does something with
> the OpenSSL framework to indicate what kind of error happened, but I am
> not sure how our PKINIT code is supposed to pull that information out.
> The man page for X509_verify_cert() only mentions
> X509_STORE_CTX_get_error().

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.

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).

> It doesn't seem like the client version should have anything to do with
> this failure, so I have no theories as to what changed.

Yeah, it's really weird to me too.  The client in anonymous PKINIT isn't
doing much.

I confirmed that it does work with certs created directly with OpenSSL, so
I'll go down that path and regenerate the CA and certificates for that
realm.

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.

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>