Web apps should request an SSL certificate for all incoming requests

Imran Qadir Baksh 51 Reputation points

Why suddenly Azure marking one of my existing Web App as unsecure because "Web apps should request an SSL certificate for all incoming requests" ?

My web app is public means anyone can browse the site using https://mysite.com? Why the user should sent client certificate?

Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,180 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. Richard Barraclough 6 Reputation points

    But people will stop using my website if I make them have to buy and install certificates.

    And you can't be following your own advice because, for example, I can access microsoft.com without having to buy and install my own certificate.

    1 person found this answer helpful.
    0 comments No comments

  2. Andriy Bilous 11,011 Reputation points MVP

    Hello @Imran Qadir Baksh

    You see Security recommendation "App Service web apps should have ‘Incoming client certificates’ enabled"

    Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app.
    The TLS mutual authentication technique in enterprise environments ensures the authenticity of clients to the server. If incoming client certificates are enabled, only an authenticated client who has valid certificates can access the app.

    With TLS mutual authentication Azure App Service supports Secure Renegotiation and doesn’t entertain ReNego. If there are TLS clients, that are not compliant as per the RFC 5746 and depend on Re-Negotiation, then they cannot connect to Azure App Service.

    Mutual authentication supports zero trust networking because it can protect communications against adversarial attacks, notably:

    • Man in the middle attack: Man-in-the-middle (MITM) attacks are when a third party wishes to eavesdrop or intercept a message, and sometimes alter the intended message for the recipient.
    • Replay attacks: A replay attack is similar to a MITM attack in which older messages are replayed out of context to fool the server. However, this does not work against schemes using mutual authentication because timestamps are a verification factor that are used in the protocols. If the change in time is greater than the maximum allowed time delay, the session will be aborted. Similarly, messages can include a randomly generated number to keep track of when a message was sent.
    • Spoofing attacks: Spoofing attacks rely on using false data to pose as another user in order to gain access to a server or be identified as someone else. Mutual authentication can prevent spoofing attacks because the server will authenticate the user as well, and verify that they have the correct session key before allowing any further communication and access.
    • Impersonation attacks: When each party authenticates the other, they send each other a certificate that only the other party knows how to unscramble, verifying themselves as a trusted source. In this way, adversaries cannot use impersonation attacks because they do not have the correct certificate to act as if they are the other party.

    Mutual authentication also ensures information integrity because if the parties are verified to be the correct source, then the information received is reliable as well