I want to go with let's encrypt certifcates so if I provide the pem
created by the acme-client it should be ok even it seems not for now.
I dont know if relayd development is going to add SNI sometime soon but
for now I could live with a certificate that basically has all my served
domains as in the SAN field.
Am 21.09.2017 um 14:49 schrieb trondd:
> On Thu, September 21, 2017 8:25 am, rosjat wrote:
>> I try to figure out the ca file option mentioned by ronan maybe this is
>> some kind of option here.
>>
>
> Using 'ca file' means you have to decrypt the SSL connection from the
> clients with relayd then re-encrypt from relayd to the web servers.
> Clients will only see relayd's SSL certificate. Originally you said you
> want to use a different cert for each web site.
>
> What CA signs the web server certificates? There was a bug, I don't know
> if it got fixed, in relayd that you can't use a big file of CAs for the
> 'ca file', the imsg was not chunked and if the file is too big, relayd
> will fail to start the relay. Take the CA cert that signed the web server
> certificates and put that into a file and reference that file like 'ca
> file "/etc/ssl/webca.pem"'
>
>> Am 21.09.2017 um 14:11 schrieb trondd:
>>> On Thu, September 21, 2017 3:49 am, rosjat wrote:
>>>> Hi,
>>>>
>>>> so I added the with tls keywords to the relay and my webserver gets
>>>> request now but from my relayhost and this is making the way back quiet
>>>> hard :(
>>>>
>>>> so I added the X Headers for Forwarded-For and Forwarded-By but it
>>>> still
>>>> leaves the question how to tell the relayhost to just let it all out
>>>> like in a normal rdr-to rule in pf? Like I said pf rule just works fine
>>>> so the traffic can go thorugh all the interfaces just fine.
>>>>
>>>> regards
>>>>
>>>> MArkus
>>>>
>>>
>>> You can't do what you want with a layer 7 relay in relayd. Redirect
>>> rules
>>> in pf work because pf doesn't know or care about DNS host names.
>>>
>>> Because you are using SSL, once you need to make decisions based on the
>>> host, you have two options:
>>>
>>> A relay server that supports SNI so it can see the Host and forward to
>>> the
>>> right server. Or terminating the SSL encryption at the relay server so
>>> you can read the unencrypted host value.
>>>
>>> Option 2 is required for relayd as it does not support SNI. But that
>>> means the relay server holds the SSL certificate. You can only have 1
>>> certificate per IP and port. If you want to use individual certs for
>>> each
>>> web site, you're stuck. You either need to use different ports, which
>>> is
>>> typically a non-starter for web sites, or put multiple IPs on the relay
>>> box.
>>>
>>> If security between the relay server and web servers is necessary (don't
>>> trust someone else's network, and if possible, don't trust your own) you
>>> can re-encrypt the communication from relayd and the web server but
>>> it'll
>>> be relayd using the web server certificate, not the user.
>>>
>
>
>
--
Markus Rosjat fon: +49 351 8107223 mail: rosjat@ghweb.de
G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden
http://www.ghweb.de
fon: +49 351 8107220 fax: +49 351 8107227
Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before
you print it, think about your responsibility and commitment to the
ENVIRONMENT
No comments:
Post a Comment