Multiple server definitions with SSL

Ben Lancaster benlancaster at holler.co.uk
Tue Jul 26 16:44:32 UTC 2011


We recently had a problem where we created a new server configuration (for http with and without ssl on ports 443 and 80 respectively) on a shared web server which also included a number of other nginx servers similarly configured. 

Unfortunately, we neglected to include the ssl_certificate and ssl_certificate_key directives for the new server. So, the configurations looked something like this:

# START CONFIG #

# Pre-existing, working server definition (one of several)
server {
  listen 80;
  listen 443 ssl;

  server_name first.example.com;

  ssl_certificate /path/to/ssl.crt
  ssl_certificate_key /path/to/key.crt

  # snip #
}

# New server definition
server {
  listen 80
  listen 443 ssl;

  server_name second.example.com;
  
  # snip #
}

# END CONFIG #

Now, prior to restarting the nginx process, we issued "nginx -t" to test the new configuration - everything passed. Once the nginx service was restarted, however, the old, working site failed to respond to https requests (cURL said "Unknown SSL protocol error in connection to first.example.com:443 "), even though the configuration for that particular server was unchanged.

I've since added a default SSL server to my config, which seems to fix this problem incase ssl_certificate_* lines get missed in future (there was no server with "listen 443 ssl default" prior to that).

We're running Ubuntu 10.04 LTS x86_64 with Nginx 1.0.0 stable from PPA:

$ nginx -V
nginx: nginx version: nginx/1.0.0
nginx: TLS SNI support enabled
nginx: configure arguments: --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-1.0.0/debian/modules/nginx-echo --add-module=/build/buildd/nginx-1.0.0/debian/modules/nginx-upstream-fair

Is this expected behaviour? Should nginx -t not have flagged that there was no default ssl_certificate(_key) directives defined? Why was the first server affected?



More information about the nginx mailing list