[krbdev.mit.edu #7122] krb5 1.10.1 PKINIT assumes server certificate has a Subject Alternative Name X.509v3 Extension

[Tom Yu via RT]

"Roy Keene via RT" <rt-comment at krbdev.mit.edu> writes:

> crypto_retrieve_X509_sans: looking for SANs in cert = /CN=EIS-DC1ITL.eis.ds.usace.army.mil
> verify_kdc_san: Checking pkinit sans
> verify_kdc_san: no pkinit san match found
> verify_kdc_san: no certhosts (or we wouldn't accept them anyway)
> verify_kdc_san: returning retval -1765328308, valid_san 0, need_eku_checking 1
> pkinit_as_rep_parse returning -1765328308 (KDC name mismatch)
> pkinit_as_rep_parse returned -1765328308 (KDC name mismatch)
> pkinit_client_process: returning -1765328308 (KDC name mismatch)
> ...
>
> My krb5.conf contains:
> [libdefaults]
>  	default_realm = EIS.DS.USACE.ARMY.MIL
>  	pkinit_kdc_hostname = EIS-DC1ITL.eis.ds.usace.army.mil
>  	...
>
> [realms]
>  	EIS.DS.USACE.ARMY.MIL = {
>  		kdc = eis-dc1itl.eis.ds.usace.army.mil
>  		default_domain = eis.ds.usace.army.mil
>  		admin_server = eis-dc1itl.eis.ds.usace.army.mil
>  	}
>
> Given this it should be entirely possible to verify that my KDC is who I 
> expect it to be as I have explicitly specified it and the certificate 
> chain has been validated.  This would comply with section 3.2.4 of RFC 
> 4556.
>
> I would like for PKINIT to succeed under these circumstances.

Your certificate doesn't appear to have any SubjectAltName extensions.
I'm fairly sure that our implementation only checks
pkinit_kdc_hostname against the dnsName SubjectAltName extensions,
which explains the "no certhosts" debugging message.  (The "certhosts"
comparison is also case-sensitive, but that could be a different issue
that this situation doesn't allow to become relevant.)

I think it also does not check against the CommonName part of the
Subject.  It's not completely clear to me from RFC 4556 whether
matching pkinit_kdc_hostname against the CommonName of the KDC
certificate is appropriate.  We will consider changing the existing
behavior, but I would first like to confirm that checking the
CommonName in this situation does not cause any additional
vulnerabilities.

Is this certificate one that you created for the purposes of using
PKINIT, or did you create it for some other purpose first?  What
method did you use to create this certificate?

Thanks.