I'm using an Azure Application Gateway v2 to route traffic to a backendpool containing VMs running some docker container hosting an aspnet core webapi. The application is listeing in port 443.
The gateway listener is configured to accept HTTPS connections. A pfx certificate has also been added.
The HTTP setting of the gateway is configured as follow:
I've provided, hopefully, the correct root certificate for the setting. I've exported the certifacte as described here:
https://learn.microsoft.com/de-de/azure/application-gateway/certificates-for-backend-authentication
All VMs from the backend pool use the same certificate as the gateway listener.
When calling the api using a C# application or open a specific url within a browser, the connections seems to be trusted.
But I get an error when calling the api using postman with endabled SSL cerificate verification.
Error: unable to verify the first certificate
A check on sslhopper.com also indicates an issue within the chain.
I got further information doing a chekc on digicert.com.
TLS Certificate is not trusted
The certificate is not signed by a trusted authority (checking against Mozilla's root store). If you bought the certificate from a trusted authority, you probably just need to install one or more Intermediate certificates. Contact your certificate provider for assistance doing this for your server platform.
I'm really stuck in resolving the issue. All helpful hints are very welcome.
The production environment, running on a Windows Server, wihtout the Gateway but the same certificates is valid. So the issue must be somewhere in the gateway configuration.
The issue is resolved. The crucial clue was delivered from a blog post.
http://blog.repsaj.nl/index.php/2019/08/azure-application-gateway-certificate-gotchas/
Gateway V2: the importance of the certificate chain
I did a new export of the pfx certificate including the whole chain and uploaded it to the gateway.
If the cert is not trusted, then you need to check the Application Gateway Listener. Make sure that you are not using Basic listener.
If you are using multi-site listener, make sure that the host name which you have mentioned matches with the certificate CN
Related
I want to use Azure Application gateway for TLS termination. When trying to upload my PFX certificate to an Application Gateway Listener I receive the following, non-informative, error message:
Failed to save application gateway changes
Failed to save configuration changes to application gateway 'main-backend'. Error: Data must be specified for Certificate main-backend/cert4.
I am using a certificate issued by LetsEncrypt and converted to PFX using openssl. The certificate file looks proper the certificate password I passed to Azure is the right one.
Can someone tell me what's the issue here? Thank you!
See SSL Cert Error in Azure Application Gateway for similar discussion.
My experience aligned with that discussion: the certificate just seemed to take a little while to deploy. No issues beyond the "disappearing rule" described there. Recreated the rule after a little while (and updated NSG to allow incoming on 443) and it flowed to backend pool (in my case: TLS offload on Gateway to HTTPS on backend).
I have created the Azure Application Gateway with HTTPS backend.
The problem here is the health check is showed healthily.
But when I connect to Application Gateway it returns 502
I check directly to the backend server but it still fine. HTTP Backend works fine also, only self-signed HTTPS backend got the problem.
Do you have any idea or troubleshooting way for this?
This could happen in the scenario that AppGW v2 when the client receives 502 through the Application Gateway when the back-end is Healthy and no Request Time-Outs.
You could first check these common scenarios, Also you could consider two cases of the health probe.
Default Probe:
AppGW v2 will always show the back-end as healthy when the probe used is the default. So ALWAYS verify if the back-end is really healthy.
Custom Probe:
In this case, the AppGW v2 is supposed to be showing the right health of the back-end.
Furthermore, Authentication Certificates have been deprecated and replaced by Trusted Root Certificates in the Application Gateway v2 SKU. Read more details here.
If the certificate is self-signed, or signed by unknown
intermediaries, then to enable end to end SSL in v2 SKU a trusted root
certificate must be defined. Application Gateway will only communicate
with backends whose Server certificate’s root certificate matches one
of the list of trusted root certificates in the backend http setting
associated with the pool.
Note
The self-signed certificate must be a part of a certificate chain. A
single self-signed certificate with no chain is not supported in V2
SKU.
You can also check if the back-end returns the complete chain of Certs to AppGW via any of the SSL Checkers Online: https://www.sslshopper.com/ssl-checker.html
More references:
Generate an Azure Application Gateway self-signed certificate with a custom root CA
Create certificates to allow the backend with Azure Application Gateway
I am playing around with Azure API Management as a SOAP passthrough. I was hoping to get some analytics in place to preview the service.
My trouble is that my client endpoint has SSL validation in place. I can't figure out how to load the .cer file in Azure to satisfy this requirement. At the very least I was hoping to find an option to turn off SSL validation (like I can with curl or even postman).
any one found a way to accomplish this?
API Management provides the capability to secure access to the back-end service of an API using client certificates. Below guide shows how to manage certificates in the API publisher portal, and how to configure an API to use a certificate to access its back-end service.
How to secure back-end services using client certificate authentication in Azure API Management
If you are calling the API Management service with https then the certificate that is presented will match the host name that you are calling with. I'm assuming you were able to change the client to point to your service at https://{servicename}.azure-api.net ?
Or did you change your local hostname file to make that happen? If that's the case, then that is why you are getting an SSL error. Without being able to re-compile your client you cannot disable the SSL validation.
You could configure the custom domain in API Management and if you have access to the certificate, you could attach it to the custom domain. However, you would actually have to change the public DNS for the domain to make that work. I don't think you can enable a custom domain in API Management, provide the certificate and only use your local hostname file to do the mapping. But I will check.
The steps under 'Scenario 7: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel' in Troubleshooting 4xx and 5xx Errors with Azure APIM services is what worked for me. I'm using this approach to bypass validating the SSL cert until I switch from using a self-signed cert to a CA signed one.
https://www.ssllabs.com/ssltest/analyze.html?d=recruit.equitysim.ai
Situation:
A client needs to access our site over a secure connection but is unable to do so because of a problem with our certificate.
We purchased a wildcard certificate and set it up as per the documentation. If you notice in the provided link, our certificate is trusted.
We are using the Azure App Service to host our website on a paid level that includes custom domain and SSL support.
Problem:
According to the test, it appears that Microsoft's SSL certificate is not trusted - alternative names mismatch (See Certificate #2). We believe this to be the reason why our client is unable to access our site.
Any thoughts on the matter? We know it isn't an SNI problem because we have another site that is hosted on a VM that also requires SNI support and they can visit that site just fine.
I have deployed the thinktecture identity server in the windows azure website role.The issue I am facing is with the SSL certificate.If I don't have a custom domain name I am forced to use *.azurewebsites which already have a certificate from microsoft and the app pool account is not able to read the private key of this certificate so it's throwing an error.
Did someone have the same issue or any ideas about what I can do to resolve it.
Thanks
The SSL and signing certificate don't need to be the same. Use the MS SSL cert (for now) and generate a separate cert for signatures. That cert can then be uploaded so that you can programmatically access it.