starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Azure Cloud Shell Could not connect to Azure behind Corp Proxy #6426

New Issue
Closed
opened 2026-01-31 00:38:25 +00:00 by claunia · 4 comments
claunia commented 2026-01-31 00:38:25 +00:00
Owner
Copy Link

Originally created by @Ugenx on GitHub (Feb 13, 2020).

Environment

Windows build number: 10.0.18363.0
Windows Terminal version (if applicable): v0.9.433.0

Any other software?

Steps to reproduce

Add a new "Azure Cloud Shell" tab to your terminal instance.

Expected behavior

A prompt should appear asking to authenticate with Azure.

Actual behavior

The message "Could not connect to Azure. You may not have internet or the server might be down." appears immediately in the new tab. Fiddler only shows a single outgoing SSL initiation request to login.microsoftonline.com with a 200 response and no followup communication.

I recently had to update the cacert bundle for the azure cli located in C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\certifi\cacert.pem to include our corp proxy certificate which restored its functionality. Is there something similar here or should the terminal be using the windows store?

Originally created by @Ugenx on GitHub (Feb 13, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows build number: 10.0.18363.0 Windows Terminal version (if applicable): v0.9.433.0 Any other software? ``` # Steps to reproduce Add a new "Azure Cloud Shell" tab to your terminal instance. # Expected behavior A prompt should appear asking to authenticate with Azure. # Actual behavior The message "Could not connect to Azure. You may not have internet or the server might be down." appears immediately in the new tab. Fiddler only shows a single outgoing SSL initiation request to login.microsoftonline.com with a 200 response and no followup communication. I recently had to update the cacert bundle for the azure cli located in C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\certifi\cacert.pem to include our corp proxy certificate which restored its functionality. Is there something similar here or should the terminal be using the windows store?
claunia commented 2026-01-31 00:38:26 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 14, 2020):

Terminal should be using the Windows certificate store; is your corp proxy cert part of the Trusted Roots (at either User or System level?)

I believe the HTTP library we're using does use the WinHTTP APIs.

@DHowett-MSFT commented on GitHub (Feb 14, 2020): Terminal should be using the Windows certificate store; is your corp proxy cert part of the Trusted Roots (at either User or System level?) I believe the HTTP library we're using _does_ use the WinHTTP APIs.
claunia commented 2026-01-31 00:38:27 +00:00
Author
Owner
Copy Link

@Ugenx commented on GitHub (Feb 14, 2020):

My corp cert is definitely in both user and machine Trusted Root stores (confirmed just now). Does cloud shell function when running from source? Perhaps I could get some additional context on the connection error that way?

@Ugenx commented on GitHub (Feb 14, 2020): My corp cert is definitely in both user and machine Trusted Root stores (confirmed just now). Does cloud shell function when running from source? Perhaps I could get some additional context on the connection error that way?
claunia commented 2026-01-31 00:38:27 +00:00
Author
Owner
Copy Link

@Ugenx commented on GitHub (Feb 14, 2020):

Pulled source to attempt debugging my specific version (v0.9.433.0), followed the instructions in the readme to restore git submodules via git submodule update --init --recursive, opened OpenConsole.sln in VS2019 Community V16.4.4, installed the required desktop development components, re-opened the solution and when right-clicking on CascadiaPackage -> Properties I am met with the error:

"An error occurred trying to load the project properties window. Close the window and try again.
The project configuration "Debug|x86" was not found in the project manifest."

Same problem in master branch. Tried searching issues for an existing bug report of this scenario and found nothing. Should I open one or am I missing something obvious here?

@Ugenx commented on GitHub (Feb 14, 2020): Pulled source to attempt debugging my specific version (v0.9.433.0), followed the instructions in the readme to restore git submodules via `git submodule update --init --recursive`, opened OpenConsole.sln in VS2019 Community V16.4.4, installed the required desktop development components, re-opened the solution and when right-clicking on CascadiaPackage -> Properties I am met with the error: "An error occurred trying to load the project properties window. Close the window and try again. The project configuration "Debug|x86" was not found in the project manifest." Same problem in master branch. Tried searching issues for an existing bug report of this scenario and found nothing. Should I open one or am I missing something obvious here?
claunia commented 2026-01-31 00:38:27 +00:00
Author
Owner
Copy Link

@TpSr52 commented on GitHub (Mar 7, 2020):

@Ugenx I just bumped into it also. I changed the platform in the top menu from x86 to x64 and then I successfully opened the "CascadiaPackage" properties. You should try it also.

It's happening because the x86 platform isn't defined in the project configuration and I think the main reason is that the "CascadiaPackage" debug project configuration for the x86 platform isn't configured deployable.

@TpSr52 commented on GitHub (Mar 7, 2020): @Ugenx I just bumped into it also. I changed the platform in the top menu from x86 to x64 and then I successfully opened the "CascadiaPackage" properties. You should try it also. It's happening because the x86 platform isn't defined in the project configuration and I think the main reason is that the "CascadiaPackage" debug project configuration for the x86 platform isn't configured deployable.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-AzureShell In-PR Issue-Bug Needs-Attention Needs-Tag-Fix Priority-2 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#6426
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?