“The remote certificate is invalid according to the validation procedure” error, intermediate certificates, proxy servers, and WinHTTP
We recently upgraded our SSL certificates on our web servers – we use GeoTrust, who recently moved to the intermediate root certificate model (well, recently meaning July, 2010) and this is our first renewal since the change.
This should have been a completely transparent change, and all in all it came pretty close. Where it didn’t go so smoothly was where SharePoint web services is concerned.
We run a few mechanisms in our stack where a process on a server relies on a connection to the SharePoint Lists web service; some are web server-based and some are running from within SQL Server. Our network architecture also puts all of our infrastructure behind a proxy, and users are granted access to the internet by login rules that set the Internet Explorer proxy appropriately.
When we installed the new set of certificates (including one for our SharePoint web servers) everything went well for the users. They connected to SharePoint and downloaded the intermediate certificates without any difficulty.
On the servers, though, it was another matter entirely. Even though the user under which context we were executing the web service calls was granted access to the internet and had previously had it’s IE proxy settings properly set the attempts to negotiate an SSL connection were failing with the error message:
The remote certificate is invalid according to the validation procedure
As it turns out, the servers were attempting to download the intermediate certificates using WinHTTP, which maintains a separate proxy configuration that needed to be set in order to allow the servers to access the intermediate certs. Another short-term solution was temporarily to open traffic from each server to the internet without filtering through the proxy, which would allow the server to download the intermediate certificate, but in the long term adding the WinHTTP proxy settings is a better solution.
In the end, our Infrastructure team was of two minds about this issue, and since the WinHTTP solution required a registry edit the simpler of the two solutions was attempted. While the service account that SQL Server is running under had been granted internet access previously, its current proxy settings in IE were out of date. We logged into the server as that user. updated the IE proxy settings, and re-ran the SQL job, and all worked as expected. On a previous occasion we simply opened up the problem machine to the internet for long enough for it to download the intermediate certificates, but this seems like a simpler and slightly more secure solution