I have a cloud service and an Azure APIM instance with a self signed client cert setup on them (the cert has intended purposes of server auth and client auth).
Each API within the APIM has the client cert setup on its security. However, when I perform the call the following comes back in the trace.
"messages":["Error occured while calling backend service.","The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.","The remote certificate is invalid according to the validation procedure."
Is there anything I am missing here, searching online and cannot see anything obvious.
Yes you are correct, the option is not available in the portal to allow self-signed certificates. Here is a blogpost by Sasha Rosenbaum: http://divineops.net/enable-self-signed-certificates-in-azure-api-management-services/
Here basically you are skipping the certificate verification using "skipCertificateChainValidation" attribute.
You can create a backend entity through power shell scripts to skipcertifioc
Related
I have an App Service that's protected by a TLS certificate. It worked fine with small payloads, however, it started failing with larger payloads.
According to an article, I enabled certificate negotiation for my API Management Service:
https://notetoself.tech/2019/06/13/api-call-with-client-certificate-policy-failing-to-execute-due-to-message-size-on-azure-api-management/
However, it still randomly fails with certificate negotiation error, as seen below:
Important - I do not want to use client authentication between browser <-> API management. I'm using it only between API management <-> App Service.
I could not find any information on this substatus 72 code. What does it mean and can it be fixed? Is Azure client certificate authentication broken and won't work with large payloads?
The Negotiate Client Certificate checkbox will not help here as this is for the mutual auth between the client and your apim service where your problem is between apim and app service. Your app service should force apim to exchange the client certificate during the initial SSL handshake rather than waiting until it is needed.
This problem is not related specifically to azure, see this
https://techcommunity.microsoft.com/t5/networking-blog/https-client-certificate-request-freezes-when-the-server-is/ba-p/339672
The issue description to me or at least to how I understood it does not match with the error code as the 17 substatus code means that the client certificate has expired or is not yet valid.
See this https://www.google.com/search?q=403.17+http+code&oq=403.17+http+code&aqs=chrome..69i57.9265j0j7&client=ms-android-samsung-gn-rev1&sourceid=chrome-mobile&ie=UTF-8
And this https://techcommunity.microsoft.com/t5/iis-support-blog/client-certificate-revisited-how-to-troubleshoot-client/ba-p/348053
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.
Is it possible to have a custom B2C policy call a REST API that uses a self-signed cert?
Currently, using the Web.TPEngine.Providers.RestfulProviderRestfulProvider to call a HTTPS REST API that uses a self-signed cert, I get the following errors in the Application Insight logs...
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The remote certificate is invalid according to the validation procedure.
Is there a metadata item I can use to have it ignore TLS verification?
If not, how to I add my cert to a B2C trust store?
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
I have a Logic App that calls a REST API via HTTPS.
The REST API is protected by a custom SSL certificat provided by a custom authority.
When I call it from the Logic App, I get a TrustFailure error, which is a normal situation.
But is it possible to add somewhere in Azure the trust chain in order to bypass this error?
It was confirmed by Microsoft that it is not possible to add my own authority certificates in the list of trusted authorities.