Re: Wierd issue with OCSP updating
On 7/8/23 21:33, Shawn Heisey wrote: Here's the very weird part. It seems that haproxy is sending the OCSP request to localhost, not the http://r3.o.lencr.org URL that it SHOULD be sending it to. Right before the above log entry is this one: Jul 8 21:15:38 - haproxy[4075] 127.0.0.1:57696 [08/Jul/2023:21:15:38.447] web80 web80/ 0/-1/-1/-1/0 302 230 - - LR-- 1/1/0/0/0 0/0 "GET /MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgOq9K0xVAXkgj8X4cNGeMutQw%3D%3D HTTP/1.1" Anyone have any idea why haproxy is sending the ocsp request to 127.0.0.1 when it should be going to a public address obtained from the dns name r3.o.lencr.org? If I do this command on the same machine, it works correctly: curl -v -o response.ocsp "http://r3.o.lencr.org/MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgOq9K0xVAXkgj8X4cNGeMutQw%3D%3D; Thanks, Shawn
Re: Wierd issue with OCSP updating
On 7/8/23 21:33, Shawn Heisey wrote: Here's the very weird part. It seems that haproxy is sending the OCSP request to localhost, not the http://r3.o.lencr.org URL that it SHOULD be sending it to. Right before the above log entry is this one: Jul 8 21:15:38 - haproxy[4075] 127.0.0.1:57696 [08/Jul/2023:21:15:38.447] web80 web80/ 0/-1/-1/-1/0 302 230 - - LR-- 1/1/0/0/0 0/0 "GET /MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgOq9K0xVAXkgj8X4cNGeMutQw%3D%3D HTTP/1.1" Anyone have any idea why haproxy is sending the ocsp request to 127.0.0.1 when it should be going to a public address obtained from the dns name r3.o.lencr.org? If I do this command on the same machine, it works correctly: curl -v -o response.ocsp "http://r3.o.lencr.org/MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgOq9K0xVAXkgj8X4cNGeMutQw%3D%3D; Thanks, Shawn
[PR] Allow load of non-existing pattern files.
Dear list! Author: Daan van Gorkum Number of patches: 1 This is an automated relay of the Github pull request: Allow load of non-existing pattern files. Patch title(s): Allow load of non-existing pattern files. Link: https://github.com/haproxy/haproxy/pull/2209 Edit locally: wget https://github.com/haproxy/haproxy/pull/2209.patch && vi 2209.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/2209.patch | git am - Description: To allow pure usage of the runtime API/LUA to add/remove entries in Maps/ACLs we should be able to load non-existing patterns. This make deploying easier as otherwise empty files needs to be created. A notice is issued when this config option is used and every time a non-existing file is loaded. Fixes: #2202 Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
Re: OCSP update mechanism startup
On 07/07/2023 18:24, Willy Tarreau wrote: On Fri, Jul 07, 2023 at 03:42:58PM +, 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| grep -m1 CN 0 s:CN = ssl383624.cloudflaressl.com $ openssl s_client -servername blah.com -connect www.fastly.com:443 /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
