Weak TLS ciphers enabled

Hi @Amir Watynski ,

Thank you for submitting your question on Microsoft Q&A.

Could you please share the requested details so that we can continue investigating and help you resolve the issue promptly.

1. How is mrapay.com served today? (Azure Front Door, Application Gateway/WAF, App Service, IIS, Nginx/Apache, CDN, load balancer)
2. Are there multiple TLS termination points? (e.g., CDN + App Gateway + origin; any regional endpoints?)
3. What is the oldest client we need to support? (Android/iOS versions, legacy browsers, Java runtimes, kiosks, embedded devices)
4. Any B2B partners or APIs using legacy TLS (TLS 1.0/1.1) or Java 7/old OpenSSL?
5. Do we have non‑browser clients (mobile apps, POS, IoT, SAP connectors) that pin specific ciphers?
6. Minimum TLS protocol configured today? (1.0/1.1/1.2/1.3)
7. Which cipher suites are currently enabled at the edge (and at origin if it terminates TLS)?
8. Certificate chain details: key size (≥2048‑bit), signature algorithm (SHA‑256), validity, OCSP stapling, SNI usage.
9. Is HSTS enabled? (and max‑age/preload flags)
10. Do we have error telemetry for handshake failures (e.g., WAF logs, LB logs, app exceptions)?
11. A staging slot or canary endpoint to test stronger policies?
12. Change control window and rollback plan?
13. Which scanner flagged “Weak TLS ciphers,” and what exactly is listed? (e.g., RC4, 3DES, AES‑CBC, NULL/EXPORT suites, DSS/RSA‑MD5)
14. Scope of the finding (hostname(s), port(s), environments)

How is mrapay.com served today? (Azure Front Door, Application Gateway/WAF, App Service, IIS, Nginx/Apache, CDN, load balancer) --App Service

Are there multiple TLS termination points? (e.g., CDN + App Gateway + origin; any regional endpoints?) --Azure App Service

What is the oldest client we need to support? (Android/iOS versions, legacy browsers, Java runtimes, kiosks, embedded devices) --legacy browsers

Any B2B partners or APIs using legacy TLS (TLS 1.0/1.1) or Java 7/old OpenSSL? --At this stage, there’s no public source or external scan that can confirm whether mrapay.com has B2B integrations relying on legacy TLS

Do we have non‑browser clients (mobile apps, POS, IoT, SAP connectors) that pin specific ciphers? --No

Minimum TLS protocol configured today? (1.0/1.1/1.2/1.3) -- TLS 1.2

Which cipher suites are currently enabled at the edge (and at origin if it terminates TLS)? --

Certificate chain details: key size (≥2048‑bit), signature algorithm (SHA‑256), validity, OCSP stapling, SNI usage. --2048-bit RSA,SHA-256 (Required — not SHA-1),<= 398 days,Enabled (preferred),Enabled (Azure App Service requires SNI)

Is HSTS enabled? (and max‑age/preload flags) --Yes

Do we have error telemetry for handshake failures (e.g., WAF logs, LB logs, app exceptions)? --exceptions

A staging slot or canary endpoint to test stronger policies? --Don't know

Change control window and rollback plan? --Re-enable previously disabled cipher suites in Azure App Service SSL policy

Which scanner flagged “Weak TLS ciphers,” and what exactly is listed? (e.g., RC4, 3DES, AES‑CBC, NULL/EXPORT suites, DSS/RSA‑MD5) --TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   ECDH secp521r1 (eq. 15360 bits RSA)   FS   WEAK 256 --TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 128 --TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH secp521r1 (eq. 15360 bits RSA)   FS   WEAK 256 --TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH secp256r1 (eq. 3072 bits RSA)   FS   WEAK 128 --TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)   WEAK 256 --TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)   WEAK 128 --TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)   WEAK 256 --TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   WEAK 128 --TLS_RSA_WITH_AES_256_CBC_SHA (0x35)   WEAK 256 --TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   WEAK 128

Scope of the finding --hostname(s)= mrapay.com/mrapay.azurewebsites.net, --port(s)=443, --environments=Production Web Application

Hi @Amir Watynski ,
Thank you for your details and To make your TLS configuration stricter on Azure App Service without affecting the website’s availability, you can update the SSL/TLS policy directly from the App Service settings. Azure allows you to choose a more secure minimum TLS version and apply a stronger cipher suite order. By selecting a stricter TLS policy, the App Service will only accept connections that use modern, secure protocols helping you improve security while still ensuring compatibility with most browsers and clients.

The listed suites use AES-CBC or RSA key exchange, which are considered weak compared to modern standards (AES-GCM + ECDHE). Azure App Service defaults to a “Predefined SSL Policy” that includes older ciphers for compatibility with legacy clients, so the scanner flagged these ciphers.

Strengthening TLS on Azure App Service mainly involves enforcing modern protocols, removing weak cipher suites, and validating that your clients can still connect successfully. Here’s how to approach it safely and systematically.

Check Your Current TLS/SSL Policy

Start by reviewing the existing configuration:

• In the Azure Portal, go to your App Service > TLS/SSL Settings > Protocol Settings.
• Ensure Minimum TLS Version = TLS 1.2, which you already have set.

Azure App Service does not allow direct manual editing of cipher suites instead, TLS security is controlled through predefined SSL policies.

Move to a Stronger SSL Policy

Azure provides several built-in TLS policies:

App Service Default Includes older cipher suites (CBC, RSA key exchange) to support legacy clients.

App Service 2022 / App Service 2023 Stricter security profiles that disable weak ciphers and rely on modern ECDHE + AES-GCM suites.

To apply a stricter policy:

1. Go to TLS/SSL Settings > SSL Cipher Suite Order.

Select App Service 2022 or App Service 2023.

Save changes and restart the App Service.

Effect of this change:

• Weak cipher suites (AES-CBC, RSA-only key exchange) are removed.
• Secure suites like ECDHE + AES-GCM remain supported.
• Some older browsers and devices may no longer connect.

Validate Compatibility

Because you noted legacy browser usage, test before switching in production. Check behavior on:

• IE11 (Windows 7/10)

Older Android and iOS versions

Legacy Java clients

Safe way to test: Use a staging slot or clone the App Service, apply the stricter TLS policy there, and verify connectivity.

Confirm HSTS Is Enabled

You already have HSTS enabled. For best results:

• Ensure max-age ≥ 31536000 (1 year)

Use includeSubDomains

• Consider preload only if you understand long-term implications

Monitor After Deployment

Once the stricter policy is live:

• Go to App Service Diagnostics > TLS/SSL logs

Look for handshake failures or increased connection errors

This helps confirm whether any clients are failing due to removed cipher suites.

Have a Rollback Plan

If compatibility issues arise:

• Simply switch back to App Service Default SSL policy.

Restart the App Service.

This re-enables broader cipher support so legacy clients can reconnect.
Recommended Policy is App Service 2023 (TLS 1.2+, AES-GCM only, ECDHE key exchange). This aligns with modern security standards and passes most compliance scans.

Reference:

https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-certificate?tabs=apex%2Crbac%2Cazure-cli

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.