I have multiple IP addresses on a particular server running Nginx. Each IP has a site and certificate including the hosting front end. When adding a new site with SSL that does NOT have it's own IP address Aegir assumes you want to use the primary IP that the front end is using. All that is expected behavior.

The problem is when I visit the newly added site I get the certificate from front end and not from the new site.

Looking at the vhost I see that the front end (or probably the first site with an SSL) gets an IP:

  listen        XX.XX.XX.XX:443 ssl http2;

But the second site gets a wildcard:

  listen       *:443 ssl http2;

If I manually edit the vhost of the second site and include the IP address it fixes the problem.

I can see in vhost_ssl.tpl.php where it shows the IP is a variable, but I can't seem to figure out where that is coming from.

<?php print "{$ssl_listen_ip}:{$http_ssl_port} {$ssl_args}"; ?>;

So the question is: Where is this coming from OR what do I need to change so this works correctly?

Comments

jeremyr created an issue. See original summary.

memtkmcc’s picture

memtkmcc CreditAttribution: memtkmcc at Omega8.cc commented
Assigned: Unassigned » memtkmcc
Category: Support request » Bug report

It is a bug we need to fix.

Apache config already uses <VirtualHost *:443> wildcard, while Nginx still has this code:

<?php foreach ($server->ip_addresses as $ip) :?>
  listen       <?php print $ip . ':' . $http_ssl_port; ?>;
<?php endforeach; ?>
memtkmcc’s picture

memtkmcc CreditAttribution: memtkmcc at Omega8.cc commented

That said, Apache config also has similar leftover in the template for disabled sites:

<VirtualHost <?php print "{$ip_address}:{$http_ssl_port}"; ?>>
memtkmcc’s picture

memtkmcc CreditAttribution: memtkmcc at Omega8.cc commented

In fact, it is perhaps OK for Apache to use $ip_address in that template (not sure, though), while in Nginx it is always wrong to use both wildcards and IP addresses in listen directives, because in the TLS/SNI mode, wildcards have always lower precedence.

It was discussed in the past: #1975188: nginx default server overrides configured vhosts

And even fixed already.

Not sure how it got back in the template for Nginx.

memtkmcc’s picture

memtkmcc CreditAttribution: memtkmcc at Omega8.cc commented

The IPs allocation in the context of TLS/SNI doesn't make any sense, and it was discussed extensively in the past.

The problem here is that we should use wildcards consistently in Nginx to avoid these problems, but such change is probably not allowed in the bug fix release.

For now we should at least sync it with Apache and use wildcard in the server (main-default) template.

memtkmcc’s picture

memtkmcc CreditAttribution: memtkmcc at Omega8.cc commented
Version: 7.x-3.7 » 7.x-3.x-dev
jeremyr’s picture

jeremyr CreditAttribution: jeremyr as a volunteer commented

memtkmcc thank you for the work you're doing on this!

memtkmcc’s picture

memtkmcc CreditAttribution: memtkmcc at Omega8.cc commented

OK, I think we have reverted these "fixes" in Nginx config at some point, for the exact same reason - to avoid mixing wildcard and IP based listen directives, because it always causes problems with Nginx, due to the fact that it always grants higher precedence for IP based directives, while Aegir still uses the pre-SNI method of managing IPs per site/certificate.

The wildcard used in Apache default catch-all server may work in Apache, but it would cause problems in Nginx. Also, in Nginx we don't even specify any certificate for the HTTPS catch-all server, so it is not going to work and should be somehow fixed/removed, perhaps.

We are going to switch to the SNI-by-default config in Aegir soon, so with wildcards everywhere the problem will be fixed automatically, but we should at least try to avoid situations like reported here, by not allowing to mix wildcards and IP listen directives on the same system.

We force wildcards and SNI on BOA for a very long time, by the way, so the problem here is specific to vanilla Aegir on Nginx.