Automate’s HTTP action silently dropping the client certificate when Basic Auth is also configured?

(2) Share

Report

Posted on by NealM4815

I’ve been trying to resolve a failing API integration for several weeks and have finally isolated what appears to be a bug.

THE ISSUE

When a Power Automate HTTP action is configured with both:

•Authentication type: Client Certificate

•A manual Authorization: Basic header

Power Automate silently drops the client certificate during the TLS handshake. The certificate is never presented to the server, causing the mTLS connection to fail.

The identical call in Azure Logic Apps (same certificate, same Authorization header) is successful.

I’ve tested with certificates from Azure Key Vault and also with the PFX base64-encoded inline…same result either way.

Tested successfully with other platforms (postman, SAP APIM, curl, RPA software). Only Power Automate seems to have this problem and I don’t know how to fix it (or if it can be fixed)

For testing, I did a test with badssl’s public certificate. I was able to make the HTTP call using their certificate in Power Automate. As soon as I added their Authorization header, the same call failed.

It looks like Power Automate treats the presence of an Authorization header as the active authentication mechanism and stops presenting the client certificate at the TLS layer. Logic Apps handles the two authentication mechanisms independently and correctly. TLS (certificate) and HTTP (Authorization header) are separate layers and should not interfere with each other.

This makes it impossible to call any API that requires both mTLS client certificate authentication AND HTTP Basic Auth credentials from Power Automate despite this being a valid and common enterprise API security pattern.

I opened a support ticket with Microsoft but I haven’t really gotten any solid info back. Has anyone else seen this? Has anyone found a workaround within Power Automate ?

I have the same question (0)

All responses (3)

Answers (0)

Sort by

Suggested answer

11manish 3,333 on at

Like
a
(1)

Report
Copy link

Link copied!

I believe that this is a known limitation (or bug) in the Power Automate HTTP action where combining client certificate authentication (mTLS) with a manually added Authorization header causes the certificate to be dropped during the TLS handshake.

While this works correctly in Azure Logic Apps, Power Automate does not currently handle these two authentication layers independently.

There is no reliable fix within Power Automate itself.

The recommended workaround is to route the request through Azure Logic Apps, Azure API Management, or an Azure Function, which can properly handle both mTLS and HTTP authentication before calling the target API.

Was this reply helpful? Yes No
Suggested answer

Valantis 6,735 on at

Like
a
(2)

Report
Copy link

Link copied!

Hi @NealM4815,

Your diagnosis makes technical sense. Power Automate's HTTP action likely has logic that short-circuits certificate presentation at the TLS layer when it detects an Authorization header, treating it as a conflicting auth mechanism rather than a separate layer. Logic Apps handles them independently because its underlying HTTP pipeline is architecturally different.

For a workaround within Power Automate, the only realistic option I can see is routing the call through Azure API Management.

You configure APIM as the endpoint from Power Automate, handle the mTLS client certificate at the APIM layer (where certificate + Basic Auth coexist fine), and APIM forwards the combined authenticated request to your target API. It adds a hop but it's fully supported and your flow doesn't need to change beyond pointing to the APIM URL.

Alternatively if you have Azure Logic Apps available in your tenant, you could invoke the Logic Apps HTTP action from Power Automate via a nested call, since you've already confirmed Logic Apps handles the combination correctly.

This is worth escalating beyond the standard support ticket.

Post it to https://aka.ms/powerautomate-ideas with your reproduction steps including the badssl test that's a clean reproducible case that Microsoft's engineering team can verify without needing access to your environment.

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No
xs2bharat 4 on at

Like
a
(0)

Report
Copy link

Link copied!

I am running into similar issue starting June 24 2026 but weirdly enough another similar http connector is working fine. opened Microsoft support case.

Was this reply helpful? Yes No