SSL/TLS connection issue troubleshooting guide
You may experience exceptions or errors when establishing TLS connections with Azure services. Exceptions are vary dramatically depending on the client and server types. A typical ones such as "Could not create SSL/TLS secure channel." "SSL Handshake Failed", etc. In this article we will discuss common causes of TLS related issue and troubleshooting steps.Service Bus - duplicate detection for partitioned messaging entity
Pre-requirements: Before we start, please read these document about Duplicate Detection, Partitioned queues and topics and Message Sessions From the above Pre-requirements, we learn the followings Enabling Duplicate detection helps to ensure that a duplicate message, which has the same message Id cannot be sent into a messaging entity during a specified time. Service Bus Partitions enable queues and topics or message entities to be partitioned across multiple message brokers and messaging stores. Enable partitioning the overall throughput will separate to different partition. Partition key can be used in some scenarios, such as sessions or transactions, require messages to be stored in a specific partition. Microsoft Service Bus Session enable joint and ordered handling of unbounded sequences of messages. There are two patterns of it , first out and request-response pattern. Any sender can create a session when submitting messages into a topic or queue by setting the SessionId property to some application-defined identifier that is unique to the session. So, from these above knowledges, we know that Azure Service Bus Queue and Topic/Subscription can enable for Duplicate Detection, Partitions and Sessions. But what’s the relationship between them?
Azure Service Bus | Receive Messages from DLQ for Queue/Subscription
Azure Service Bus queues and topic subscriptions provide a secondary subqueue, called a dead-letter queue(DLQ). The dead-letter queue need not to be explicitly created and can't be deleted or otherwise managed independent of the main entity. Azure Service Bus messaging overview - Azure Service Bus | Microsoft Docs Messages that can't be processed because of various reasons fall into DLQ. Below are few conditions where messages will fall into DLQ: 1. Not matching with the filter condition 2. TTL expired, header exceed 3. Quota exceed for header size 4. Max delivery count reached 5. Session enabled and sending messages without sessionID 6. Using more than 4 forward to Case: To receive DLQ messages from queue/subscription Pre-Requisites: 1. Service Bus namespace 2. Already created queue/subscription 3. Should have messages in DLQ either for queue/subscription 4. Service Bus Explorer We have multiple ways to receive messages from DLQ. Using Service Bus Explorer: Download the “Service Bus Explorer” from: https://github.com/paolosalvatori/ServiceBusExplorer Open service bus explorer and click File and connect it. From the drop down, select connection string and provide the connection string of the namespace level. Once it is successfully connected, you will see Service Bus Explorer shows the count of the DLQ message. In the below screenshot, there are 11 messages currently in the DLQ for the queue "ankitatest". To receive messages from DLQ through SB explorer, you need to click on that particular queue and then click on “Deadletter” tab then one dialogue box will pop up then you need to click on “Receive and Delete”. The default value is Top10 so top10 messages will be received from DLQ. The updated DLQ message count is now 1. Through C# Code: In the given screenshot, we have 12 messages in DLQ for queue and we wanted to receive them. I will run the below code which will receive the message from the mentioned queue. Once you run the code successfully, you will see the message ID in the console window as below. Now, check on SB explorer and you will see 1 message has been gone from DLQ. class Program { static void Main(string[] args) { RetrieveMessageFromDeadLetterForQueue(); RetrieveMessageFromDeadLetterForSubscription(); } public static void RetrieveMessageFromDeadLetterForQueue() { var receiverFactory = MessagingFactory.Create( "sb://<ServiceBusNamespaceName>.servicebus.windows.net/", new MessagingFactorySettings { TokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider("RootManageSharedAccessKey", "<NamespaceLevelKey>"), NetMessagingTransportSettings = { BatchFlushInterval = new TimeSpan(0, 0, 0) } }); string data = QueueClient.FormatDeadLetterPath("<QueueName>"); var receiver = receiverFactory.CreateMessageReceiver(data); receiver.OnMessageAsync( async message => { var body = message.GetBody<Stream>(); lock (Console.Out) { Console.WriteLine(message.MessageId); } await message.CompleteAsync(); }, new OnMessageOptions { AutoComplete = false, MaxConcurrentCalls = 1 }); } public static void RetrieveMessageFromDeadLetterForSubscription() { var receiverFactory = MessagingFactory.Create( "sb://<NS>.servicebus.windows.net/", new MessagingFactorySettings { TokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider("RootManageSharedAccessKey", "<NamespaceLevelSASKey>"), NetMessagingTransportSettings = { BatchFlushInterval = new TimeSpan(0, 0, 0) } }); string data = SubscriptionClient.FormatDeadLetterPath("<TopicName>", "<SubscriptionName>"); var receiver = receiverFactory.CreateMessageReceiver(data); receiver.OnMessageAsync( async message => { var body = message.GetBody<Stream>(); lock (Console.Out) { Console.WriteLine("Message ID :" + message.MessageId); } await message.CompleteAsync(); }, new OnMessageOptions { AutoComplete = false, MaxConcurrentCalls = 1 }); } }
Common causes of SSL/TLS connection issues and solutions
In the TLS connection common causes and troubleshooting guide (microsoft.com) and TLS connection common causes and troubleshooting guide (microsoft.com), the mechanism of establishing SSL/TLS and tools to troubleshoot SSL/TLS connection were introduced. In this article, I would like to introduce 3 common issues that may occur when establishing SSL/TLS connection and corresponding solutions for windows, Linux, .NET and Java. TLS version mismatch Cipher suite mismatch TLS certificate is not trusted TLS version mismatch Before we jump into solutions, let me introduce how TLS version is determined. As the dataflow introduced in the first session(https://techcommunity.microsoft.com/t5/azure-paas-blog/ssl-tls-connection-issue-troubleshooting-guide/ba-p/2108065), TLS connection is always started from client end, so it is client proposes a TLS version and server only finds out if server itself supports the client's TLS version. If the server supports the TLS version, then they can continue the conversation, if server does not support, the conversation is ended. Detection You may test with the tools introduced in this blog(TLS connection common causes and troubleshooting guide (microsoft.com)) to verify if TLS connection issue was caused by TLS version mismatch. If capturing network packet, you can also view TLS version specified in Client Hello. If connection terminated without Server Hello, it could be either TLS version mismatch or Ciphersuite mismatch. Solution Different types of clients have their own mechanism to determine TLS version. For example, Web browsers - IE, Edge, Chrome, Firefox have their own set of TLS versions. Applications have their own library to define TLS version. Operating system level like windows also supports to define TLS version. Web browser In the latest Edge and Chrome, TLS 1.0 and TLS 1.1 are deprecated. TLS 1.2 is the default TLS version for these 2 browsers. Below are the steps of setting TLS version in Internet Explorer and Firefox and are working in Window 10. Internet Explorer Search Internet Options Find the setting in the Advanced tab. Firefox Open Firefox, type about:config in the address bar. Type tls in the search bar, find the setting of security.tls.version.min and security.tls.version.max. The value is the range of supported tls version. 1 is for tls 1.0, 2 is for tls 1.1, 3 is for tls 1.2, 4 is for tls 1.3. Windows System Different windows OS versions have different default TLS versions. The default TLS version can be override by adding/editing DWORD registry values ‘Enabled’ and ‘DisabledByDefault’. These registry values are configured separately for the protocol client and server roles under the registry subkeys named using the following format: <SSL/TLS/DTLS> <major version number>.<minor version number><Client\Server> For example, below is the registry paths with version-specific subkeys: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client For the details, please refer to Transport Layer Security (TLS) registry settings | Microsoft Learn. Application that running with .NET framework The application uses OS level configuration by default. For a quick test for http requests, you can add the below line to specify the TLS version in your application before TLS connection is established. To be on a safer end, you may define it in the beginning of the project. ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 Above can be used as a quick test to verify the problem, it is always recommended to follow below document for best practices. https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls Java Application For the Java application which uses Apache HttpClient to communicate with HTTP server, you may check link How to Set TLS Version in Apache HttpClient | Baeldung about how to set TLS version in code. Cipher suite mismatch Like TLS version mismatch, CipherSuite mismatch can also be tested with the tools that introduced in previous article. Detection In the network packet, the connection is terminated after Client Hello, so if you do not see a Server Hello packet, that indicates either TLS version mismatch or ciphersuite mismatch. If server is supported public access, you can also test using SSLLab(https://www.ssllabs.com/ssltest/analyze.html) to detect all supported CipherSuite. Solution From the process of establishing SSL/TLS connections, the server has final decision of choosing which CipherSuite in the communication. Different Windows OS versions support different TLS CipherSuite and priority order. For the supported CipherSuite, please refer to Cipher Suites in TLS/SSL (Schannel SSP) - Win32 apps | Microsoft Learn for details. If a service is hosted in Windows OS. the default order could be override by below group policy to affect the logic of choosing CipherSuite to communicate. The steps are working in the Windows Server 2019. Edit group policy -> Computer Configuration > Administrative Templates > Network > SSL Configuration Settings -> SSL Cipher Suite Order. Enable the configured with the priority list for all cipher suites you want. The CipherSuites can be manipulated by command as well. Please refer to TLS Module | Microsoft Learn for details. TLS certificate is not trusted Detection Access the url from web browser. It does not matter if the page can be loaded or not. Before loading anything from the remote server, web browser tries to establish TLS connection. If you see the error below returned, it means certificate is not trusted on current machine. Solution To resolve this issue, we need to add the CA certificate into client trusted root store. The CA certificate can be got from web browser. Click warning icon -> the warning of ‘isn’t secure’ in the browser. Click ‘show certificate’ button. Export the certificate. Import the exported crt file into client system. Windows Manage computer certificates. Trusted Root Certification Authorities -> Certificates -> All Tasks -> Import. Select the exported crt file with other default setting. Ubuntu Below command is used to check current trust CA information in the system. awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt If you did not see desired CA in the result, the commands below are used to add new CA certificates. $ sudo cp <exported crt file> /usr/local/share/ca-certificates $ sudo update-ca-certificates RedHat/CentOS Below command is used to check current trust CA information in the system. awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem If you did not see desired CA in the result, the commands below are used to add new CA certificates. sudo cp <exported crt file> /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust Java The JVM uses a trust store which contains certificates of well-known certification authorities. The trust store on the machine may not contain the new certificates that we recently started using. If this is the case, then the Java application would receive SSL failures when trying to access the storage endpoint. The errors would look like the following: Exception in thread "main" java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at org.example.App.main(App.java:54) Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:130) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:371) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:309) Run the below command to import the crt file to JVM cert store. The command is working in the JDK 19.0.2. keytool -importcert -alias <alias> -keystore "<JAVA_HOME>/lib/security/cacerts" -storepass changeit -file <crt_file> Below command is used to export current certificates information in the JVM cert store. keytool -keystore " <JAVA_HOME>\lib\security\cacerts" -list -storepass changeit > cert.txt The certificate will be displayed in the cert.txt file if it was imported successfully.
Bridging Connectivity: Exploring Azure Relay Bridge (azbridge)
Introduction to Secure Remote Access with Azure Relay and Azbridge In modern IT environments, securely accessing on-premises resources from remote locations is a common challenge. Traditional methods, such as setting up VPNs, often require complex configurations and can introduce significant overhead. For organizations seeking a more streamlined solution, Azure Relay, combined with the open-source tool Azure Relay Bridge (azbridge), offers an efficient way to establish secure, direct connections without the need for VPNs. Azbridge leverages Azure Relay to create TCP, UDP, HTTP, and Unix Socket tunnels, enabling secure traversal through NATs and firewalls using only outbound HTTPS (443) connectivity. This makes it ideal for connecting remote clients to on-premises resources, such as Remote Desktop Protocol (RDP) sessions, without exposing them to the public internet. While Azure Relay is fully supported by Microsoft, it’s important to note that azbridge is an open-source tool and is not covered by Microsoft support. Users can seek assistance for Azure Relay, but azbridge-specific issues should be reported directly on its repository, where response times may vary. In this guide, we’ll walk through the setup process for using azbridge with Azure Relay to create an RDP connection. You’ll learn how to configure a Hybrid Connection in Azure, customize client and server configuration files, and run azbridge as a service across different operating systems. Example Use Case for AZBridge Azbridge enables secure Remote Desktop Protocol (RDP) connections by allowing users to expose a network-isolated socket that can be accessed from an entirely separate network. This approach provides secure, remote access to on-premises resources—such as RDP, databases, or web servers—without the complexity of setting up a VPN, making it ideal for users needing isolated, controlled access across network boundaries. Using Azure Relay, azbridge creates direct tunnels that bypass NATs and firewalls without requiring extensive network configuration. This setup not only simplifies access but also enhances security by enabling RDP connections without exposing sessions to the public internet, thereby reducing potential risks. In many situations, users need access to specific resource endpoints rather than an entire network. Azbridge is especially valuable in scenarios such as accessing billing databases in franchise locations, integrating with secure test systems, or making web service calls to protected applications. By leveraging Azure Relay, azbridge provides a controlled way to reach exactly the endpoint you need without exposing the entire network that it is in. Additionally, azbridge is a cost-effective solution, avoiding traditional VPN licensing fees and charging only for active Azure Relay connections. Because it relies on outbound HTTPS (443), azbridge works seamlessly across restrictive networks, allowing connections without additional firewall adjustments. For developers and IT admins, azbridge provides quick, secure access to on-premises machines from any location, serving as a fast, flexible alternative to traditional VPNs for endpoint-specific connectivity. The diagram above demonstrates how azbridge enables a secure Remote Desktop Protocol (RDP) connection across network boundaries using Azure Relay. In this setup, On-Premises Network A contains the client machine, where azbridge (labeled as "Relay Bridge") is installed. This client is seeking to establish an RDP connection to a remote machine located in a different network, On-Premises Network B. Azure Relay acts as a secure intermediary between the two networks, facilitating the connection without exposing either network to the public internet. By creating a direct tunnel that bypasses NATs and firewalls, Azure Relay allows the client in Network A to communicate with the endpoint in Network B safely. On-Premises Network B contains the target machine with azbridge installed, which is also labeled as "Relay Bridge." This machine hosts the specific endpoint (such as an RDP server) that the client in Network A is trying to access. Through this configuration, azbridge in Network A connects via Azure Relay to reach the endpoint in Network B without requiring a VPN. Only the designated RDP endpoint is exposed to the connection, while the rest of Network B remains isolated and secure. This approach provides a secure, controlled RDP connection across networks, allowing remote access to on-premises resources without exposing the entire network. Prerequisites and Initial Setup To get started, you will first need to set up an Azure Relay Hybrid Connection the basic instructions for doing so are provided below. Presuming you have already gained the Entra id login credentials for Azure, set up some environment variables in your environment: export NAMESPACE=<your_namespace_name> # e.g., mynamespacename export LOCATION=<location_name> # e.g., eastus2 export RELAYNAME=<your_relay_name> # e.g., azbridge Next, use the specified namespace and location to create a resource group: az group create --name $NAMESPACE --location $LOCATION In your resource group, create an azure relay namespace for this example the resource group and the azure relay namespace are identically named: az relay namespace create -g $NAMESPACE --name $NAMESPACE Create a new Hybrid Connection in your Azure Relay namespace: az relay hyco create -g $NAMESPACE --namespace-name $NAMESPACE --name $RELAYNAME Create an authorization rule with your Hybrid Connection, allow send and listen permissions on the authorization rule: az relay hyco authorization-rule create -g $NAMESPACE --namespace-name $NAMESPACE --hybrid-connection-name $RELAYNAME -n sendlisten --rights Send Listen Retrieve the primaryConnectionString for the authorization rule generated. This will be needed for the azbridge configuration files: az relay hyco authorization-rule keys list -g $NAMESPACE --namespace-name $NAMESPACE -n sendlisten --hybrid-connection-name $RELAYNAME --out tsv --query "primaryConnectionString" Setting Up RDP with Azure Relay and Azbridge For this example, we’ll be using the Windows operating system. Install the MSI package on both your client machine and the remote RDP machine. You can download the MSI package for installation from Azure Relay Bridge Releases on GitHub Client Machine Configuration On the client machine, generate a client_config.yaml file with the following contents: LocalForward : - BindAddress: 127.1.0.2 BindPort: 13389 PortName: rdp RelayName: <<RELAYNAME>> ConnectionString: <<primaryConnectionString>> LogLevel: INFO Bind Address: Source address of outbound, forwarding connections, in this example, 127.1.0.2 is used to create a local endpoint on the client machine without affecting 127.0.0.1 BindPort: TCP port mapped to the hybrid connection 13389 is used in this case because Windows does not allow listening on port 3389 on any address. PortName: Primarily used for internal configuration within azbridge to label and map the local and remote ports consistently. This label helps identify the specific purpose of each connection. RelayName: Hybrid Connection on Azure Relay that will be used for this connection ConnectionString: primaryConnectionString created for the Azure Relay Hybrid Connection with Send and Listen permissions. To start the client connection, open up a command prompt and specify the client_config.yml file that was generated. azbridge -f client_config.yml Remote RDP Machine Configuration On the rdp machine, generate a server_config.yml file with the following contents: RemoteForward : - RelayName: <<RELAYNAME>> Host: localhost PortName: rdp HostPort: 3389 ConnectionString: <<primaryConnectionString>> LogLevel: INFO Similar to the Client setup, only this file sets up a remote forwarder that binds the hybrid connection with logical port "rdp" to the Windows RDP endpoint on "localhost", port 3389. To start the local RDP connection, open up a command prompt and specify the server_config.yml file that was generated. azbridge -f server_config.yml Connect via RDP On your client machine, open up a Remote Desktop Connection to your Remote RDP host. For this connection, you will use the 127.1.0.2:13389 specified in your client_config.yml:
Steps to upgrade control plane API references for Azure Service Bus, Event Hubs and Relay
On 30 September 2026, Azure Resource Manager control plane APIs 2014-09-01, 2015-08-01, and 2016-07-01 will be retired. Migrate to the latest control plane API version by that date to avoid potential service outages in Azure Service Bus, Event Hubs, and Relay. The latest API for control plane operations, version 2021-11-01, offers feature updates and performance improvements to make your applications more resilient.
