I am trying to move our API Management instance behind the application gateway. I created a private dnszone on which the API management ETC is listening. I created Self Signed certificates for this private DNS zone0.
Uploaded the root certificate to the certificates tabs under security, as well as under the HTTP(s) settings tab of the application gateway. however my custom healt probe and health check keep mentioning that the CN Name does not match that one of the backend.
I have to mention that hostname of the listener is a different hostname (our public domain name) than the hostname i used on the private DNS Zone. Is this a problem?
You have to add the same custom domain used by application gateway to the api management service.
Api management is multi site service so it does not respond to the custom host names that are not defined under its custom domains because simply it does not know to which component/site it has to route the incoming request, also the the same extracted .CER certificate of the pfx certificate uploaded to api management should be added to the backend http settings for whitelisting purposes if you chose end to end ssl encryption, if you add a different certificate you will get a certificate mismatch error.
Related
Environment- Established the connection between Azure App Service and OnPrem Network and vrified the connection.
Requirement - There is API hosted in OnPrem and with DNS name and HTTPS enabled (https://test.com/GetData)
But OnPrem API cannot be accessible from Azure API using DNS name and getting error like Hostname cannot be found.
But When I mention the Onprem API IP address (https://12.34.34.3/GetData), it seems communication established but ssl error - The SSL connection could not be established.
What would be the best solution here.
Regards
Abdul
Reason for "Hostname not found error" is the custom domain is not mapped to the Azure App service properly.
Please go to "Custom Domains" and check if the custom domain is added or not.
If not added, please follow the below procedure to add custom domain :
please click on "+ Add Custom Domain"
enter the domain and click on validate.
Add CNAME and TXT records in your DNS domain to verify domain ownership.
Click on "Add Custom Domain"
After adding the custom domain, the custom domain is still unsecure. You need to add the SSL certificate.
To add SSL certificate, please follow below procedure :
Go to TLS / SSL settings and click on "+ Add TLS / SSL Binding"
Select your custom domain and import the .pfx or public certificate for you domain and click Add.
Go to Custom Domains section and click on "Add binding".
Select the certificate of your domain and TLS/SSL type as SNI.
Click on "Add binding"
Now, you can access API using your custom domain which is secured.
When an app hosted on Azure App Service and tries to connect to a remote endpoint over SSL, it is important that the certificate on the remote endpoint service is issued by a Trusted Root CA. If the certificate on the remote service is a self-signed certificate or a private CA certificate, it will not be trusted by the instance hosting your app and the SSL handshake will fail with this error.
Possible solutions are:
1: Remote endpoint service must use a certificate issued by Trusted Root CA.
2: Host the application on App Service Environment (ASE) where you can upload your internal CA root certificate and use WEBSITE_LOAD_ROOT_CERTIFICATES appsetting to load it into Trusted Root store.
We have been working on a flow of upstream services on Azure. The following is the architecture:
User -> DNS -> Azure CDN -> Azure Traffic Manager -> Frontend Load Balancer (Firewall NVA) -> Azure Application Gateway -> Backend Pool (VM-Webserver)
The above flow was designed for a client and we are provisioning the same. The entire end to end flow works with HTTP requests.
But for HTTPS with SSL, the flow works only till traffic manager, as soon as we add CDN in the flow, it gives error, 'Request cannot be served', when checked in browser, it shows 502 bad gateway in developer tools
What we have seen so far:
The end to end flow is working seamless for HTTP requests For
HTTPs/SSL requests following configs have been done:
a) CDN : We have a profile with Custom Domain and HTTPS and Certificate enabled over it.The profile has both 80,443 enabled
b) Traffic manager : Endpoint set to port 443
c) Application Gateway : Plan to use end to end SSL encryption
i) Listener is on 443 port and has a pfx certificate
ii) HTTP setting with HTTPS and has a cer certificate from the original webserver
We have tried different combinations of configuration with CDN and traffic manager but doesn't seem to be working. I need this flow to be working end to end for HTTPS requests. This is for a prod migration to Azure.
Sorry for not following up and reverting on this.
As for the above issue and requirements, it was resolved.
Following were the steps taken:
CDN was configured with Origin type was select as Custom Origin - Original Hostname was given as traffic manager URL For Eg. abc.trafficmanager.net. Origin Host Header was left as blank
For Traffic manager profile changed the endpoint as Azure endpoint selected Target resource type as Public IP Address and added the public IP address of Load Balancer
For Application Gateway, it had to be made sure that we used PROPER CA CERTIFIED CERTIFICATE for end to end SSL encryption, we were trying it with self signed one hence did not work. We purchased one and used it, CDN responded as expected
Another important observation was that, for Application gateway in the HTTP settings (i.e. backend settings), the same CER certificate can be used for multiple websites for backend server certificate whitelisting.
The certificate (cer) that you wish to use, set it as the default certificate on your server, say for a particular website named abcxyz.com. Then the certificate of abcxyz.com can be used for whitelisting the backend for all the websites on that server
In short, app gateway backend only checks if the certificate (cer) is valid, it has nothing to do with the hostname or the certificate is of which domain, if the certificate matches and is valid, it is whitelisted
So folks, with all the detailed study and trails with logical reasoning, we were able to get the same exact flow as mentioned above working for both HTTP and HTTPs, with SSL encryption as well as SSL offloading for application gateway.
Thank you once again for all the support and suggestions !!
I have created Windows Server VM in Azure and deployed my site to IIS, which is now accessible at https://mysite.westeurope.cloudapp.azure.com/
however I get certificate error when I try to visit it from outside the vm.
how do I configure the VM to have proper https without certificate errors (just like app service - mysite.azurewebsites.net)?
As the comments from micker #micker, you can't get an SSL certificate for this subdomain westeurope.cloudapp.azure.com which is owned by Microsoft.
Since you host your websites on Azure VM, you could purchase a domain then get an SSL certificate for your own domain, then bind the SSL certificate to your custom domain in IIS on the Azure VM. You can either purchase that certificate through Azure or an external provider or get a free SSL cert from Let's Encrypt.
However, if you just want to have a test in your test environment, you can use a self-signed certification with this DNS name like vma.centralus.cloudapp.azure.com. You can follow steps in How To Create A SHA-256 Self-Signed Certificate on the Azure VM then export this cert .cer format file on the Azure VM and import the .cer cert under the mmc---certificate---local machine---Trusted root certification Authorities on the machine where you want to access the websites. Please note this It's not recommended to use self-signed cert in your production environment.
I had same issue, and I found resolution without custom domain using following additional azure settings.
create Azure WAF, add custom rules to deny if not in IP list - this is if you need ip whitelisting, useful if your main domain uses akamai or other edge routing to point to external hosting of subdomains, you can use whitelist to restrict access to the akamai or other servers, though this takes some big lists you must paste of ranges one row at a time. Set any other web app firewall rules you want enforced for allow/deny.
Create Azure Front Door named like you want as an endpoint url e.g. myappfrontdoor will make myappfrontdoor.azurefd.net. in backend pool specify the your public-ip shared dns name (see step 3) like myapptest..cloudapp.azure.com.
This is the important step : in Settings at top of front door designer, disable cert validation. in routing rules config, no condition, forward to backend pool setup in prior step. This ignores the fact that you cannot cert your cloudapp.azure.com endpoint, and wraps it with a *.azurefd.net certificate.
In your azure firewall, Edit NAT rules, set rule name myapp-web-fd-... , tcp, ip address, 147.243.0.0/16 (this is Azure's front door backend ip range). destination should be the firewall's own public ip. destination port 443, translated address should be the target vm's azure internal ip, target port - service port.
Now you will have a site like myappfrontdoor.azurefd.net.
Note that Azure Front Door and WAF have their own pricing costs, so maybe it is cheaper for you to buy a domain. Hopefully you are also using Azure Firewall, though expensive. If not, one could point to public ip directly on NSG or on vm itself but I wouldn't skip having a firewall for a public server. There is a standing Azure enhancement request to get Azure Front Door to recognize certificates, but it was triaged 2 years ago and still not added, so not sure if it will be worked. If it ever does get worked, devs could make own cert auth and self-signed cert with expirations to more securely hook front door to azure internal vm. For now, have to rely on the front door backend setting, waf, and azure firewall to have these things routed.
There are some options in Akamai and other edge routing systems to import cert and self-created authority sort of, but I've not tried that yet, so cannot confirm this would cleanly wrap your azure site without cert errors. You can make a self-signed authority using openssl commands as noted in other posts out and about on the web.
The simplest and cheapest option is to purchase a domain and use a cname dns record to map your new domain to your Azure subdomain address - an "A" record is not required. Also per answer above, a WAF is expensive and possibly unnecessary for a test set up (but a requirement for a production website). You can use Certbot and NGINX to create a free Lets Encrypt certificate for your domain and assign it to your website.
Adding a Public IP Address, Load Balancer, and Network Security Group to your Azure Resource Group may also be required to provide access to your website. This is largely how my test configuration is set up except I'm using a Linux VM, have a single wildcard certificate, and use NGINX to reverse proxy 3 websites.
I am going a bit nuts here, as I can't get it to work properly.
Environment:
App Gateway v2 (WAF)
App Service with custom domain
End 2 End SSL
Goals:
Manage external SSL Certificate on App Gateway only
Self-signed SSL on App Service
End2End SSL
Setup:
BackendPool set to App Service (*.azurewebsites.net)
FronendIP configured externally
Custom Probe with external Hostname set, Https
SSL Listener with FrontendIp/Port(443), host name and external valid certificate
Imported the self-signed certificate (cer) into the Trusted Root Authorities in App Gateway (powershell)
Http Settings -> Https, Port 443, timeout 30, custom probe, host name set to external address, TrustedRootCertificate assigned (powershell)
Basic Rule with SSL listener, Backend pool, Http Setting applied (powershell!)
Now this is probably the bit that throws me off, because:
Powershell says backend http settings are applied
The portal says so too on the "overview" page of the Rule
When editing the rule however, the "Http setting" field is empty, and there is a red exclamation mark:
"There are no http settings with pick host name from backend address
set. Create a new http setting with pick host name from backend
address set and then try again."
However, I don't want this setting, because that would access the back-end as "*.azurewebsites.net", right? I need the backend to be accessed by the external hostname (*.mydomain.com).
Symptoms:
Backend health in Portal "Healthy"
Accessing the external hostname -> 502 Bad Gateway
I had this working by using "pick host name from backend" and using the azure hostname (*.azurewebsites.net) for internal access, unfortunately our application really needs the external name (and for context: when finished, there will be multiple external names pointing to the same application, and the application changes behavior depending on which hostname is used)
More notes:
The App Service is configured with SSL, the self-signed certificate is only assigned to the custom hostname with "SNI"
This turns out to be a side-effect of "V2" being in "Preview" (as of 2018-12-13). The "Preview" label is not immediately apparent. The Azure Portal does not mention anything about it being in Preview, and all the Documentation talks about "Autoscaling" being in Preview.
Turns out, "V2" is meant with the "Autoscaling" feature, so the whole "V2" thing is in Preview.
We have re-done the exact same setup with the "V1" app gateway type, and it works as expected.
I wish they would clearly label preview things in the Portal, too...
When editing the rule however, the "Http setting" field is empty, and
there is a red exclamation mark:
Similar scenario in Github here. It seems WAF_v2 won't accept .cer files when setting HTTPS Settings. When you whitelist the CER cert with Http settings using PowerShell, it is not reflected in the portal. A possible reason is that application Gateway does not support Authentication Certificates for the WAF_v2 tier. You can read the known-issues-and-limitations in Application Gateway with WAF_v2 and End to end SSL with the v2 SKU.
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.
In addition to root certificate match, Application Gateway also
validates if the Host setting specified in the backend http setting
matches that of the common name (CN) presented by the backend server’s
SSL certificate. When trying to establish an SSL connection to the
backend, Application Gateway sets the Server Name Indication (SNI)
extension to the Host specified in the backend http setting.
If pick hostname from backend address is chosen instead of the Host
field in the backend http setting, then the SNI header is always set
to the backend pool FQDN and the CN on the backend server SSL
certificate must match its FQDN. Backend pool members with IPs are not
supported in this scenario.
About the 502 Bad Gateway error, the backend health is healthy on your side. If there is not a firewall blocking request or response from your backends, I may suggest checking the error on your web server side and make sure the backend is responding to the request sent by Application gateway within 30 seconds(Default value).
You could get more references from troubleshooting steps and diagnostic logs, and metrics for Application Gateway and here.
Hope this will help.
Is it possible to set multiple Domains to point to an Azure Application Gateway Public IP and then upload SSL Certificates for each one that can then Offload on the Application Gateway?
For example if we'd like to have 200 LetsEncrypt certificates uploaded and terminating at the gateway, then forwarding traffic onto the internal VM IPs
Is it possible to set multiple Domains to point to an Azure
Application Gateway Public IP and then upload SSL Certificates for
each one that can then Offload on the Application Gateway?
Yes, it is possible to set multiple domains to point to an Azure Application Gateway Public IP.
It is also possible to upload SSL certificates for each one so that Application Gateway offloads it.
However, there are limits. Please read below.
According to https://learn.microsoft.com/en-us/azure/azure-subscription-service-limits#application-gateway-limits you can upload a maximum of 20 certificates to a single Application Gateway resource, and only one certificate per HTTP listener.
You can however generate SAN certificate through LetsEncrypt and have a single certificate for multiple domains:
Can I get a certificate for multiple domain names (SAN certificates or
UCC certificates)?
Yes, the same certificate can contain several different names using
the Subject Alternative Name (SAN) mechanism.
https://letsencrypt.org/docs/faq/
I do not have experience yet with LetsEncrypt and do not know how to generate SAN certificate through LetsEncrypt.
We have SAN certificate (paid) through another company for multiple domains working in Application Gateway.