[ietf78-tech] Fwd: Certificates for the IETF

[Chris Elliott]

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