HTTPS problem: wildcard in the certificate

Somebody raised an interesting problem recently with our SLOODLE tools in-world. The tools connect to a Moodle website, and on HTTP it's always fine. I had thought it was OK on HTTPS, if the certificate was valid and properly signed.

However, in this case, the certificate had a wildcard in it, let's say: *.yoursite.com. The actual Moodle website was hosted at "moodle.yoursite.com", so the wildcard certificate should normally be fine. LSL didn't seem to like this though, and kept responding with a 499 status code. Preliminary tests seem to suggest that setting HTTP_VERIFY_CERT to false makes the HTTP requests work in this case. (The certificate itself is properly signed and verifiable, so I hadn't expected this to be necessary.)

I think the only solution would be to change all the code to set HTTP_VERIFY_CERT to false in every HTTP request. Given the size of our code base, that's not really practical just now, especially since it's only one person who might benefit from the change.

If anybody knows of any other way round this, then I'm open to suggestions! Otherwise, hopefully it's a useful bit of experience for others to know about.

Perhaps it would be beneficial to establish a simple proxy server, using libcURL. Just use cURL to validate the request, and then pass it from a compliant (not wildcard signed) host. The effort would be minimal, and you could sell it as a value added service.

Even if you would not want to do it, I would offer my services to said client on my HTTPS servers, just message me inworld.