Connect to Azure SQL with certificate validation instead of disabling it

[paolosalvatori]

Motivation

The sample connected to Azure SQL with TrustServerCertificate=yes, which keeps the connection encrypted but turns certificate validation off. That was a workaround for LocalStack for Azure, where the SQL endpoint used to present a self-signed certificate that no CA chain could validate, and the sample's own comment said so: "tells the ODBC driver to accept self-signed certificates without verification".

Two things make it unnecessary now. LocalStack for Azure serves a publicly trusted certificate for the host name it returns in fullyQualifiedDomainName, so a client with default settings validates it, and Microsoft's guidance is explicit that disabling validation is the option of last resort: "Install a certificate on the server that the client trusts. This option is the recommended one, and it's the only one that keeps both encryption and validation" (ODBC driver version differences).

Leaving the keyword in place also taught the wrong habit: a reader copying this sample into an application would carry an adversary-in-the-middle exposure into production, for no benefit.

Fixes SMF-898

Changes

TrustServerCertificate is removed from the connection string the application builds, rather than set to no. Its default is already no in ODBC Driver 18, so writing the default value only adds noise; the keyword belongs in a connection string when you deviate from the default. Encrypt=yes stays explicit, because that default does differ between driver 17 and 18.

The same keyword is removed from the connection string deploy.sh stores in Key Vault, since that is the value the application reads and the one a reader is most likely to copy.

The code comment now says what the absence means, and when you would still need the keyword: if LocalStack cannot download its public certificate (for example with SKIP_SSL_CERT_DOWNLOAD=1), the server presents a certificate issued by the LocalStack root certificate authority, and a client then needs that authority installed or TrustServerCertificate=yes.

Tests

The sample is otherwise unchanged and was deployed end to end on both targets.

Real Azure (az cloud show reporting AzureCloud, invented prefix, resource group deleted afterwards):

• deploy.sh exit 0, validate.sh exit 0.
• https://<app>.azurewebsites.net returned HTTP 200 with the application's own page, <title>Vacation Planner</title>, and 9 table cells rendered from the Azure SQL database.

LocalStack for Azure (emulator started with RUNTIME_COMPONENTS=azure, azlocal start-interception):

• deploy.sh exit 0, validate.sh exit 0.
• http://local-webapp-test.azurewebsites.azure.localhost.localstack.cloud:4566 returned HTTP 200 with the same page and the same 9 cells.

The first run of this check was rejected on purpose: HTTP 200 came from the App Service default welcome page while the site was still warming up, which proves nothing about the database. The runs above wait for the application's own title before asserting.

The certificate the emulator serves for a SQL host was also inspected directly: issuer=C=US, O=Google Trust Services, CN=WR1, a public authority.

🤖 Generated with Claude Code

[Copilot]

🔵 Needs a closer look

Remove -C from the remaining sqlcmd calls so deployment consistently validates certificates.

Pull request overview

Updates the Python Azure SQL sample to use encrypted connections with server certificate validation.

Changes:

• Removes TrustServerCertificate=yes from runtime and Key Vault connection strings.
• Documents certificate validation and the LocalStack fallback.
• Retains explicit encryption.

File summaries

File	Summary
samples/web-app-sql-database/python/src/database.py	Uses default certificate validation and documents the connection behavior.
samples/web-app-sql-database/python/scripts/deploy.sh	Removes the bypass from the Key Vault string, but earlier sqlcmd calls still use -C.

Review details

Suppressed comments (1)

samples/web-app-sql-database/python/scripts/deploy.sh:363

• This changes the Key Vault connection string to validate certificates, but every sqlcmd call earlier in this same deployment script still uses -N -C; -C explicitly trusts the server certificate without validating it. The setup, schema, and seed operations therefore continue to demonstrate and rely on disabled certificate validation. Remove -C (or explicitly install/use the LocalStack CA when needed) so the deployment script consistently validates the server certificate as well.

SQL_CONNECTION_STRING="Server=tcp:${SQL_SERVER_FQDN},1433;Database=${SQL_DATABASE_NAME};User ID=${DATABASE_USER_NAME};Password=${DATABASE_USER_PASSWORD};Encrypt=yes;Connection Timeout=30;"

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.