This chapter covers encryption in transit for Azure services, focusing on TLS (Transport Layer Security) and HTTPS. For the AZ-500 exam, this topic appears in roughly 5-10% of questions, primarily under objective 2.3 (Implement and manage compute security) and 3.1 (Configure and manage security for data). You must understand how TLS protects data moving between clients and Azure services, how Azure enforces HTTPS, and how to configure TLS versions and cipher suites. This chapter provides the depth needed to answer exam questions confidently, including specific values, default settings, and common misconfiguration pitfalls.
Jump to a section
Imagine you need to send a secret letter to a colleague in a different city. You place the letter inside a locked box. Only you and your colleague have the key to this lock. You hand the box to a courier service. The courier cannot open the box, but they can see the delivery address on the outside. Before sending, you also wrap the box in a special tamper-proof seal that, if broken, leaves a visible pattern. When the box arrives, your colleague checks the seal – if it's intact, they know no one opened the box in transit. They then unlock the box with their key and read the letter. This is exactly how TLS works: the locked box is the encrypted data (using symmetric encryption after a key exchange), the tamper-proof seal is the message authentication code (MAC) that ensures integrity, and the delivery address is the server name (SNI). The courier is the network – they can see where the packet is going (the IP address and port) but cannot read the contents. The initial key exchange (like agreeing on a shared key) happens using asymmetric cryptography (like a public-key lockbox) before the symmetric key is used for the actual data.
What is Encryption in Transit?
Encryption in transit protects data from being read or modified while traveling over a network. In Azure, this is primarily achieved using TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer). HTTPS is HTTP over TLS. The exam expects you to know that TLS 1.2 is the minimum required version in many Azure services, and TLS 1.0 and 1.1 are deprecated. The current recommended version is TLS 1.3.
How TLS Works: The Handshake
The TLS handshake is the process by which client and server agree on encryption parameters. Here's the step-by-step mechanism:
Client Hello: The client sends a list of supported TLS versions, cipher suites (e.g., TLS_AES_256_GCM_SHA384 for TLS 1.3), and a random number.
Server Hello: The server selects the highest mutually supported TLS version and a cipher suite, sends its digital certificate (containing its public key), and a random number.
Key Exchange: For TLS 1.2, the client generates a pre-master secret, encrypts it with the server's public key, and sends it. For TLS 1.3, a Diffie-Hellman key exchange is used, providing forward secrecy.
Session Keys: Both parties derive symmetric session keys from the pre-master secret and random numbers.
Finished: Both sides send encrypted messages to confirm the handshake is complete.
Key Components and Defaults
TLS Versions: Azure supports TLS 1.0, 1.1, 1.2, and 1.3. The default for most Azure services (like App Service, Azure Front Door) is TLS 1.2. You can enforce minimum TLS versions in policy.
Cipher Suites: These define the encryption algorithm (e.g., AES-256), key exchange (e.g., ECDHE), and MAC (e.g., SHA-384). Azure Front Door and Application Gateway allow you to manage cipher suites.
Certificates: X.509 certificates are used for server authentication. Azure Key Vault can store and manage certificates. The certificate must be valid (not expired), have a trusted root CA, and match the domain name (CN or SAN).
Port: HTTPS uses TCP port 443 by default.
Azure Services and TLS Configuration
Azure App Service: You can enforce HTTPS only (redirect HTTP to HTTPS), set minimum TLS version (1.0, 1.1, 1.2), and upload custom certificates.
Azure Front Door: Supports TLS 1.2 and 1.3. You can manage cipher suites and enable OCSP stapling.
Application Gateway: Supports end-to-end TLS with SSL termination at the gateway. You can upload certificates and configure TLS policy.
Azure Storage: Supports HTTPS for REST API calls. You can enforce secure transfer (HTTPS) at the storage account level.
Azure SQL Database: Always encrypts data in transit using TLS 1.2. You cannot disable it.
Azure Key Vault: All traffic is encrypted with TLS 1.2. You can configure firewall and VNet service endpoints.
Verification Commands
You can test TLS configuration using tools like openssl or curl:
# Check TLS version and cipher for a website
openssl s_client -connect example.com:443 -tls1_2
# List supported ciphers
nmap --script ssl-enum-ciphers -p 443 example.comIn Azure, you can use Azure Policy to enforce minimum TLS versions. For example, the built-in policy "App Service should only be accessible over HTTPS" ensures HTTPS-only.
Interaction with Related Technologies
Azure Policy: Can enforce minimum TLS version across subscriptions.
Azure Security Center: Provides recommendations like "Enforce HTTPS only" and "Use TLS 1.2".
Azure Front Door WAF: Can inspect HTTPS traffic and block malicious requests.
Azure Private Link: Traffic to PaaS services over private endpoints uses Microsoft backbone network, but still uses TLS for encryption.
Common Configuration Mistakes
Allowing older TLS versions (1.0/1.1) due to legacy client support.
Using self-signed certificates without proper CA trust.
Not enforcing HTTPS redirect, leaving HTTP endpoints exposed.
Misconfiguring cipher suites, leading to weak encryption or compatibility issues.
Not updating certificates before expiry, causing service interruptions.
Exam Focus on Defaults
The AZ-500 exam often tests default settings. For example:
Azure Storage: Default is to allow HTTP, but you can enforce HTTPS via "Secure transfer required".
Azure App Service: Default is to allow both HTTP and HTTPS, but you can enable "HTTPS Only".
Azure SQL Database: Always uses TLS 1.2; no configuration needed.
Azure Key Vault: Default is TLS 1.2; cannot be changed.
TLS 1.3 vs 1.2
TLS 1.3 offers improved security and performance:
Removes weak cipher suites (e.g., RC4, 3DES).
Reduces handshake round trips (1-RTT vs 2-RTT).
Provides forward secrecy by default.
Uses AEAD ciphers (e.g., AES-GCM).
Azure Front Door and Application Gateway support TLS 1.3. Azure App Service supports it as an option.
Certificate Management in Azure
Certificates can be stored in Azure Key Vault and automatically rotated. For App Service, you can import certificates from Key Vault. The exam may ask about certificate expiration: you must renew before expiry to avoid downtime. Azure Key Vault can send alerts before expiration.
Summary of Key Values
Minimum TLS version for most Azure services: 1.2.
Default port: 443.
Certificate type: X.509 (PEM/PFX).
Key exchange: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for forward secrecy.
Encryption: AES-256-GCM for TLS 1.3.
Hash: SHA-384 for TLS 1.3.
These specifics are frequently tested.
Client Initiates TLS Handshake
The client (e.g., a web browser) sends a ClientHello message to the server. This message includes the highest TLS version the client supports (e.g., TLS 1.3), a list of cipher suites (e.g., TLS_AES_256_GCM_SHA384), and a random 32-byte number (client random). The client also indicates if it supports features like SNI (Server Name Indication) for hosting multiple domains on one IP. This step occurs over TCP port 443 after the TCP three-way handshake is complete.
Server Responds with ServerHello
The server receives the ClientHello and selects the highest TLS version common to both (e.g., TLS 1.2) and a cipher suite from the client's list. It sends a ServerHello message containing the chosen version, cipher suite, a server random (32 bytes), and optionally a session ID for resumption. For TLS 1.3, the server also sends its certificate and a key share (public key for key exchange) in the same flight, reducing round trips.
Server Sends Certificate and Key Exchange
The server sends its digital certificate (X.509) containing its public key and identity (domain name). The client validates the certificate against a trusted root CA, checks expiration, and verifies the domain name matches. For TLS 1.2, the server may also send a ServerKeyExchange message for key exchange algorithms like DHE or ECDHE. For TLS 1.3, the key exchange is integrated into the ServerHello.
Client Generates and Sends Pre-Master Secret
In TLS 1.2, the client generates a 48-byte pre-master secret, encrypts it with the server's public key (from the certificate), and sends it in a ClientKeyExchange message. The client also sends a ChangeCipherSpec message indicating that subsequent messages will be encrypted. Then it sends an encrypted Finished message containing a hash of all previous handshake messages. The server decrypts the pre-master secret using its private key.
Session Key Derivation and Verification
Both client and server independently derive session keys from the pre-master secret, client random, and server random using a pseudo-random function (PRF). For TLS 1.2, this yields encryption keys (e.g., AES-256), MAC keys (e.g., HMAC-SHA256), and IVs. The server sends its own ChangeCipherSpec and Finished message. The client verifies the server's Finished message. Once both sides verify, the handshake is complete, and encrypted data transfer begins.
Enterprise Scenario 1: E-Commerce Application with PCI DSS Compliance
A large e-commerce company hosts its web application on Azure App Service. To comply with PCI DSS, they must encrypt all cardholder data in transit using strong cryptography. They enforce HTTPS-only by enabling the "HTTPS Only" setting in App Service TLS/SSL settings. They also set the minimum TLS version to 1.2 to prevent downgrade attacks. They use Azure Front Door as a global load balancer and WAF, which terminates TLS and inspects traffic. The backend App Service is configured to accept traffic only from Front Door's IP ranges (via access restrictions). They upload a wildcard certificate (*.contoso.com) from a public CA to App Service. Performance is monitored: TLS 1.3 is enabled on Front Door to reduce latency. A common issue is certificate expiration: they use Azure Key Vault to store the certificate and set up auto-renewal, with alerts 30 days before expiry.
Enterprise Scenario 2: Multi-Tenant SaaS Application with Custom Domains
A SaaS provider runs a multi-tenant application on Azure App Service with custom domain names for each customer (e.g., customer1.saas.com). They use SNI (Server Name Indication) to serve different certificates per domain. Each customer uploads their own certificate or the provider uses a wildcard certificate. They enforce TLS 1.2 as minimum. They use Application Gateway for SSL offloading: the gateway handles TLS termination and forwards plain HTTP to the backend (or re-encrypts for end-to-end TLS). For high availability, they deploy multiple instances across availability zones. A misconfiguration occurs when a customer's certificate is not updated: the application becomes inaccessible. They use Azure Monitor to set up alerts for certificate expiration. They also use Azure Policy to enforce that all App Service instances have HTTPS only enabled.
Enterprise Scenario 3: Financial Services with Strict Encryption Requirements
A bank uses Azure SQL Database for transaction processing. All data in transit must be encrypted. Azure SQL Database always uses TLS 1.2; no configuration is needed. However, the bank's applications must connect using TLS 1.2. They use Azure Key Vault to store the client certificate for service-to-service authentication. They also use Azure Private Link to connect from their VNet to SQL Database, ensuring traffic never leaves the Microsoft backbone. They enforce a minimum TLS version of 1.2 for all Azure services via Azure Policy. A common issue is that legacy applications try to connect with TLS 1.0, which fails. They remediate by updating the application's TLS stack or using an Application Gateway to terminate TLS 1.0 and re-encrypt with TLS 1.2.
AZ-500 Exam Focus on Encryption in Transit
Objective Codes: This topic directly maps to objective 2.3 (Implement and manage compute security) and 3.1 (Configure and manage security for data). Questions may appear under "Secure data in transit" or "Configure TLS settings."
What the Exam Tests:
The ability to enforce HTTPS-only and minimum TLS versions on Azure services (App Service, Storage, SQL, Key Vault).
Understanding of TLS handshake basics (not deep cryptography, but which steps occur).
Knowledge of default TLS settings: Azure SQL Database always uses TLS 1.2; Azure Storage defaults to allowing HTTP but can enforce HTTPS; App Service defaults to allowing both.
Certificate management: where to store certificates (Key Vault), how to import to App Service, and the importance of expiration.
The difference between SSL termination (at load balancer) and end-to-end TLS.
Common Wrong Answers and Why Candidates Choose Them: 1. "Azure SQL Database supports TLS 1.0" — Candidates see that older SQL Server versions support TLS 1.0, but Azure SQL Database enforces TLS 1.2. The exam tests that Azure SQL Database always uses TLS 1.2. 2. "Enabling HTTPS only on App Service automatically redirects HTTP to HTTPS" — This is actually correct, but candidates may think it doesn't. The setting does redirect HTTP 301 to HTTPS. 3. "You must configure TLS version on Azure Key Vault" — Key Vault enforces TLS 1.2 by default and cannot be changed. Candidates may think they can lower it. 4. "TLS 1.3 is not supported in Azure" — It is supported in Front Door and Application Gateway. Candidates may assume only TLS 1.2.
Specific Numbers and Values:
Minimum TLS version for most services: 1.2.
Default port: 443.
Certificate type: X.509.
Cipher suite example for TLS 1.3: TLS_AES_256_GCM_SHA384.
Azure Policy for HTTPS: "App Service should only be accessible over HTTPS" (built-in).
Edge Cases:
If a client uses TLS 1.0 and the server requires TLS 1.2, the handshake fails. The exam may ask what error occurs (e.g., handshake failure).
When using Azure Front Door, you can set minimum TLS version on the custom domain HTTPS settings.
For Azure Storage, "Secure transfer required" must be enabled to enforce HTTPS.
How to Eliminate Wrong Answers:
If an answer suggests disabling TLS or using plain HTTP, it is wrong.
If an answer mentions configuring TLS version on Azure SQL Database, it is wrong (it's fixed).
If an answer says you must manually rotate certificates in App Service, it may be wrong if Key Vault integration is available.
TLS 1.2 is the minimum required version for most Azure services; TLS 1.0 and 1.1 are deprecated.
Azure SQL Database always uses TLS 1.2 – no configuration option exists.
Azure Storage defaults to allowing HTTP; enable 'Secure transfer required' to enforce HTTPS.
Azure App Service can enforce HTTPS-only and set minimum TLS version in TLS/SSL settings.
Certificates must be valid, from a trusted CA, and match the domain name (CN/SAN).
Azure Key Vault can store and automatically rotate certificates used by App Service.
TLS 1.3 is supported in Azure Front Door and Application Gateway; provides faster handshake and better security.
Azure Policy can enforce minimum TLS version across all resources in a subscription.
These come up on the exam all the time. Here's how to tell them apart.
SSL Termination at Load Balancer
TLS is decrypted at the load balancer (e.g., Application Gateway).
Backend servers receive plain HTTP traffic.
Reduces CPU load on backend servers.
Requires trust between load balancer and backend (internal network).
Common for web applications where backend is in a VNet.
End-to-End TLS
TLS is maintained from client to backend server.
Backend servers must handle TLS decryption.
Provides encryption throughout the entire path.
Backend servers need certificates and more CPU resources.
Required for compliance where data must be encrypted end-to-end (e.g., PCI DSS).
Mistake
TLS and SSL are the same thing and can be used interchangeably.
Correct
SSL (Secure Sockets Layer) is the predecessor to TLS. SSL versions 2.0 and 3.0 are deprecated and insecure. TLS 1.0 is sometimes called SSL 3.1, but TLS is the modern standard. Azure services do not support SSL; they support TLS 1.0, 1.1, 1.2, and 1.3.
Mistake
Enabling HTTPS-only on App Service automatically disables HTTP completely.
Correct
HTTPS-only redirects HTTP requests to HTTPS (301 redirect). The HTTP endpoint still exists but responds with a redirect. To disable HTTP entirely, you must also remove the HTTP binding or use access restrictions.
Mistake
Azure SQL Database allows you to choose the TLS version for connections.
Correct
Azure SQL Database enforces TLS 1.2 for all connections. You cannot configure a different TLS version. This is a common exam trap.
Mistake
Self-signed certificates are acceptable for production HTTPS in Azure.
Correct
Self-signed certificates are not trusted by browsers and clients. For production, you must use a certificate from a trusted public CA (e.g., DigiCert, GlobalSign) or Azure Key Vault integrated CA.
Mistake
TLS 1.3 is not supported in any Azure service.
Correct
Azure Front Door and Azure Application Gateway support TLS 1.3. Azure App Service also supports TLS 1.3 as an option. Always check the specific service documentation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The default minimum TLS version for Azure App Service is TLS 1.2. However, you can change it to 1.0 or 1.1 if needed (not recommended). The exam expects you to know that TLS 1.2 is the default and that you can enforce it via the Azure portal or CLI.
In the Azure portal, go to your storage account, select 'Configuration' under Settings, and set 'Secure transfer required' to Enabled. This will reject any HTTP requests. You can also do this via Azure Policy using the built-in policy 'Storage accounts should restrict network access' or a custom policy.
No, Azure Front Door requires a certificate from a trusted public CA. Self-signed certificates are not supported because Front Door must present a certificate that clients trust. You can use Azure Key Vault to store a CA-signed certificate.
The connection will fail because Azure SQL Database only accepts TLS 1.2. The client will receive a handshake failure error. The exam may test this as a scenario where legacy applications stop working.
In the Front Door custom domain HTTPS settings, you can select the minimum TLS version: 1.0, 1.2, or 1.3. The default is 1.2. You can also manage cipher suites under the policy settings.
SSL termination means the load balancer decrypts TLS and sends plain HTTP to the backend. End-to-end TLS means the encryption is maintained from client to backend server. The exam may ask which is more secure (end-to-end) and which reduces backend CPU (termination).
No, Azure Key Vault always uses TLS 1.2. You cannot disable encryption in transit. All requests to Key Vault must be over HTTPS.
You've just covered Encryption in Transit: TLS and HTTPS — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?