krbdev Digest, Vol 169, Issue 7

Andrey Volodin andre at academ.org
Tue Jan 31 20:02:49 EST 2017


It seems that we have had a more or less fine connection with few interrupth though.
On Tue, 31 Jan 2017 12:00:31 -0500
krbdev-request at mit.edu wrote:

> Send krbdev mailing list submissions to
> 	krbdev at mit.edu
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://mailman.mit.edu/mailman/listinfo/krbdev
> or, via email, send a message with subject or body 'help' to
> 	krbdev-request at mit.edu
> 
> You can reach the person managing the list at
> 	krbdev-owner at mit.edu
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of krbdev digest..."
> 
> 
> Today's Topics:
> 
>    1. Implicit REALM/DNS Mapping (Nathaniel McCallum)
>    2. NSS PKINIT requires nsCertType extension? (Matt Rogers)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 31 Jan 2017 11:36:29 +0100
> From: Nathaniel McCallum <npmccallum at redhat.com>
> Subject: Implicit REALM/DNS Mapping
> To: krbdev <krbdev at mit.edu>
> Message-ID:
> 	<CAOASepOm1EaGqH3SxX7guReb+bkdgxjK9yz_7LXK8PEWWtGrfw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Currently, GSSAPI will select a non-default ccache if a realm/domain
> mapping exists in krb5.conf. However, this doesn't work if the KDC was
> found via discovery. Does MIT have any thoughts about implying an
> implicit mapping in this case?
> 
> Nathaniel
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 31 Jan 2017 10:09:57 -0500
> From: Matt Rogers <mrogers at redhat.com>
> Subject: NSS PKINIT requires nsCertType extension?
> To: krbdev at mit.edu
> Message-ID:
> 	<CAAeFVfxrTwp6rKW3c2=HZH6ga+0=fnzmYAjQ0Gvp-j9YgCU97g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> When building with --with-pkinit-crypto-impl=nss and running the test
> suite, I found that PKINIT related tests fail on certificate
> verification (either client or KDC certificate depending on the test)
> with SEC_ERROR_INADEQUATE_CERT_TYPE : "Certificate type not approved
> for application." It turns out NSS is expecting the Netscape
> certificate type extension (nsCertType = client/server in
> openssl.cnf), and adding it to the test certificates made the tests
> pass. Is this expected, or documented anywhere? I've not seen
> nsCertType required for SSLClient and SSLServer usage profiles before,
> so I'm not sure why it is expected here. My version of NSS is 3.27 by
> the way.
> 
> Regards,
> Matt
> 
> 
> ------------------------------
> 
> _______________________________________________
> krbdev mailing list
> krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 
> End of krbdev Digest, Vol 169, Issue 7
> **************************************


-- 
Andrey Volodin <andre at academ.org>


More information about the krbdev mailing list