Ignore broken SSL servers in config

TL;DR:
Any nginx setting to say ‘if a vhost’s ssl settings are broken, skip it
and
don’t fail to start’ ?

I’ve certainly RTFM’d this and peered at the source, but I figured I
might
as well throw it out there, in case there’s some hidden setting I’ve
missed.

I’m building a reverse proxy config for thousands of SSL virtual hosts,
to
replace an apache solution.

It very often happens that someone in support will make a mistake with
regards to certs/keys. E.g. updating someone’s SSL cert but actually
putting the CSR there instead.

In apache, since the config is being generated out of mod_perl, I can
get
around this situation by having mod_perl do a modulus check on the cert
and
key and skip the vhost if they don’t match. In my case, I’d far prefer
to
have a missing vhost and have the other 1000 sites working, than all
down.

And, yes, I realize in default apache, it’d just fail to load. And also,
yes, I realize asking something to ignore broken configs is a bit
non-standard :slight_smile:

Since I don’t have mod_perl at my fingertips in nginx to perform a
similar
trick, the startup will just fail.

So I was curious if there’s some obscure setting to tell nginx “if a
vhost
fails to loads its cert properly (or potentially any other vhost
setting),
skip it and continue loading the rest”?

If such a thing did exist, I imagine that the configtest would have to
turn
errors for that vhost into warnings as well.

My guess is obviously ‘no’, but I figured asking woud only cost me the
time
it takes to compose an email.

Hello!

On Wed, Jun 19, 2013 at 11:06:19AM -0700, Mark M. wrote:

It very often happens that someone in support will make a mistake with
non-standard :slight_smile:

My guess is obviously ‘no’, but I figured asking woud only cost me the time
it takes to compose an email.

In nginx, there are two mechanism to deal with configuration
errors:

  1. On configuration reload nginx refuses to load a new
    configuration if there are errors (and continues to work with
    previously loaded correct configuration).

  2. There is “nginx -t” to test configs.

By using the two you are safe from a situation when a typo
in configuration takes a service down (well, mostly: one always
can take it down with a valid config). There is no kludge to
magically apply only parts of a configuration though.


Maxim D.
http://nginx.org/en/donation.html

On Thu, Jun 20, 2013 at 2:00 AM, Maxim D. [email protected]
wrote:

might

If such a thing did exist, I imagine that the configtest would have to

  1. On configuration reload nginx refuses to load a new

Yup, that’s what I figured. Thanks for confirming.