Ignore broken SSL servers in config

[Mark Moseley]

On Thu, Jun 20, 2013 at 2:00 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Wed, Jun 19, 2013 at 11:06:19AM -0700, Mark Moseley wrote:
>
> > 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 :)
> >
> > 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.
>
> 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.
>
>
Yup, that's what I figured. Thanks for confirming.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130620/3f9d512f/attachment-0001.html>