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. Willy
