Azure Connected Machine Agent Extensions will not install - Error: context: library has no ciphers (SSL routines) [asio.ssl:167772321]

Hello Devon Deweert, 

Thank you for reaching out to the Microsoft Q&A forum. 

We understand your Arc agent is failing to negotiate any cipher suites when it calls out to the metadata service (“library has no ciphers”). That usually means SChannel on your Windows box doesn’t have any of the recommended TLS 1.2/1.3 ciphers enabled, so the agent literally can’t speak SSL/TLS.

Here’s what you can try:

Upgrade the Arc agent • Make sure you’re running the latest Connected Machine agent (≥ 1.56). TLS 1.3 support and enforcement of the recommended cipher list lands in that release. azcmagent version If you’re not on 1.56+, download/install the latest from Agent Release Notes.

Confirm which ciphers are enabled

Open PowerShell as admin and run: Get-TlsCipherSuite | Format-List Name You should see at least one of these TLS 1.3 suites:

• TLS_AES_256_GCM_SHA384

• TLS_AES_128_GCM_SHA256 …or at least one of these TLS 1.2 suites:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

In your snippet I only saw ECDSA ciphers, so nobody for the agent to use!

Enable the missing ciphers

• If you don’t see the TLS 1.2 RSA suites, you need to inject them via Group Policy or registry.

– Group Policy: Computer Configuration → Admin Templates → Network → SSL Configuration Settings → SSL Cipher Suite Order. Paste in the Microsoft-recommended cipher list (see doc below). – Registry: update HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\Functions with the same list.

Reboot and retry After you enable at least one of the above suites, reboot your server, then try installing/running your extension again.

Verify connectivity one more time azcmagent check --location “westus2”

If you still see “library has no ciphers,” double-check that no GPOs or security baselines are stripping out the RSA ciphers, and confirm you’re on a supported Windows Server version (2012 R2 or newer).

— Hope that does the trick! Let me know if you need any more help.

Reference docs

• Windows TLS configuration issues: https://learn.microsoft.com/azure/azure-arc/servers/troubleshoot-networking#windows-tls-configuration-issues

• Agent release notes (for v1.56+): https://learn.microsoft.com/azure/azure-arc/servers/agent-release-notes

• Network requirements: https://learn.microsoft.com/azure/azure-arc/servers/network-requirements

• Troubleshoot VM extensions: https://learn.microsoft.com/azure/azure-arc/servers/troubleshoot-vm-extensions

 

Hello @Siva shunmugam Nadessin ,

Thanks for the help, I'm sorry to say that it was just my mistake in not copying the correct TLS cipher suites, the full list does contain those RSA suites, they are #5 and 6 in the full list as seen below.

PS C:\> Get-TlsCipherSuite | Format-List Name
Name : TLS_AES_256_GCM_SHA384
Name : TLS_AES_128_GCM_SHA256
Name : TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Name : TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Name : TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Name : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Name : TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Name : TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Name : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Name : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Name : TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Name : TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
Name : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Name : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Name : TLS_RSA_WITH_AES_256_GCM_SHA384
Name : TLS_RSA_WITH_AES_128_GCM_SHA256
Name : TLS_RSA_WITH_AES_256_CBC_SHA256
Name : TLS_RSA_WITH_AES_128_CBC_SHA256
Name : TLS_RSA_WITH_AES_256_CBC_SHA
Name : TLS_RSA_WITH_AES_128_CBC_SHA
Name : TLS_RSA_WITH_NULL_SHA256
Name : TLS_RSA_WITH_NULL_SHA
Name : TLS_PSK_WITH_AES_256_GCM_SHA384
Name : TLS_PSK_WITH_AES_128_GCM_SHA256
Name : TLS_PSK_WITH_AES_256_CBC_SHA384
Name : TLS_PSK_WITH_AES_128_CBC_SHA256
Name : TLS_PSK_WITH_NULL_SHA384
Name : TLS_PSK_WITH_NULL_SHA256

I have updated the GPO with the two TLS 1.2 suites moved up to position #3 and #4 now. I also confirmed the GPO is applied, the applied GPO is the only one affecting the cipher suites in general, and the registry also contains all the correct cipher suites.

Reboot still has the same issue in the logs, and connectivity is the same as in my original post.

