metadata-support - RE: [Metadata-Support] port numbers in metadata
Subject: InCommon metadata support
List archive
- From: "Cantor, Scott" <>
- To: "" <>
- Subject: RE: [Metadata-Support] port numbers in metadata
- Date: Thu, 7 Jul 2016 15:48:25 +0000
- Accept-language: en-US
- Authentication-results: spf=pass (sender IP is 164.107.81.220) smtp.mailfrom=osu.edu; incommon.org; dkim=none (message not signed) header.d=none;incommon.org; dmarc=bestguesspass action=none header.from=osu.edu;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
> I was actually thinking more about the renegotiation issues. Most of the
> people who were doing front and back channel on port 443 in the UK
> federation ended up migrating away from that configuration (just four
left, I
> think).
Yes, because of the TLS issues. There's no client TLS if you want to use the
front channel, it kicks on message level for you and your web server doesn't
get told to try and get a client cert.
-- Scott
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
- [Metadata-Support] port numbers in metadata, Tom Scavo, 07/07/2016
- Re: [Metadata-Support] port numbers in metadata, Ian Young, 07/07/2016
- RE: [Metadata-Support] port numbers in metadata, Cantor, Scott, 07/07/2016
- Re: [Metadata-Support] port numbers in metadata, Ian Young, 07/07/2016
- RE: [Metadata-Support] port numbers in metadata, Cantor, Scott, 07/07/2016
- Re: [Metadata-Support] port numbers in metadata, Ian Young, 07/07/2016
- RE: [Metadata-Support] port numbers in metadata, Cantor, Scott, 07/07/2016
- Re: [Metadata-Support] port numbers in metadata, Ian Young, 07/07/2016
Archive powered by MHonArc 2.6.19.