On 07/07/2023 18:24, Willy Tarreau wrote:
On Fri, Jul 07, 2023 at 03:42:58PM +0000, Tristan wrote:
Also personally I have never understood the point of default server certs...
besides getting unwanted attention from censys/shodan/etc...
I remember some users who were hosting many applications from internal
subsidiaries wanted to make sure that unhandled names were always served
on the corporate site, at least to say something along "this site is no
longer here" or just to direct users to the list of available sites.
In the past it was common as well on hosting providers that any unhandled
site was handled by a default page hosted by that provider. However it
seems it's less common nowadays with SSL (though I could be wrong). Hmmm
just testing right now seems to indicate it's still the case for some:
$ openssl s_client -servername blah.com -connect www.cloudflare.com:443
</dev/null 2>/dev/null| grep -m1 CN
0 s:CN = ssl383624.cloudflaressl.com
$ openssl s_client -servername blah.com -connect www.fastly.com:443 </dev/null
2>/dev/null | grep -m1 CN
0 s:CN = www.fastly.com
So it seems to indicate that such infrastructures which are designed to
host hundreds of thousands of domains still prefer to be able to deliver
something if the user is willing to click on "accept the risk".
Hmm, I understand why it was decided to go that route, and indeed that is
probably not too too hard to do... Though I can't help wonder if an opt-in
mechanism similar to the server state file would make sense for it?
I seem to remember that it's possible to issue a "show ocsp" on the CLI
and direct it to a file, but I could be wrong. That's the same way the
server-state works by the way.
I'll take a look at it, though the main advantage would be to keep it all in
HAProxy and to avoid dirty cron jobs. But I appreciate that's me asking for
HAProxy to do everything and more beyond its job... :)
For the server state, it was performed at reload time, no need for a cron
job. I don't see why it would have to be different here.
It might be a bit more complicated than for the server state file since
we could have OCSP responses that don't correspond to any file on the
filesystem. We can't just assume that the foo.pem.ocsp file does not
exist and create a file at this location since it might exist but not
have been loaded by haproxy (through a ssl-load-extra-files none for
instance). And updating only OCSP responses that were loaded at build
time and for which we have an actual path would not be that satisfying.
It would still require an extra step for new responses.
We could add an extra global parameter that defines a directory in which
those responses are written but reusing them for a new haproxy process
would require that those responses are moved alongside their
corresponding certificate, which could be a pain as well.
But I fully agree that it would help to be able to perform this
operation from haproxy directly. I just don't see a simple solution yet.
Rémi
