I just added a second SSL site to Nginx uising two different certs. The
problem is that both sites are pulling the one cert. I have each of
them served on 443 and serving their own domains. Just like i would
think port 80 to work with multiple sites but its not. Is there another
port i should use for the second instance say 444 ? and just action that
in rails ? anyone experience similar ?
Chris
On Wed, May 28, 2008 at 11:07 AM, Eire A. [email protected]
wrote:
I just added a second SSL site to Nginx uising two different certs. The
problem is that both sites are pulling the one cert. I have each of them
served on 443 and serving their own domains. Just like i would think port
80 to work with multiple sites but its not. Is there another port i should
use for the second instance say 444 ? and just action that in rails ?
anyone experience similar ?
I think I experienced this at first, and IIRC it was a wildcard name
on one of the domains causing it… removed that and it works now
We bind extra SSL sites to 444,445,etc to avoid these issues. We run
an lvs load balancer in front of them and assign a public IP per SSL
server instance. So external ip #1 443 routes to internal 443 and
external ip #2 443 routes to internal 444. It greatly simplified
things for us but it might not be an option for everyone.
__
Corey D.
[email protected]
(866) 518-9273 x207
Chris,
Are you using one ip address for multiple domain/ssl certs? If so, I
believe you may need to assign each cert to a separate ip.
Are you using a separate host names in one domain? You might need a
wild card certificate (*.yourdomain.com). There is a problem in that
nginx needs to see the request URL before deciding which cert to use
in the handshake. However, nginx cannot see the URL until the
handshake has been completed. See
NameBasedSSLVHosts - HTTPD - Apache Software Foundation for more details.
If you get it working or you have a different setup then send mail to
the list.
–
Calomel @ https://calomel.org
Open Source Research and Reference
you cant do virtual naming with ssl
because the cert negotation comes first.
i.e. each ssl site needs its own ip.
Yes I am using one IP with multiple domains/certs
so depending on the server and if i can get another IP
I’m pretty certain Virtual servers can get more IP’s w/o
adding hardware?
“nginx cannot see the URL until the
handshake has been completed”
makes sense for customer security
Calomel [email protected] wrote: Chris,
Are you using one ip address for multiple domain/ssl certs? If so, I
believe you may need to assign each cert to a separate ip.
Are you using a separate host names in one domain? You might need a
wild card certificate (*.yourdomain.com). There is a problem in that
nginx needs to see the request URL before deciding which cert to use
in the handshake. However, nginx cannot see the URL until the
handshake has been completed. See
NameBasedSSLVHosts - HTTPD - Apache Software Foundation for more details.
If you get it working or you have a different setup then send mail to
the list.
–
Calomel @ https://calomel.org
Open Source Research and Reference
right. thanks to all the help
Chris
Calomel [email protected] wrote: Chris,
Getting multiple ips for one physically system to multiple virtual
domains should not be a problem. Once you have the ips then have each
Nginx server {…} section listen to a separate ip and define its own
SSL cert.
–
Calomel @ https://calomel.org
Open Source Research and Reference
Chris,
Getting multiple ips for one physically system to multiple virtual
domains should not be a problem. Once you have the ips then have each
Nginx server {…} section listen to a separate ip and define its own
SSL cert.
–
Calomel @ https://calomel.org
Open Source Research and Reference
Sean A. wrote:
you cant do virtual naming with ssl
because the cert negotation comes first.
However, SNI is rapidly becoming an option?
It appears that SNI support has been backported to at least OpenSSL
0.9.8g ? You need to specify --enable-tlsext when building openssl
What else is required on the nginx side in order to test TLS upgrades?
Does someone have a sample config showing this working on some web
browser?
Cheers
Ed W
Ed,
As I understand it tlsext is still in “BETA” like stage for 0.9.8g. I
also believe remote clients must be strictly RFC 4366 compliant
otherwise browsers will still get a SSL error page.
According to Goggle, this site has a test case tlsext setup.
https://dave.sni.velox.ch/
–
Calomel @ https://calomel.org
Open Source Research and Reference
Calomel wrote:
Ed,
As I understand it tlsext is still in “BETA” like stage for 0.9.8g. I
also believe remote clients must be strictly RFC 4366 compliant
otherwise browsers will still get a SSL error page.According to Goggle, this site has a test case tlsext setup.
https://dave.sni.velox.ch/
Got any tips to configure nginx to support the same (subject to browser
compatibility, etc)
Cheers
Ed W
On 5/28/08, Sean A. [email protected] wrote:
you cant do virtual naming with ssl
because the cert negotation comes first.
i.e. each ssl site needs its own ip.
Unless you have a wildcard cert, and all the sites are subdomains that
match the cert.
yeah, i have… o… 40 or so of those setup right now.
now if you could use a variable name in the cert configurations…
that and log files, o life would be so much easier.
On May 30, 2008, at 12:41 AM, eliott wrote:
On 5/28/08, Sean A. [email protected] wrote:
you cant do virtual naming with ssl
because the cert negotation comes first.
i.e. each ssl site needs its own ip.
Unless you have a wildcard cert, and all the sites are subdomains that
match the cert.
ok, you got me on that edge case.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs