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