A vulnerability was detected on Azure SQL server on port 443 that tls1.0 and 1.1 are enabled. But we already disabled and configured a minimul TLS version in configuration

We disabled and configured a minimum TLS version of 1.2 in configuration of Azure SQL server. But a vulnerability was detected on Azure SQL server on port 443 that tls1.0 and 1.1 are enabled.

The vulnerabilities were not detected on port 1433 but only on 443. Does the configuration on Azure portal not apply to all the ports. If yes, could this be an issue and has to be fixed by Azure?

  1. Erland Sommarskog 134.7K Reputation points • MVP • Volunteer Moderator

    Port 443 is https. I don't know exactly what the relation is to Azure SQL Server, but there is certainly to SQL traffic on that port.

Sign in to comment

3 answers

  1. Pilladi Padma Sai Manisha 10,190 Reputation points • Microsoft External Staff • Moderator

    Hi Singireddy Lohith Reddy,
    For Azure SQL Database, the Minimum TLS version setting applies to SQL client connectivity. Setting the minimum TLS version to 1.2 is the correct way to ensure database connections do not use TLS 1.0 or TLS 1.1.

    If a scanner is still reporting a TLS-related finding, we should first confirm whether the alert is associated with the SQL client connection path or with a Microsoft-managed platform endpoint.

    In many cases, these findings should be reviewed against the exact rule or validation logic used by the scanning tool. If the database connection path is already enforcing TLS 1.2, then the result may reflect how the external scanner interprets the endpoint rather than an Azure SQL configuration issue.

    Please verify the following:

    • The Azure SQL server is configured with Minimum TLS version = 1.2.
    • Applications are connecting successfully using TLS 1.2 on the SQL connection path.
    • The reported finding matches the specific Azure SQL vulnerability assessment rule or connectivity validation being tested.

    Microsoft documentation for reference:

    If the issue still appears after confirming TLS 1.2 enforcement on the database connection path, further validation may be required with Microsoft Support or the scanner vendor to determine whether the result is related to platform-managed endpoints or scanner interpretation.

    1. Pilladi Padma Sai Manisha 10,190 Reputation points • Microsoft External Staff • Moderator

      Hi
      Following up to see if the below answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.

    2. Singireddy Lohith Reddy 0 Reputation points

      Hi @Pilladi Padma Sai Manisha ,

      As reported in the request, the vulnerability was not detected on the SQL service but on port 443/80. Is this something expected when a scan is run on Azure SQL Server name.

    3. Pilladi Padma Sai Manisha 10,190 Reputation points • Microsoft External Staff • Moderator

      Hi @Singireddy Lohith Reddy
      Yes, this can happen depending on what exactly the vulnerability scanner is testing.

      The Minimum TLS version setting on Azure SQL Server only applies to SQL client connections on port 1433. It does not control every endpoint that may respond when the Azure SQL Server name is scanned.

      If the vulnerability is being reported only on ports 443 or 80 and not on port 1433, the scan is most likely hitting a Microsoft-managed HTTP/HTTPS endpoint rather than the actual SQL service.

      In that case, it does not necessarily indicate an issue with your Azure SQL Server configuration. Customers cannot directly manage or disable TLS protocols on those Microsoft-managed endpoints.

      It would be helpful to verify:

      • The exact Azure SQL Server FQDN that was scanned.
      • Whether the finding is reported only for ports 80/443 and not for port 1433.
      • The endpoint or IP address the scanner is actually reaching.

      If TLS 1.2 is already enforced for SQL connectivity on port 1433 and the finding is limited to ports 80/443, this is likely related to a platform-managed endpoint or the way the scanner is interpreting the results, rather than a configuration issue with Azure SQL itself.

    4. Pilladi Padma Sai Manisha 10,190 Reputation points • Microsoft External Staff • Moderator

      Hi @Singireddy Lohith Reddy
      Could you please review above response and please let us know if you have any queries.

    Sign in to comment
  2. Alberto Morillo 35,506 Reputation points • MVP • Volunteer Moderator

    Azure SQL Database has a shared Control Plane due to which Azure cannot selectively turn off specific version of TLS or weak cipher suites. When Azure customers run scanners against Azure infrastructure, they will see these flagged and it is by design. Vulnerability scanners will show something like:

    • TLS 1.0 FOUND
    • TLS 1.1 FOUND
    • TLS 1.2 with Weak Cipher Suite (SWEET32).

    Azure initially announced deprecation of TLS < 1.2 by October 31st 2024 but Azure extended support for TLS 1.0 and TLS 1.1 to August 31, 2025 as you can read here. That eliminated majority of the weak ciphers. After August 31, 2025 TLS 1.2 is required to connect to Azure SQL. Additionally, Azure is working on adding TLS 1.3 to Minimal TLS Version so customers can use it to overcome Sweet32 vulnerability but there is no official ETA.

    As of today, Azure infrastructure does support TLS 1.3 connectivity.

    Hope this helps.

    0 comments No comments
    Sign in to comment

  3. AI answer

    The minimum TLS version setting on an Azure SQL logical server applies to SQL client connections to the database service (for example, on port 1433) and is enforced at the application layer of the SQL endpoint. It does not change how generic HTTPS/TLS on port 443 is exposed or probed at the protocol level.

    Key points from the documented behavior:

    1. Minimum TLS version is enforced at the application layer
      • For Azure SQL Database and Azure Synapse, the minimum TLS version is enforced by the service, not by the raw TCP/TLS listener.
      • Tools that scan or probe TLS at the protocol level against the endpoint can still report support for older TLS versions even when the service enforces a higher minimum at the application layer:
        • “When you configure a minimum TLS version, that minimum version is enforced at the application layer. Tools that attempt to determine TLS support at the protocol layer might return TLS versions in addition to the minimum required version when run directly against the managed instance endpoint.”
        • The same note exists for Synapse: “The minimum TLS version is enforced at the application layer. Tools that attempt to determine TLS support at the protocol layer might return TLS versions in addition to the minimum required version when run directly against the endpoint.”
    2. What the minimum TLS version actually guarantees
      • For Azure SQL Database:
        • “Choosing TLS 1.2 means only connections with TLS 1.2 or TLS 1.3 are accepted, while connections using TLS 1.1 or lower are rejected.”
        • “Currently, the lowest minimum TLS version supported by Azure SQL Database is TLS 1.2… TLS 1.0 and 1.1 are retired and no longer available.”
      • For Azure SQL Managed Instance:
        • “Setting Minimum TLS version to 1.2 is currently enforced… Only connections using TLS 1.2 or above are accepted.”
        • “TLS 1.0 and 1.1 is retired and no longer available.”
      • If a client attempts to use a TLS version lower than the configured minimum, authentication fails with:
        • Error 47072 Login failed with invalid TLS version
    3. Why scanners still report TLS 1.0/1.1 on 443
      • Because enforcement is at the SQL application layer, a generic TLS scanner that only negotiates TLS at the protocol level on port 443 (or 1433) can see lower protocol versions as “supported,” even though SQL login attempts using those versions are rejected.
      • This can lead to “false positive” vulnerability reports when the service is already enforcing TLS 1.2+.
    4. Whether this needs to be “fixed”
      • From the service perspective, TLS 1.0 and 1.1 are already retired and not usable for successful SQL authentication when the minimum TLS version is set to 1.2.
      • If the logical server is configured with minimum TLS 1.2 and clients connect with TLS 1.2 or higher, no additional action is required according to the FAQ:
        • “If your server or database is already configured with minimum TLS 1.2… and connecting with 1.2, no action is required.”
      • The discrepancy is in how external scanners interpret protocol-level capabilities versus application-layer enforcement, not in the SQL configuration itself.

    In practice, this means:

    • The configuration in the Azure portal does apply to SQL client connections (including those that ultimately use 1433), and TLS 1.0/1.1 cannot be used to successfully authenticate.
    • A vulnerability report that only looks at protocol-level negotiation on port 443 can be a false positive with respect to actual SQL data-plane risk.
    • If further validation is needed, use the Azure portal metrics or SQL audit logs to confirm that no successful connections are using TLS 1.0/1.1.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer