@moparisthebest you up to check what this is about?

Debugging through the curl and openssl code, it seems to me that even if public-key pinning is the selected option, CA pinning is also being done, and this is why the failure occurs.
The logic starts from ossl_connect_common():

  while(ssl_connect_2 == connssl->connecting_state ||
        ssl_connect_2_reading == connssl->connecting_state ||
        ssl_connect_2_writing == connssl->connecting_state) {

    ...
    /* Run transaction, and return to the caller if it failed or if this
     * connection is done nonblocking and this loop would execute again. This
     * permits the owner of a multi handle to abort a connection attempt
     * before step2 has completed while ensuring that a client using select()
     * or epoll() will always have a valid fdset to wait on.
     */
    result = ossl_connect_step2(conn, sockindex); // -------> the certificates are verified here
    if(result || (nonblocking &&
                  (ssl_connect_2 == connssl->connecting_state ||
                   ssl_connect_2_reading == connssl->connecting_state ||
                   ssl_connect_2_writing == connssl->connecting_state)))
      return result;

  } /* repeat step2 until all transactions are done. */

  if(ssl_connect_3 == connssl->connecting_state) {
    result = ossl_connect_step3(conn, sockindex); // --------> the public key is checked here
    if(result)
      return result;
  }

ossl_connect_step2() calls SSL_connect() from openssl, which at some point verifies the certificate chain in the X509_verify_cert() function:

/* We now lookup certs from the certificate store */
for (;;) {
    /* If we have enough, we break */
    if (depth < num)
        break;
    /* If we are self signed, we break */
    if (cert_self_signed(x))
        break;
    ok = ctx->get_issuer(&xtmp, ctx, x); // -----> can't find the issuer of the intermediate certificate, so fails with ok = 0

    if (ok < 0) {
        ctx->error = X509_V_ERR_STORE_LOOKUP;
        goto err;
    }
    if (ok == 0)
        break;
    x = xtmp;
    if (!sk_X509_push(ctx->chain, x)) {
        X509_free(xtmp);
        X509err(X509_F_X509_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
        ctx->error = X509_V_ERR_OUT_OF_MEM;
        ok = -1;
        goto err;
    }
...

So because the ossl_connect_step2() fails it never ends up calling ossl_connect_step3(), where the public key is actually being checked.

I figure you need to explicitly switch off the CA verification with CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST.

Thank you, it works this way. It now says:
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
, and then it continues with the download.

Actually only disabling CURLOPT_SSL_VERIFYPEER seems to be necessary; I guess the host name can still be checked against the one from the received certificate.

But is this safe? In the documentation for CURLOPT_SSL_VERIFYPEER it says:
WARNING: disabling verification of the certificate allows bad guys to man-in-the-middle the communication without you knowing it. Disabling verification makes the communication insecure. Just having encryption on a transfer is not enough as you cannot be sure that you are communicating with the correct end-point.
I'm guessing this warning doesn't apply in this case because even if an attacker would forge a certificate it would still need to have a public key with the exact same SHA256 hash as the one used by the client...

But is this safe?

The documentation for that option doesn't really take pinning into consideration. Key pinning is really an alternative to the regular VERIFYPEER so yes, I would qualify that as still safe. We should probably attempt to phrase that a little better in the documentation.

And as you say, the VERIFYHOST verifies that the host is correct in the server cert so you can probably keep that as it really should match even when you use pinning.

Thanks for the confirmation. That makes it very clear.