I have an app service protected by Front Door. App Service access restrictions only allow connections from FrontDoor.
App service accepts https only TLS1.2.. FD routing set to httpsOnly.
Let's Encrypt TLS Cert is setup in keyvault and custom domain setup in Frontdoor.
The backend host header field in FD is left empty, to allow for custom domain to be passed in header to app service to avoid broken redirects and cookies (redirects were going to app service DNS instead of FD)
I added the custom domains to app service.. but getting a warning that there are no TLS bindings.
Do I need them, given I don't allow connections direct to app service but to FD only?
The FrontDoor TLS end to end encryption documentation states the
following:
For HTTPS connections, Azure Front Door expects that your
backend presents a certificate from a valid Certificate Authority (CA)
with subject name(s) matching the backend hostname. As an example, if
your backend hostname is set to myapp-centralus.contosonews.net and
the certificate that your backend presents during the TLS handshake
doesn't have myapp-centralus.contosonews.net or *.contosonews.net in
the subject name, then Azure Front Door will refuse the connection and
as a result an error.
My understanding here is FD relies on the app service hostname and TLS cert (Azure managed) to encrypt its backend connection.
Everything works, and I don't see any security warnings in the browser... but wondering if in fact the backend TLS encryption is being correctly implemented?
Related
By default, when the web app is deployed in Azure Static Web App, it will automatically use https. However, the back-end API must use https (web socket must use wss) as well.
I used the self-signed cert to expose the back-end API to let the front-end consume. However, the browser deny with message "TLS handshake error from xx.xx.xx.xx: remote error: tls: unknown certificate"
Must I purchase the CA signed certificate? This is my personal project. And I do not want to spend money to buy a CA signed cert. Is there other way to resolve the problem, such as downgrade the https used in Azure Static Web App to http?
I am working on setting up an API Management service on Azure. My question is related to setting up the SSL certificate that was generated using Azure Key Vault.
My certificate was created with the CNAME as *.contoso.com. My custom domain in the API Management service is api.contoso.com. Now, when I'm setting up my custom domain, there is a field to select the certificate from Key Vault which I have already done. Now when I import the API using OpenAPI spec and go to Settings; there is also an option to select a Client cert under the Gateway credentials heading (see screenshot attached).
My question is, what is the difference between these two? If I have already provided a certificate when setting up the custom domain, do I need to add the certificate to the API as well?
Just a piece of extra information. My plan is to import two APIs and set them up at https://api.contoso.com/app1 and https://api.contoso.com/app2
The backend gateway credentials are for authenticating the API Management instance ("gateway") to the backend service, that doesn't know it's being called by a gateway. It's there on the assumption that you can't always pass through a valid set of credentials from the client since one of API Management's roles is to work as an adapter for services not necessarily designed to be called by clients on the internet.
You've already worked out what the custom domain certificate is for; this is so that the API Management instance can negotiate TLS on the frontend with a certificate whose subject matches the hostname the caller connected with.
For testing purposes I would like to enable the 'Incoming Client Certificates' option in my Azure App Service (running a WCF webservice), and see if my Client application can still connect to the webservice. Since I am still in a testing phase, my app service still has the .azurewebsites.net domain name.
However, I can't seem to figure out how to get a proper client certificate that the server will accept (without switching to a custom domain name, which I know will work).
Currently, I see 2 possible routes to a solution:
Somehow get my hands on .cer that is signed by a CA trusted by the App Service server.
Generate a self-signed .pfx and .cer with my own self-signed CA. Import the pfx on the App Service and install the .cer on the client.
Both directions have not yielded any success so far. Does anyone have any experience with this?
Per my understanding, the client certificate is used by client systems to make authenticated requests to a remote server. In this case, your webservice is the remote server in a C/S mode. As you point out, "validating this certificate is the responsibility of the web app. So this means that any certificate will be valid as long as you don't validate anything". It does not effect on whether you have a custom domain or not in your web app service.
If you want to use client cert authentication with Azure app, you can refer to How To Configure TLS Mutual Authentication for Web App.
If the server has requested client certificate in its server hello and the client cert has signing capability, then it is expected to send the CertificateVerify message to the server. It contains signed hash of all messages from Client Hello till that point which are buffered on the server side. The server TLS layer will decrypt this using the client public key (which is in the Client certificate received earlier) and compare with its calculated hash. It will call back to application layer if this fails.
The application needs to handle it at that point and return its own error or continue with the session. https://www.rfc-editor.org/rfc/rfc5246#section-7.4.8
One example of this with Wolfssl library is https://github.com/wolfSSL/wolfssl/blob/14ef517b6113033c5fc7506a9da100e5e341bfd4/wrapper/CSharp/wolfSSL-Example-IOCallbacks/wolfSSL-Example-IOCallbacks.cs#L145
How can we limit the number of accepted client certificates when doing mutual TLS with Azure web apps?
I want to be able to control the trusted issuers list sent to the web browser so that list of allowed certificates can be filtered in the browser. This was possible in IIS and with Azure Cloud Service I believe but how can we do it in a web app?
Schannel documentation for this in Windows Server 2012:
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786429(v=ws.11)
What we basically want to do is set the content of the certificate_authorities field in CertificateRequest sent by the server to the browser in the TLS handshake as stated in RFC5246.
I've posted a feature request for this:
https://feedback.azure.com/forums/169385-web-apps/suggestions/35566390-limit-number-of-accepted-client-certificates-when
In IIS 7, I've created an https binding for a site, and I'd like to require client certificates for https and still keep my http endpoint.
That is to say, I'd like to require client certificates for my https endpoint without requiring SSL across the board and disallowing access to my http endpoint (via "require SSL" in SSL Settings). Is this possible?
Client certs are usually used for 2-way SSL, so not just the server but the client is also encrypting the traffic with it's private key.
If you don't want to enforce https across the board, then the one thing you can try is to accept the client cert ( see SSL settings ) then implement the cert validation in your application.
See Request.ClientCertificate on MSDN for more details
if (HttpContext.Current.Request.IsSecureConnection)
{
// it's SSL, so check the client cert
bool authorized = IsClientCertAuthorized(HttpContext.Current.Request.ClientCertificate)
}
Then implement that method as needed.
Note: I haven't tested this, so please comment if you've tried.