An update from our side:
We have renewed our client's SSL certificate today, which has resolved the error that was originally reported.
Our previous SSL supplier was GoDaddy, and is now TSO Host. Both certificates are standard SSL certificates for a subdomain.
Not sure if this will help resolve the issue, or will help in any way for anybody else.
For anyone following this thread in the future, I had a similar problem caused not by an expired cert, but a dodgy Apache vhost config.
The Shopify app proxy will verify the certificate of the target system, which means you need to set in your vhost:
Sometimes SSLCACertificateFile is only set if SSLVerifyClient is also set.
If you're debugging this sort of thing in the future, don't just rely on Chrome Developer tools. I had two URLs (one working with app proxy, one not). Both showed a valid certificate, both responded with identical content and near identical headers. In the end I had to use cURL to expose the problem:
curl -XGET -v <url>
which highlighted the error:
* NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER)
* Peer's Certificate issuer is not recognized.
* Closing connection 0
curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Shopify couldn't validate my cert because it didn't know where to find the CA bundle.