On 10/07/2023 22:41, Shawn Heisey wrote:
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/<NOSRV> 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";
The OCSP update mechanism uses the internal http_client which then uses
the resolvers. The only time when I had some strange resolver-related
issues is when the name resolution returned IPv6 addresses which were
not properly managed on my machine. The workaround I had in this case
was to add "httpclient.resolvers.prefer ipv4" in the global section.
You could also try to perform the same kind of request using the
http_client directly from the CLI.
Rémi
