[ietf78-tech] Fwd: Certificates for the IETF

[Jim Martin]

John,
	Ok, go ahead and make the second request to Russ, CCing me. Thanks for taking the time to double check.

	- Jim

On Jul 14, 2010, at 1:43 PM, John Kemp wrote:

> 
> Looked at this a bit more, and I would say that I'm
> more convinced we should get the 2nd certificate.  Since
> we also rely on "REMOTE_ADDR" from the client, we don't
> really have the option of using DNAT instead of REDIRECT,
> since that would alter that value in flight.
> 
> IP for the webpage has to be on the VLAN of the client.
> Name for that IP has to resolve to match the certificate.
> IP for that Name has to work when the client fetches it.
> 
> So I think we're stuck.  Sorry for the late notification
> on this.  Anytime you have multi-bridge configurations,
> you get this kind of fun stuff... ;-/
> 
> /jgk
> 
> 
> On 07/14/2010 12:07 PM, John Kemp wrote:
>> 
>> Just an educated guess... I'm going by what I read in the
>> iptables manpage for REDIRECT, and by the fact that we will
>> have more than one bridge interface, each having a different
>> IP address.  Seems like we are stuck with having to target
>> the IP on the bridge interface.  Which ties to SSL, which
>> ties to NAME... :(
>> 
>> /jgk
>> 
>> 
>> On 07/14/2010 11:53 AM, Jim Martin wrote:
>>> Folks,
>>>   Could you guys sanity check this for John and I? I can't imagine you
>>> would really need a separate cert per van. John, no offense intended,
>>> but I want to be really sure before I go back to Russ for yet something
>>> else. 
>>> 
>>> -Jim
>>> 
>>> Sent from my iPhone
>>> 
>>> Begin forwarded message:
>>> 
>>>> *From:* John Kemp <kemp at network-services.uoregon.edu
>>>> <mailto:kemp at network-services.uoregon.edu>>
>>>> *Date:* July 14, 2010 10:17:03 AM PDT
>>>> *To:* Jim Martin <jim at daedelus.com <mailto:jim at daedelus.com>>
>>>> *Subject:* *Re: Certificates for the IETF*
>>>> *Reply-To:*
>>>> <mailto:kemp at network-services.uoregon.edu>kemp at network-services.uoregon.edu
>>>> <mailto:kemp at network-services.uoregon.edu>
>>>> 
>>>> On 07/13/2010 09:36 AM, Jim Martin wrote:
>>>>> Ray,
>>>>>   The cert for portal.meeting.ietf.org
>>>>> <http://portal.meeting.ietf.org> should go to John, since he's the
>>>>> guy actually building the boxes.
>>>>> 
>>>>>   Thanks!
>>>>> 
>>>>>   - Jim
>>>>> 
>>>> 
>>>> Gah.
>>>> 
>>>> I just realized that we require one more certificate for the 2nd vlan.
>>>> Hopefully, that should do it.  I believe we only have "ietf-portal" and
>>>> "ipef-a-portal".  So maybe: https://portal-a.meeting.ietf.org/ as well???
>>>> 
>>>> Should I just generate the csr and ask for 1 more?
>>>> 
>>>> /jgk
>>>> 
>>>> 
>>>> --> here's the sequence.  Upshot is that we need to hand the
>>>> user: https://NAME/, otherwise, they will get a match error at
>>>> the point the SSL starts to check.  And we can't hand them a
>>>> NAME on a vlan outside of the redirect to local bridge ip so...
>>>> 
>>>> Iptables redirects user to br_int_ip.
>>>> br_int_ip is an IP Virtual Host in apache.
>>>> http -> https/NAME/index.pl?redir=...
>>>> Apache also does rewrite of any https URL to a NAME/index.pl
>>>> 
>>>>   index.pl/Apache processes "index.pl" looks at the client IP.
>>>>   index.pl determines the vlan.
>>>>   index.pl uses br_int_name as POST action
>>>>   Configured br_int_name is then filled in as the POST action
>>>> 
>>>> -----------------------------
>>> 
>>> 
>>> _______________________________________________
>>> ietf78-tech mailing list
>>> ietf78-tech at daedelus.com
>>> http://www.daedelus.com/mailman/listinfo/ietf78-tech
>> 
> 
> _______________________________________________
> ietf78-tech mailing list
> ietf78-tech at daedelus.com
> http://www.daedelus.com/mailman/listinfo/ietf78-tech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3675 bytes
Desc: not available
Url : http://www.daedelus.com/pipermail/ietf78-tech/attachments/20100714/6031e323/attachment.bin