Azurestorageexplorer: Storage explorer not finding tenant: SELF_SIGNED_CERT_IN_CHAIN

[bplaats]

Storage Explorer Version:
Platform/OS Version:win7
Architecture:
Regression From:

Steps to Reproduce:

1. login to storage explorer
2. storage explorer authenticates authenticates successfully but no tenant/subscription or errors on retreivel

Expected Experience:

expect storage listing for subscription

Actual Experience:

Received this error and told to report here to github

Subscriptions for the follwowing tenants could not be retrieved:
Tenant Id: 539e8ab5-5bfa-44c8-b872-3dc8d1a124f8, Error: {"code":"SELF_SIGNED_CERT_IN_CHAIN"}

[PeterParker1234]

This is a serious issue which deserves attention

[x3nc0n]

I am also having this issue and have a Premiere case open on it.

[x3nc0n]

Subscriptions for the follwowing tenants could not be retrieved:
Tenant Id: , Error: {"code":"SELF_SIGNED_CERT_IN_CHAIN"}

I have imported my PKI certs, as we do TLS inspection, but still get this error.

[MRayermannMSFT]

Could y'all trying launching Storage Explorer from the command line, and when doing so, include a --ignore-certificate-errors flag. So for example:

.\StorageExplorer.exe --ignore-certificate-errors

And let me know if that helps you out.

[x3nc0n]

It works when I do that. Is there somewhere I can view the self-signed cert it's getting? I have imported my entire PKI and firewall certificate chains (we do inspection on the firewall, off a CA cert issued by one of my two Enterprise CAs, which are signed by the offline root.

[x3nc0n]

From Dev Tools errors:

self_cert_azurestorage.txt.txt

[MRayermannMSFT]

Unfortunately we don't know of a way to see the untrusted cert (and it has frustrated the heck out of us as well). I've been asking around Microsoft/the Electron community for help on this issue, and so far people have advised that we use the Electron Net module. Thing is, we can't do that right now because the Azure Storage library doesn't provide a way for us to change how they do network requests. So although we would get your sign in and subscriptions unblocked, you wouldn't be able to actually interact with Storage.

We're hoping that in the future it will be possible to change how the library makes requests, but until then, you either have to get lucky in finding the certs or use the flag (which is potentially unsafe, but I'll leave taking that risk up to you). Please let us know if you find a reliable way to discover the certs though, as we would love to share that method with other users!

And to clarify, you are saying the flag works yes?

[x3nc0n]

Yes, it does.

[x3nc0n]

Is there any list of URIs that are used to get that subscription data? I can add those to my inspection bypass list and see if that helps.

[MRayermannMSFT]

Here are the URLs that we talk to for getting subscriptions:

• Azure: https://management.azure.com/
• Azure Germany: https://management.microsoftazure.de/
• Azure US Govt: https://management.usgovcloudapi.net/
• Azure China: https://management.chinacloudapi.cn/

[MRayermannMSFT]

If adding those to your inspection by pass fixes the issue, then we can work on getting you the other URLs we talk to.

[x3nc0n]

Bypassing TLS inspection for management.azure.com did fix the issue.

Edit: why it still didn't work though I imported certificates is still unknown. Could you ask the team that does Storage Explorer if they have implemented HPKP? That might cause the error if Storage Explorer has the management.azure.com key pinned and doesn't use the certificates I imported except for accessing storage accounts.

[MRayermannMSFT]

I am from the team. 😄 As for HPKP, that is a term we haven't heard of before, so I'll need to do some digging into whether or not that is something we use. Based on what I'm reading here though, we probably don't. By default, Electron (the framework we are written on) uses NodeJS' networking stack. NodeJS does not look at your OS' cert store. Instead, it trusts a compile time defined list of certs. So whenever you import a cert, we add it to that list, and assuming you imported it correctly, then it should work.

In related news, I just found this library while looking for the link to NodeJS' cert list. I'll be investigating if it can unblock those of you in this situation.

[x3nc0n]

Basically you'd be including a whitelisted public certificate key or set of keys in the MSI for the app, and the app wouldn't trust anything else, even if "trusted" in the cert store (even if it's using NodeJS'). I have no further insight to NodeJS as I'm not a dev, but I do deal with stuff that doesn't use the OS cert store often enough.

Also, thanks for the link to that library. I have a dev friend that will love that for another project.

Edit: clarifying cert store

[MRayermannMSFT]

Ok ya, now that you're saying MSI, I can definitely say that HPKP is not something that we can implement/take advantage of. In the meantime, do you need any other URLs, or are you unblocked now? I would think you would need the storage endpoints, so let me know if you do.

[x3nc0n]

The storage endpoints are working fine. I think they were included in a Palo App-ID for Azure we use for bypassing TLS inspection; the management URI was not in that App-ID rule.

[MRayermannMSFT]

Awesome! I'll be leaving this issue open for the other 2 people involved to make sure they're unblocked, but feel free to come back and comment if this pops up again, or create a new issue for any bugs or feature requests you have.

[bplaats]

I did get passed the cert error with that cmd line switch

I now get

Subscriptions for the follwowing tenants could not be retrieved:

Tenant Id: 539e8ab5-5bfa-44c8-b872-3dc8d1a124f8, Error: {"code":"ETIMEDOUT","errno":"ETIMEDOUT","syscall":"connect","address":"52.224.105.172","port":443}

is port 445 required to be open or another nonstandard port? Even though the error says it timedout on 443 ?

thanks,
Brett

---

From: Matthew Rayermann [e-mail]
Sent: Monday, June 25, 2018 12:38 PM
To: Microsoft/AzureStorageExplorer
Cc: bplaats; Author
Subject: Re: [Microsoft/AzureStorageExplorer] Storage explorer not finding tenant (#335)

If adding those to your inspection by pass fixes the issue, then we can work on getting you the other URLs we talk to.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/AzureStorageExplorer/issues/335#issuecomment-400016435, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AlfTWDDh_TrDrukO5hLtF1dE1yPJmf2Bks5uARIFgaJpZM4UyBI3.

[MRayermannMSFT]

@bplaats , are you behind a proxy?

[bplaats]

No but only have port 443 open for now.

Sent from my mobile device, please excuse typos.

On Jun 27, 2018, at 12:11 PM, Matthew Rayermann <[email protected][e-mail]> wrote:

@bplaatshttps://github.com/bplaats , are you behind a proxy?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/AzureStorageExplorer/issues/335#issuecomment-400734741, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AlfTWCoDm27YgeTaEpooPLySYWbpt__gks5uA66kgaJpZM4UyBI3.

[sunilnandaeast]

hi any update on this issue.am also getting same issue.able to connect the storage blob from Visual studio but not working in storage explore.
"code":"ETIMEDOUT","errno":"ETIMEDOUT","syscall":"connect","address":"13.87.37.12","port":443}

[MRayermannMSFT]

Please refer to the troubleshooting guide for SSL cert related issues: https://docs.microsoft.com/en-us/azure/storage/common/storage-explorer-troubleshooting?tabs=Windows%2C1804#error-self-signed-certificate-in-certificate-chain-and-similar-errors

If anyone here is still having problems, please open a new issue. Thanks.