Azure Fundamentals for Web Hosting: SSL/TLS certificates and HTTPS enforcement

What HTTPS and TLS provide (and what Azure expects)

HTTPS is HTTP carried inside a TLS-encrypted connection. TLS provides three core properties for web hosting: (1) encryption so traffic cannot be read in transit, (2) integrity so traffic cannot be modified without detection, and (3) authentication so clients can verify they are talking to the correct hostname via a certificate.

In practice, this means your public endpoint must present a certificate whose Subject Alternative Name (SAN) includes the exact hostname users visit (for example, www.example.com). The certificate must be trusted by client devices (typically a public CA), and the server must negotiate a modern TLS version and cipher suite.

Where TLS terminates (and why it matters)

• App Service: TLS terminates at the App Service front ends (Azure-managed). Your app receives HTTP internally unless you also implement end-to-end TLS behind the platform (not typical for basic web hosting). You manage certificates and bindings in the App Service resource.
• Azure Container Apps: TLS terminates at the Container Apps ingress (Envoy-based). You attach a certificate to the Container App environment and bind it to a custom domain. Your container receives HTTP from the ingress unless you build additional internal TLS.
• Virtual Machines: TLS terminates wherever you configure it: directly on the web server (IIS/Apache/Nginx), or on a reverse proxy/load balancer you manage. You are responsible for certificate storage, renewal, and server TLS configuration.

Implementation guide: obtain a certificate

Option A: Use a managed certificate (when available)

Managed certificates reduce operational work because Azure handles issuance and renewal. Availability depends on the service and scenario.

• App Service Managed Certificate: Suitable for many common App Service custom domain scenarios. It is free, auto-renewed, and stored/managed by the platform. Limitations apply (for example, it is intended for App Service front-end use and not exportable as a PFX for other services).
• Container Apps: Container Apps supports binding a certificate to custom domains; depending on your setup you may use a certificate you upload (BYO) or integrate with a managed approach via Key Vault/automation. Plan for BYO unless your environment explicitly supports a managed issuance workflow.

Prerequisites for managed issuance: the custom domain must already be validated and mapped to the service, and the hostname must resolve correctly. If issuance fails, it is often due to incomplete domain validation or DNS not yet propagated.

Option B: Bring your own certificate (PFX/PEM)

Bring-your-own (BYO) is the most flexible approach and works everywhere, including VMs. Typical sources:

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

• A public CA certificate purchased from a certificate provider.
• An ACME-based certificate (for example, Let’s Encrypt) obtained via an automation tool.
• A certificate issued by your organization’s internal CA (only appropriate if all clients trust that CA).

File formats:

• PFX (.pfx): contains certificate + private key, protected by a password. Common for App Service and Windows/IIS.
• PEM (.pem/.crt + .key): common for Linux/Nginx/Apache and some upload workflows.

Key size and algorithm: prefer RSA 2048+ or ECDSA (P-256) depending on your compatibility needs. Ensure the certificate includes the full chain (intermediate certificates) to avoid trust errors.

Bind the certificate to the hostname

App Service: upload/bind or use a managed certificate

Goal: ensure https://your-hostname presents the correct certificate and SNI binding.

• Managed certificate path (typical):
  • In the App Service, go to TLS/SSL settings (or Certificates depending on portal layout).
  • Create an App Service Managed Certificate for the validated custom domain.
  • Go to TLS/SSL bindings and add a binding: select the custom hostname, choose the managed certificate, and use SNI SSL.
• BYO certificate path:
  • Upload the PFX to the App Service certificate store (portal: Certificates or TLS/SSL settings).
  • Add a TLS/SSL binding for the hostname using SNI SSL (recommended for multiple hostnames on the same app).
  • If you have multiple hostnames, ensure each hostname has a binding to a certificate that includes it in SAN.

Notes: If you use deployment slots, bindings can be slot-specific depending on configuration; plan bindings so production hostname always points to the slot that should serve traffic.

Container Apps: upload/attach certificate and map to custom domain

Goal: terminate TLS at the ingress and serve the custom domain over HTTPS.

• In the Container Apps environment (or the Container App, depending on portal experience), add a certificate (upload PFX/PEM as supported).
• In the Container App, open Ingress and configure Custom domains.
• Associate the custom domain with the uploaded certificate.
• Ensure ingress is enabled and external if this is a public web app.

Notes: Container Apps typically routes traffic via the ingress proxy. Your container should listen on the configured target port (HTTP) unless you explicitly implement internal TLS.

Virtual Machines: install certificate on the web server or reverse proxy

Goal: configure your web server to present the certificate and private key for the hostname, and to negotiate strong TLS settings.

Windows/IIS (high-level steps):

• Import the PFX into the Windows certificate store (Local Computer > Personal).
• In IIS Manager, open the site > Bindings > add/edit https on port 443.
• Select the certificate and ensure the Host name is set for SNI if hosting multiple sites.

Linux/Nginx (high-level steps):

• Place fullchain.pem and privkey.pem with strict permissions (private key readable only by root or the service account).
• Configure a server block for listen 443 ssl; and set ssl_certificate and ssl_certificate_key.
• Reload Nginx after validation.

# Example Nginx snippet (paths are examples)server {  listen 443 ssl http2;  server_name www.example.com;  ssl_certificate     /etc/ssl/certs/fullchain.pem;  ssl_certificate_key /etc/ssl/private/privkey.pem;  # ... app proxy / root ...}

Enable HTTPS-only and configure redirects

Why both matter