PS C:\>azcmagent.exe version
azcmagent version  1.62.03365.2847

Agent version is up to date (it better be after I've re-installed it so many times now :P), and the server is running Windows Server 2025 Datacenter : 10.0.26100.32522

Hello Devon Deweert

When investigated our server does have the required Azure Arc (azcmagent) cipher suites enabled, including the two TLS 1.2 RSA ECDHE suites (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) at positions #5 and #6.

So if you’re still seeing the Arc error like __“context: library has no ciphers__the issue is usually not “missing suites” anymore, but how Windows is being told to use suites during handshake.

Microsoft states that starting with Connected Machine agent v1.56+, Windows machines must have at least one of these sets enabled:

• TLS 1.3: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256
• TLS 1.2: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [Troublesho...soft Learn | Learn.Microsoft.com], [Connected...soft Learn | Learn.Microsoft.com]

Your output contains these.

Why it still fails: custom SSL Cipher Suite Order can block negotiation

When you configure “SSL Cipher Suite Order” by GPO, Windows treats it as an allow-list for Schannel negotiation: suites not effectively usable in that policy context can lead to handshake failures, and changes only take effect after reboot.

Also, Azure Arc had a known incident after agent 1.56 where strict cipher handling exposed misconfigurations in OS cipher policies; Microsoft’s mitigation guidance was to follow the TLS/cipher configuration docs.

Key takeaway: even if Get-TlsCipherSuite shows the suites, your GPO cipher ordering policy can still cause the agent’s TLS negotiation to fail.

The  Recommended Solution (most reliable): revert to Windows Server 2025 defaults

Windows Server 2025 already ships with modern defaults, and your output matches the documented default order (TLS 1.3 first, then TLS 1.2 ECDHE, etc.).

Step 1 — Set the GPO to Not Configured

In Group Policy: Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order

Set it to:

Not Configured

This forces Windows to use its default cipher configuration (which includes the Arc-required suites on Server 2025).

Step 2 — Reboot (required for cipher order changes)

Microsoft notes the cipher order change takes effect on the next boot.

Step 3 — Re-test Arc connectivity

After reboot, validate the agent is still on a supported/new release (you have 1.62, good) and that the TLS requirement is satisfied (per docs

Alternate Solution (if you must enforce cipher order by GPO)

If your security baseline requires the SSL Cipher Suite Order policy to stay enabled, then configure it to include at minimum the suites Microsoft calls out for Arc:

TLS 1.3

• TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256

TLS 1.2

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

And ensure the policy list is in the exact, strict format Microsoft describes (comma-delimited list, length constraints, and applied on reboot). 

Practical recommendation: don’t “move up #3/#4” by inserting just two suites; instead, make sure the final GPO list includes these four suites exactly, then reboot. 

Don’t skip this: confirm Arc endpoint requirements (even if “connectivity looks fine”)

Microsoft’s Arc requirements include specific outbound endpoints and TLS guidance; if a network middlebox is doing TLS interception or limiting TLS versions, Arc can still fail even when DNS resolves. Review the Arc network requirements and ensure TLS 1.2/1.3 are being used. 

   Quick “do this now” checklist (minimal disruption)

1. Temporarily set SSL Cipher Suite Order GPO → Not Configured
2. Reboot (cipher order applies after reboot)
3. Confirm Get-TlsCipherSuite still shows the TLS 1.2 RSA ECDHE suites and TLS 1.3 AES suites
4. Recheck Arc connectivity/agent behavior (this aligns with Arc troubleshooting guidance for TLS issues) 

If it still fails after reverting to defaults

At that point, the next most common cause is TLS interception / proxy behavior or endpoint restrictions, because the cipher requirement would be satisfied and the OS defaults are known-good on Server 2025. The Arc network requirements doc is the authoritative checklist for that stage.

 

 

 

Devon Deweert, Just checking in to see if the solution shared above help you to resolve your issue. please reach out to us If you have any further questions.

If the answer was helpful, kindly Accept Answer & and Up-vote this can be beneficial to other community members.

Thanks

Hello @Siva shunmugam Nadessin ,

Sorry, no this didn't help me, do you have any in depth knowledge that can help me to diagnose and fix this issue?

Thanks,
Devon