Re: krbdev Digest, Vol 169, Issue 7

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: krbdev Digest, Vol 169, Issue 7

andre@academ.org
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
[hidden email] wrote:

> Send krbdev mailing list submissions to
> [hidden email]
>
> 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
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> 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 <[hidden email]>
> Subject: Implicit REALM/DNS Mapping
> To: krbdev <[hidden email]>
> Message-ID:
> <[hidden email]>
> 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 <[hidden email]>
> Subject: NSS PKINIT requires nsCertType extension?
> To: [hidden email]
> Message-ID:
> <CAAeFVfxrTwp6rKW3c2=HZH6ga+0=[hidden email]>
> 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
> [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
> End of krbdev Digest, Vol 169, Issue 7
> **************************************


--
Andrey Volodin <[hidden email]>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Loading...