[ietf78-tech] Fwd: Certificates for the IETF

[John Kemp]

If we need more stuff later, that seems like a good idea.
But for now, I would suggest we just get his one more.
Minimum hassle factor...

/jgk


On 07/14/2010 02:16 PM, Chris Elliott wrote:
> Could we instead request a certificate we could use for our own CA for meeting.ietf.org? Then we could generate whatever we need.
> 
> Chris.
> 
> 
> --
> Chris Elliott
> 
> 
> On Jul 14, 2010, at 5:10 PM, Jim Martin <jim at daedelus.com> wrote:
> 
>> 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
>>
>> _______________________________________________
>> ietf78-tech mailing list
>> ietf78-tech at daedelus.com
>> http://www.daedelus.com/mailman/listinfo/ietf78-tech