Describe the bug
Yesterday we renewed our TLS certificate, and deployed it to our Azure Application Gateway as per usual. The gateway is a reverse proxy in front of the Wordpress installation, and the installation itself has a different TLS certificate internally which is not exposed to end-users. Once this new certificate was installed, the plugin blocked users with the message:
SSL certificate problem: unable to get local issuer certificate
Disabling the option for SSL Verify in the plugin "resolves" the issue, but we would like to have it working as it was before, since this is not really the recommended way to have this working.
To Reproduce
This started after installing a new certificate in the reverse proxy.
Expected behavior
We expected that a certificate obtained from a well-known CA (and the same we used previously) should not be blocked by the SSL verification.
Isolating the problem (mark completed items with an [x]):
[ ] I have deactivated other plugins and confirmed this bug occurs when only this plugin is active.
[ ] This bug happens with a default WordPress theme active.
[X] I can reproduce this bug consistently using the steps above.
WordPress Environment
Website URL: Only for internal users - I can give more info about the certificate itself if needed
After investigation, this seems to be related to the host machine, rather than the app. curl command verifies that one of the intermediate certs is not in the trusted store.
Describe the bug Yesterday we renewed our TLS certificate, and deployed it to our Azure Application Gateway as per usual. The gateway is a reverse proxy in front of the Wordpress installation, and the installation itself has a different TLS certificate internally which is not exposed to end-users. Once this new certificate was installed, the plugin blocked users with the message: SSL certificate problem: unable to get local issuer certificate
Disabling the option for SSL Verify in the plugin "resolves" the issue, but we would like to have it working as it was before, since this is not really the recommended way to have this working.
To Reproduce This started after installing a new certificate in the reverse proxy.
Expected behavior We expected that a certificate obtained from a well-known CA (and the same we used previously) should not be blocked by the SSL verification.
Isolating the problem (mark completed items with an [x]):
WordPress Environment