Troubleshooting Lab: Configure certificates and Transport Layer Security (TLS) for an App Service
Diagnostic Scenarios
Scenario 1 — Root Cause
A web application hosted on an App Service in the Standard S1 plan was recently migrated to a new custom domain portal.contoso.com. The operations team configured an SNI SSL type TLS binding and uploaded a .pfx certificate acquired from an external certificate authority. The certificate covers exactly the domain portal.contoso.com and is valid until 2026.
After configuration, users report that the browser displays the following warning:
NET::ERR_CERT_COMMON_NAME_INVALID
The certificate presented is valid for: shop.contoso.com
Information collected by the team:
- The App Service responds correctly on
https://portal.contoso.comfor the internal team - The CNAME DNS record correctly points to
contoso-app.azurewebsites.net - The Standard plan is active and without alerts in the portal
- The certificate upload was done with the correct password and the portal confirmed the thumbprint
What is the root cause of the observed problem?
A) The SNI SSL binding type is incompatible with the Standard S1 plan
B) The uploaded certificate covers a different domain from the custom domain configured in the binding
C) The CNAME DNS record is still propagating and some users are being routed to the old endpoint
D) The App Service has TLS cache enabled, delivering the old certificate from the previous configuration
Scenario 2 — Action Decision
The security team identified that an App Service in production is accepting TLS 1.0 connections. The cause was confirmed: the Minimum TLS Version field in Configuration > General settings is set to 1.0. The application processes financial data and corporate policy requires TLS 1.2 as minimum.
The App Service is in continuous production, serving approximately 4,000 simultaneous users. The minimum TLS version change does not require application restart and takes effect immediately. The team knows that a subset of users operates on legacy corporate devices that only support TLS 1.0, and these devices are in the process of replacement with completion expected in 30 days.
What is the correct action to take at this moment?
A) Immediately change the Minimum TLS Version to 1.2, as security policy takes precedence over compatibility with legacy devices
B) Wait 30 days until completion of legacy device replacement and then change the minimum version
C) Change the Minimum TLS Version to 1.1 as an intermediate measure, eliminating TLS 1.0 without affecting legacy devices
D) Create a second App Service with mandatory TLS 1.2 and gradually redirect traffic via Traffic Manager
Scenario 3 — Root Cause
An App Service in the Basic B2 plan has a custom domain api.fabrikam.io configured correctly. The team uploaded a valid .pfx certificate and attempted to create an IP Based SSL type binding. The Azure portal displayed the following error message when saving the binding:
The pricing tier 'Basic' does not support IP-based SSL.
Please upgrade your App Service plan to use this feature.
After seeing the error, a junior administrator took the following actions without consulting the team:
- Removed the binding with error
- Recreated the binding as SNI SSL
- Tested access via modern browser and confirmed HTTPS working
- Closed the incident as resolved
The next day, the integrations team reports that an external partner can no longer connect to the endpoint api.fabrikam.io. The partner uses a legacy system that does not support SNI.
What is the root cause of the failure reported by the partner?
A) The .pfx certificate was corrupted during binding removal and recreation
B) SNI SSL binding is not supported in the Basic B2 plan and the certificate is being delivered without encryption
C) Changing the binding type from IP Based SSL to SNI SSL made the endpoint inaccessible for clients without SNI support
D) The custom domain api.fabrikam.io lost domain ownership verification after removing the original binding
Scenario 4 — Diagnostic Sequence
An App Service exhibits the following behavior: when accessing https://crm.wingtip.com, the browser displays an expired certificate warning. The domain uses a manually uploaded certificate (not a managed certificate). The team needs to diagnose and resolve the problem.
The following investigation steps are available, out of order:
- Step P: Upload a new valid
.pfxcertificate to App Service viaCertificates > Bring your own certificates - Step Q: Check the expiration date of the current certificate in
Certificatesin the Azure portal - Step R: Update the binding in
Custom domains > TLS/SSL bindingsto point to the new certificate by thumbprint - Step S: Confirm that the new certificate covers the domain
crm.wingtip.comand that the.pfxfile includes the private key - Step T: Validate access on
https://crm.wingtip.comand confirm that the browser no longer displays the warning
What is the correct sequence of investigation and resolution?
A) Q, P, S, R, T
B) S, Q, P, R, T
C) Q, S, P, R, T
D) P, S, R, Q, T
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The NET::ERR_CERT_COMMON_NAME_INVALID message with the indication that the certificate is valid for shop.contoso.com directly reveals that the uploaded certificate does not match the domain configured in the binding. The certificate covers a different domain (shop.contoso.com), so the browser rejects the connection.
The decisive clue in the statement is the browser error message itself, which displays the domain covered by the certificate. This information eliminates all other hypotheses without requiring additional investigation.
The irrelevant information in the statement is that the internal team can access the endpoint correctly. This may occur due to DNS cache variations, but it doesn't change the cause of the certificate warning, which is independent of DNS routing.
Distractor C is the most dangerous: in migration scenarios, DNS propagation is a common and legitimate suspicion, but the warning displayed is not a name resolution error, but rather a certificate incompatibility. Acting based on this hypothesis would lead the team to wait for propagation that has already occurred, while the wrong certificate remains in the binding.
Answer Key — Scenario 2
Answer: A
The statement explicitly states that corporate policy requires TLS 1.2 as minimum and that the change does not cause service interruption. Given that the security restriction is defined by organizational policy and not by optional technical choice, the correct action is to immediately apply the required configuration.
Alternative B ignores the security policy and prioritizes compatibility with devices being decommissioned. This reasoning is a self-imposed restriction that doesn't exist in the statement: the policy doesn't provide an exception for a timeframe.
Alternative C represents a technically possible action, but one that doesn't meet corporate policy. TLS 1.1 is also considered insecure and doesn't satisfy the minimum version 1.2 requirement.
Alternative D is an architecturally correct solution for other scenarios, but introduces unnecessary operational complexity when the solution is a point configuration change without availability impact. Creating parallel infrastructure to work around a one-line configuration is a response proportionality error.
Answer Key — Scenario 3
Answer: C
The partner uses a legacy system without SNI support. The SNI SSL binding depends on the SNI extension of the TLS protocol for the server to identify which certificate to present during the handshake. Clients that don't send the SNI field in the handshake cannot establish TLS connection correctly with this type of binding when there are multiple certificates on the same IP address.
The root cause is not that the binding was recreated per se, but that the chosen binding type is incompatible with the partner's legacy client.
The relevant information confirming the diagnosis is the combination of two facts: the partner uses a legacy system without SNI support, and the binding was changed from IP Based SSL to SNI SSL. The failure occurred exactly after this change.
Alternative D is the most dangerous distractor. In scenarios of custom domain removal and recreation, domain ownership verification can indeed be affected. However, if the domain had lost verification, the symptom would be a resolution error or redirection to the App Service default hostname, not a selective TLS connection failure affecting only the partner's system.
Answer Key — Scenario 4
Answer: C
The correct sequence is Q, S, P, R, T.
Progressive diagnostic reasoning requires:
- Q — Confirm the problem with the current certificate by checking expiration, which validates the symptom before any action
- S — Before uploading any file, validate that the new certificate covers the correct domain and contains the private key, avoiding rework
- P — Only after validating the new certificate, perform the upload
- R — After upload, update the binding to reference the new thumbprint
- T — Validate the final result in the browser to confirm resolution
Alternative A (Q, P, S, R, T) reverses the order of S and P: the file would be uploaded before being validated, which may result in uploading a certificate that doesn't cover the domain or doesn't contain the private key, forcing a new removal and reload cycle.
Alternative D starts with upload before any diagnosis or validation, which represents the most serious error: acting before understanding the problem and before verifying the adequacy of the material that will be used in the correction.
Troubleshooting Tree: Configure certificates and Transport Layer Security (TLS) for an App Service
Color legend:
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate verification or validation |
To use this tree when facing a real problem, start with the root node describing the general symptom and follow the branches by answering each question based on what you observe in the environment. Closed questions like "does the certificate domain match the binding?" or "is the client a legacy system?" eliminate hypotheses quickly. When you reach a red node, the cause is identified. The green node immediately accessible from it indicates the correct action. Never execute a green action before confirming you've reached the corresponding red node through the correct path.