2 minute read

cURL is one of the most common ways to make HTTP requests from PHP code. When you make regular http:// calls everything is alright, but when you decide to go with https://, you need to configure few things on App Service manually for it to work correctly.

So what is it that you need to be able to call remote server over https://? Usually, you need a CA certificate to be able to verify the remote server's identity. In some cases, people tend to disable CURLOPT_SSL_VERIFYPEER option, which can be good for debug or testing, however, do not ever do this in production (unless of course, you don't give a damn about security).

There are tutorials how to set this up (for example in Azure docs), however beware of this very bit - the path:

; Example Settings
curl.cainfo="%ProgramFiles(x86)%\Git\bin\curl-ca-bundle.crt"

The path is referring to the web instance's filesystem, based on the CURRENT image and version of Git which is installed on the instance. In short, this means that if something changes on the instance, like a new version of git is installed, where certificates get stored into %ProgramFiles(x86)%\Git\usr\ssl\certs\ca-bundle.crt, your application is going to stop working and you may have a hard time figuring out what is wrong.

Why am I writing this?

Because it actually happened. I was relying on the certificate which is distributed with Git - because I thought - "hmm, if I upload my own, I will have to maintain it, so I am going to use the one distributed with Git, because Microsoft will be keeping it up-to-date" - and that is exactly what happened. While I was relying on the path shown in the example, the instances were upgraded with a new version of Git, which stores the CA certificate in a different path - and things obviously started falling apart.

Conclusion

So I would say that it is a good practice to distribute a CA certificate when deploying your application to Azure - this can be achieved by plugging the task into the release definition in VSTS or deployment script, and it is going to always keep the certificate up to date, and you will be the one having control of it. So the advice is - do not rely on anything which is not distributed with your application (except the default configuration of the runtime and its settings).

To submit comments, go to GitHub Discussions.