On 11/07/2023 22:22, Shawn Heisey wrote:
On 7/11/23 01:30, Remi Tricot-Le Breton wrote:
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.
That directive didn't work in "global" but it was accepted when I
moved it to "defaults". But it didn't change the behavior. IPv6 is
completely disabled on the server.
Didn't work as in an error was raised ? I have a local configuration
file with this option in the global section and it seems to work fine.
You could also try to perform the same kind of request using the
http_client directly from the CLI.
Can you explain how to do this? When I make the request with curl, it
works, but I don't know how to do what you are saying here.
You can use the "httpclient" CLI command this way:
echo "expert-mode on; httpclient GET
http://r3.o.lencr.org/MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgOq9K0xVAXkgj8X4cNGeMutQw%3D%3D";
| socat <your_stat_sock> -
It probably won't work either but at least you will have an easier way
of testing the resolvers outside of the OCSP update. Apart from a
specific configuration on your system I don't really see a reason why
your tests fail somewhere and work correctly on another machine.
Everything works on another server running a newer version of Ubuntu.
That uses a newer version of gnu libc, which affects pretty much
everything on the system, and a large number of other libraries are
newer as well.
Rémi
