We are going multi-region for our project and there is a need for us to use an Azure traffic manager to route traffic to each region. Our setup looks like below where our app gateway is exposed via a public IP which I used to configure on the Azure Traffic Manager.
My issue is when I hit the traffic manager URL it give me an SSL cert error, while if I hit the App gateway URL directly it works fine on HTTPS. Looking at the below error I know I need to configure the traffic manager certificate and my question is
Is this needs to be configured somewhere in the traffic manager? OR
DO we need to configure this in the application gateway and change the app gateway ingress in Kubernetes with and also use traffic manager certificate there?
• The traffic manager works at the DNS level, thus as the DNS records pointing to the traffic manager’s public URL aren’t setup correctly, you are getting this error when browsing the traffic manager’s URL. Also, when you are accessing the application gateway URLs independently, they are being accessed successfully as the URLs for the application gateways are hosted on the Azure DNS and independent public IPs are also allotted against their DNS records. Thus, appropriate DNS records to route the DNS access request for the traffic manager’s website need to be updated.
• Since you are using multi region setup in Azure with load balancing features, I am considering that your custom domain and its DNS records are setup in Azure itself. And the URLs for the application gateway are setup as separate endpoints in the form of subdomains in the custom DNS record setup itself. Thus, when you browse the application gateway URLs according to the custom domain URL setup, you can access the application page correctly. With respect to the traffic manager, you will need to create a CNAME record pointing from your custom domain to the ‘*.trafficmanager.net’ domain, while also creating a CNAME record pointing from your custom domain to your generic application gateway URLS.
• Once done, create A host records for each application gateway endpoint pointing to the public IP address assigned by Azure to them. After doing the above, your traffic manager URL should be able to route and redirect the application access requests correctly. For more information, please refer to the community discussion below which specifies the exact details relating to your problem: -
Azure Traffic Manager SSL Setup (not classic)
Related
I need some help to develop this solution in my application.
I have a domain https://my-app-api.com with SSL and there is running my application API.
Every customer who using my application can enter their own Custom Domain for example customer-domain.com and points his domain CNAME to my-app-api.com.
Additional info
My API running on Kubernetes cluster and using DigitalOcean services.
Problem
There is a problem with SSL certificates. Custom Domain that points to my-app-api.com runs only under HTTP not HTTPS. Everything must be done automatically over API. If customer enters a new custom domain and points CNAME to my app domain then I need to provide connection over HTTPS.
How can I get it to run on HTTPS?
Is zerossl.com solves that problem for me?
Do I have to use Caddy or smth else?
customer domain --> CNAME --> your api
Is that correct?
your API has SSL.
Is that correct?
customer domain no SSL.
Is that correct?
If all answer is 'yes', the problem is, your customers.
Your customers need an SSL certificate for their domain, your had done all you need to do about SSL (for your API).
Your customers can use a service such as zerossl.com.
Ant-Media-Server is running on an IPAdress without any domains. We just set up this server to be used for streaming in order to use it from different domains pointing to different servers.
Since all of our domains use ssl, we face the typical connection problem:
mixed Content: The page at 'https://SOMEDOMAIN.com/QUERY' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://1.2.3.4:56'. This request has been blocked; this endpoint must be available over WSS.
Ant-Media already offers tutorials on how to install a Let's Encrypt SSL Certificate but sadly it is not available for pure IP-Addresses.
Apart from the Ant-Media Service, the server doesn't has any NGINX, NodeJS, Apache or other http Servers installed - the plan was just to use it for streaming by calling the IP-Address.
Do you have any ideas on how to solve that problem?
Unfortunately, this is not possible.
The goal of having a SSL is ensure you are requesting the right domain name besides encrypting the content between your users and your server.
Here are some alternatives:
create an endpoint in your own app that proxies data to your server.
Instead of playing the IP address, you can play:
/your-proxy-url?stream=http://yourIp.com:port/....
Note that using a proxy will make all the traffic pass through your web app.
As a reference, if you are using PHP on your website, you can have some ideas from here: https://gist.github.com/iovar/9091078
Create a reverse-proxy in front of your web app that redirects the traffic to your IP address.
Both solutions does not change your Ant Media Server, just adds a new resource between your users and your streaming server - adding the SSL on it.
I have build a saas product with angular 4 integrated with golang rest api and uploaded the build on aws ec2 instance. My project is a multi-tenant based app which loads customers dashboard on merchant-name.mystore.com subdomain but some of the customers asking for custom domain feature like they should be able to load the app on mydomain.com .
I have done the the subdomain part with following code in apache2.conf file so all subdomain loads from apps folder where the angular app files located
<VirtualHost *:80>
ServerAlias *.mystore.com
DocumentRoot /var/www/html/apps
<Directory "/var/www/html/apps">
AllowOverride All
Require all Granted
</Directory>
</VirtualHost>
For custom domain feature I have a section in admin to save custom domain but not sure how should I implement it.
possible method I thought about are
Create virtual host file and update it on each merchant signup with his custom domain
Do it somehow with htaccess file and mod_rewrite
Shopify do it but not sure how they load merchant specific store. Another point kept me busy thinking about is what values should I ask to update
IP address on domain registrar
Name servers ( not sure what it will be for my on aws )
Ask to create CNAME or A record as some of the article suggest
I have a similar setup on a number of SaaS platforms I develop and manage. This type of setup is certainly desirable, as your clients suggest. You should plan to serve each customer site on its own domain, probably also with *SSL, from the begining. In my opinion, this is best practice for a well architected Saas service today.
In reading your question, I think you are over engineering it a little.
For a custom domain Saas app on the same server, you simply open port 80 to all traffic, regardless of domain name. Point all customer domains to app.mystore.com, which is a CNAME to your app endpoint.
The app then reads the HTTP request header, and in that way determines the host name that was requested.
Finally the app looks up the host name in its client database, and locates the client record for the give customer domain.
For example, in Nginx all you need is:
server {
listen 80 default_server;
server_name _;
root /var/www/myservice/htdocs;
}
This server configuration provides a catch all for any domain that points to this endpoint.
That is all the web server should need to allow it to answer to any customer domain. The app must do the rest.
* When you serve a custom domain on an app on this domain, you should plan to serve the SSL endpoint for the domain, eg https://www.mycustomdomain.com. Consider this in your architecture design. Consider also the DNS issues also if your app fails over to a new IP.
The accepted answer is satisfactory but it only skims over the most important part, and that is enabling HTTPS by issuing certificates for third-party domains.
If your customers just CNAME to your domain or create the A record to your IP and you don't handle TLS termination for these custom domains, your app will not support HTTPS, and without it, your app won't work in modern browsers on these custom domains.
You need to set up a TLS termination reverse proxy in front of your webserver. This proxy can be run on a separate machine but you can run it on the same machine as the webserver.
CNAME vs A record
If your customers want to have your app on their subdomain, e.g. app.customer.com they can create a CNAME app.customer.com pointing to your proxy.
If they want to have your app on their root domain, e.g. customer.com then they'll have to create an A record on customer.com pointing to your proxy's IP. Make sure this IP doesn't change, ever!
How to handle TLS termination?
To make TLS termination work, you'll have to issue TLS certificates for these custom domains. You can use Let's Encrypt for that. Your proxy will see the Host header of the incoming request, e.g. app.customer1.com or customer2.com etc., and then it will decide which TLS certificate to use by checking the SNI.
The proxy can be set up to automatically issue and renew certificates for these custom domains. On the first request from a new custom domain, the proxy will see it doesn't have the appropriate certificate. It will ask Let's Encrypt for a new certificate. Let's Encrypt will first issue a challenge to see if you manage the domain, and since the customer already created a CNAME or A record pointing to your proxy, that tells Let's Encrypt you indeed manage the domain, and it will let you issue a certificate for it.
To issue and renew certificates automatically, I'd recommend using Caddy, greenlock.js, OpenResty (Nginx).
tl;dr on what happens here;
Caddy server listens on 443 and 80, receives requests, issues, and renews certificates automatically, and proxies traffic to your backend.
How to handle it on the backend
Your proxy is terminating TLS and proxying requests to your backend. However, your backend doesn't know who is the original customer behind the request. This is why you need to tell your proxy to include additional headers in proxied requests to identify the customer. Just add X-Serve-For: app.customer.com or X-Serve-For: customer2.com or whatever the Host header is of the original request.
Now when you receive the proxied request on the backend, you can read this custom header and you know who is the customer behind the request. You can implement your logic based on that, show data belonging to this customer, etc.
More
Put a load balancer in front of your fleet of proxies for higher availability. You'll also have to use distributed storage for certificates and Let's Encrypt challenges. Use AWS ECS or EBS for automated recovery if something fails, otherwise, you may be waking up in the middle of the night restarting machines, or your proxy manually.
Alternatively, there have been a few services like this recently that allow you to add custom domains to your app without running the infrastructure yourself.
If you need more detail you can DM me on Twitter #dragocrnjac
My goal is to have an Azure App Service, served from a custom domain over HTTPS.
This app receives HTTPS POST requests and should log the remote IP in the process.
I usually get the remote IP address, the IP of the calling client, like this:
HttpRequest request = ...
var IP = request.HttpContext.Connection.RemoteIpAddress;
To have the app served over HTTPS for a custom domain I enabled an azure CDN endpoint.
Now the IP I record is for the CDN server not the calling client.
Is it possible to get the originating IP?
The requests in question are HTTPS POST so CDN caching shouldn't be an issue.
Does the Azure CDN add any headers that could contain such info?
Does adding an SSL cert directly to the App Service change anything?
By testing I've found that Azure CDN adds the X-Forwarded-For header with the client's real IP.
The only mention of this header I've found is in Azure CDN documentation mentioning the header as being reserved.
This article describes how Azure CDN works, and we could know that user request a file via CDN, if the edge servers in the POP do not have the file in their cache, the edge server requests the file from the origin. The user request does not be sent directly from client user to the origin, so as you seen, it records the IP of the edge server instead of the calling client.
I have 2 web roles in a cloud service; my API and my Web Client. Im trying to setup SSL for both. My question is, do I need two SSL certificates? Do I need 2 domain names?
The endpoint for my api is my.ip.add.ress. The endpoint for my webclient is my.ip.add.ress:8080.
Im not sure how to add the dns entrees for this as there is nowhere for me to input the port number (which I have learned is because its out of the scope of the dns system).
What am I not understanding? This seems to be a pretty standard scenario with Azure Cloud Services (it is set up this way in the example project in this tutorial, for instance http://msdn.microsoft.com/en-us/library/dn735914.aspx) but I can't find anywhere that explains explicitly how to handle this scenario.
First, you are right about DNS not handling port number. For your case, you can simply use one SSL certificate for both endpoints and make the two endpoints have the same domain name. Based on which port is used by user request, the request will be routed to the correct endpoint (API vs. Web Client). Like you said this is a relative common scenario. There is no need to complicate things.
Let's assume you have one domain www.dm.com pointing to the ip address. To access your Web API, your users need to hit https://www.dm.com, without port number which defaults to 443. To access your web client, your users need to hit https://www.dm.com:8080. If you want users to use default port 443 for both web api and web client, you need to create two cloud services instead of one, then web api on one cloud service and web client on the other cloud service. Billing wise, you will be charged the same as one cloud service.
Are there any reasons you want to make 2 different domains and in turn 2 SSL certificates? If so, it is still possible. Based on your requirements, you may have to add extra logic to block requests from the other domain.