HTTPS-only prevents clients from using plain HTTP. Redirects provide a user-friendly path from http:// to https:// (typically a 301/308). You often want both: redirect for convenience, and enforcement to prevent accidental insecure access.

App Service: HTTPS-only and redirect behavior

• Enable HTTPS Only in the App Service settings. This blocks HTTP at the platform edge.
• If you need explicit redirect semantics (for SEO or strict client behavior), implement an application-level redirect (for example, middleware) because platform enforcement may behave as a block rather than a classic 301 in some cases.

Example (conceptual) application redirect: in many frameworks you can enable “use HTTPS redirection” so requests to HTTP receive a 301/308 to HTTPS.

Container Apps: enforce HTTPS at ingress and redirect

Container Apps ingress typically supports HTTPS for custom domains when a certificate is bound. To ensure HTTP does not remain usable:

• Prefer configuring ingress to accept HTTPS only if the platform option is available in your environment.
• If HTTP remains reachable, implement an HTTP-to-HTTPS redirect in your application or via a lightweight sidecar/reverse proxy pattern.

Practical approach: ensure your app checks X-Forwarded-Proto (or equivalent forwarded headers) from the ingress and redirects to HTTPS when it indicates an HTTP request.

Virtual Machines: redirect at the web server

On VMs you control both enforcement and redirect logic. A common pattern is to listen on port 80 and redirect everything to HTTPS.

# Example Nginx HTTP->HTTPS redirectserver {  listen 80;  server_name www.example.com;  return 301 https://$host$request_uri;}

IIS: you can use URL Rewrite to redirect HTTP to HTTPS, and optionally require SSL for the site.

Verification: browser tools and command-line checks

Browser verification

• Open the site in a private/incognito window to avoid cached redirects.
• Click the lock icon and inspect certificate details: hostname match, issuer, validity dates, and chain.
• Use Developer Tools > Network: confirm requests are https://, check for mixed content warnings, and verify any HTTP request receives a 301/308 (if you configured redirects).

Command-line checks

Check redirect and headers with curl:

# Show response headers (HTTP) and confirm redirect to HTTPS curl -I http://www.example.com/# Follow redirects and show final URL and status curl -IL http://www.example.com/

Inspect certificate and negotiated TLS with OpenSSL:

# SNI is important: use -servername to test the correct hostname openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts

In the output, verify:

• The certificate subject/SAN includes the hostname.
• The chain includes intermediate certificates (clients should not need to fetch missing intermediates).
• The negotiated protocol is TLS 1.2 or TLS 1.3.

Optional: test specific TLS versions (should fail for old versions):

# These should generally fail if you have disabled legacy protocols openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_0 openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1

Renewal and avoiding downtime

Managed certificates: monitor, but expect auto-renew

• Managed certificates are designed to renew automatically. Still, monitor expiration dates and set alerts where possible.
• Be cautious with domain/DNS changes: if domain validation breaks, renewal can fail later.

BYO certificates: plan a repeatable renewal process

For BYO, renewal is your responsibility. The key to avoiding downtime is to renew early and deploy the new certificate without breaking the existing binding.

• Renew early: start renewal at least 2–4 weeks before expiration.
• Overlap validity: obtain the new certificate while the old one is still valid.
• Deploy then switch:
  • App Service: upload the new PFX, then update the TLS binding to point to the new certificate. This is typically quick and does not require app redeploy.
  • Container Apps: upload/add the new certificate, then update the custom domain binding to reference it.
  • VMs: install the new certificate alongside the old one, update the server config/binding, validate configuration, then reload the service (reload preferred over restart when supported).
• Rollback plan: keep the old certificate available until you confirm the new one is served correctly.

Automation note: for ACME-based renewals on VMs, use a scheduled task/cron job that renews and reloads the web server only when the certificate changes. For PFX-based workflows, ensure the private key password and storage are handled securely.

Zero-downtime considerations

• App Service/Container Apps: certificate binding changes are generally low-impact; still validate immediately after changes.
• VMs: prefer configuration reloads (for example, nginx -s reload) to avoid dropping connections. If you must restart, do it during low-traffic windows or behind a load-balanced setup.

Security notes and hardening checklist

Use strong TLS versions and ciphers

• Target TLS 1.2 and TLS 1.3. Disable TLS 1.0/1.1 unless you have a documented legacy requirement.
• On managed platforms (App Service/Container Apps), platform defaults are typically modern; still verify with command-line checks.
• On VMs, explicitly configure your web server to disable weak protocols and ciphers.

HSTS (conceptual guidance)

HTTP Strict Transport Security (HSTS) tells browsers to only use HTTPS for your domain for a specified period. This reduces downgrade attacks and accidental HTTP usage, but it can also lock clients into HTTPS—so enable it only after you are confident HTTPS is stable.

• Start with a short max-age and increase gradually.
• Be careful with includeSubDomains if you have subdomains that are not ready for HTTPS.
• Preload is an additional commitment and should be considered only after thorough validation.

Protect private keys

• Limit access to certificate private keys to the minimum necessary identities/accounts.
• Store secrets securely (for example, use a secret store and controlled access); avoid embedding private keys in source control or container images.
• On Linux, set strict filesystem permissions for key files (for example, owned by root, readable only by the web server process if needed).
• Rotate keys if you suspect compromise; do not only reissue the certificate with the same key.

Operational checks to keep in place

• Alert on certificate expiration (for all hostnames/SANs you serve).
• Periodically re-run TLS verification (protocol versions, chain completeness).
• Validate that HTTP is either blocked or redirected, and that no mixed content is introduced by application changes.