ADF Linked Service fails to authenticate when fetching client certificate from Key Vault, but works when uploaded manually

BharathKumarS-1759 60 Reputation points
2025-10-31T07:09:47.36+00:00

Hi everyone,

I’m trying to connect to SharePoint Online List from Azure Data Factory using a service principal with client certificate authentication (application permissions).

The strange part —

  • When the Linked Service is configured to fetch the certificate directly from Azure Key Vault, the test connection fails with an authentication error.
  • But if I download the same PFX from Key Vault and upload it manually into the Linked Service, the connection works perfectly.

I tried both:

  • A Key Vault–generated certificate

A PowerShell self-signed certificate

Both behave the same way — failing only when pulled from Key Vault. The ADF managed identity has KV secret user, KV client certificate user access.

So it feels like ADF isn’t handling the certificate properly when it’s referenced from Key Vault, even though it can access it fine.

Has anyone else faced this issue or found a workaround? Is there something special about how ADF expects the certificate format when coming from Key Vault?

Below are the screenshots of both manual and KV fetched cases of same certificate.

User's imageUser's image

Thanks,

Bharath Kumar S

Azure Key Vault
Azure Key Vault
An Azure service that is used to manage and protect cryptographic keys and other secrets used by cloud apps and services.
{count} votes

Answer accepted by question author
  1. Alex Burlachenko 18,570 Reputation points Volunteer Moderator
    2025-10-31T08:57:47.98+00:00

    Hi BharathKumarS-1759,

    the fact that the manual upload works proves your certificate and service principal are configured correctly. the issue is specifically with how adf retrieves and uses the certificate from key vault.

    the most common culprit here is the certificate's content type. when you upload a pfx to key vault, it is stored as a secret. azure key vault expects the pfx bytes to be base64 encoded. however, sometimes the encoding or the metadata is not exactly what adf expects when it pulls the secret.

    check how the certificate is stored in key vault. go to your key vault in the azure portal, find the secret for your certificate, and check its content type. it should be application/x-pkcs12. if it is something else, like just application/octet-stream, that could be the problem.

    next, try to re upload the pfx to key vault, but this time, use the azure cli or powershell to ensure it is stored correctly. you can use this powershell command.

    az keyvault secret set --vault-name "your-kv-name" --name "your-cert-name" --file "path-to-your-cert.pfx" --content-type "application/x-pkcs12"

    the --content-type flag is key. this explicitly tells key vault that this secret is a pfx certificate.

    after re uploading it with the correct content type, go back to your adf linked service and test the connection again. this often resolves the parsing issue on the adf side.

    if that does not work, there is a known workaround. instead of pointing the linked service directly to the key vault, you can use an adf web activity to fetch the certificate from key vault, decode it, and then pass it to a subsequent activity. but that is much more complex.

    the issue is likely the content type of the secret in key vault. re upload your pfx certificate using the azure cli or powershell and explicitly set the content type to application/x-pkcs12.

    rgds,

    Alex

    0 comments No comments

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.