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.
Related
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)
I am currently developing a web application to allow customers to place orders.
The way I have choosed to handle the application structure is to split the app in two sub-applications:
1 backend application (the API) that serves only json content
1 front end application (AngularJS in my case) that takes an API url as configuration and serves user content
Now on the server, what I have done for testing, is creating 2 virtual hosts:
app.com
api.app.com
and linked the API to the frontend app.
The problem is that everything will be served over https and, in the current setup, I will need to buy either 2 SSL certificates, or 1 wildcard certificate.
The second solution would be to create a subdirectory on the frontend app (let's say /api) and copy the backend app into it. The advantage would be to get only one single SSL certificate and have everything on the same directory; the /api would be an .htaccess redirect to the backend api.
I think that the "cleanest" solution would be to split the two apps completely and get a wildcard SSL certificate for both, but I'd like to hear if someone have some experience whether one solution is better than another.
The advantage of combining is that you will get to avoid CORS. CORS isn't that bad, but it's another complication. That being said, if you want to expose this to the outside world (allow other web pages to use it), you might want to go through that process anyway.
If you aren't looking to actually expose your API to third-parties, but just keep your layers separate, than I would either look at combining, or even proxying. I've used this architecture to put my services completely behind the firewall, and use mod_proxy or the like to serve my API through my web server. This is useful as it limits the exposure of your API, and solves CORS issues in one go.
If you really want to use SSL between your web server and your API server, you can do a self-generated client certificate between you web-server and your API server.
We have a Web-Application that should interact with a desktop application that has a helper tool character (e.g. no setup, no need for admin privileges). The helper is listening via http/https on a simple port bound to localhost.
The Web-Application uses a SSL certificate. Every customer has a machine on its own for his data. For claryfication: The Web-Application is running on a server, serving one customer but multiple people.
The problem is, the Web-Application cannot reach the helper tool via https (using image or iframe). The main issue is, that the local webserver listening on localhost has no signed certificate. So the web browser is blocking the interaction.
Is there any way to get around this trouble? I think, I cannot get a certificate for localhost, because no one would sign it.
I know, that I cannot use XMLHttpRequest for this, but that's not the point.
The goal is to have a customer friendly - no install - just works - solution. The customer should not do ANY configuration. Just downloading and starting the tool. We'd like to have a direct communication to the tool (e.g. no outbound direction to the web server).
Is the any solution for this?
If it is Active-directory environment , you can create your own CA and sign certificates and distribute them across the domain. also you can add to trusted sites through domain policies this way client side you don't need to configure anything .
I want to migrate an existing On Premise WCF service to Windows azure without asking clients to change anything in thier application like endpoint URL, certificate etc.
PLease let me know if this can be done?
In principal - yes.
The Endpoint Url is dependant on you controlling the domain and forwarding the URL over to Azure (for us, we use a CNAME redirect to the Azure URL). More details here.
For the certificate, as long as you've got an exportable version of the certificate with a Private Key, it should be a matter of uploading the certificate to the server that matches the endpoint URL. More details here.
So, all in all (with these changes in place) it's just a matter of uploading the certificate, redirecting to over to Azure and then letting DNS do its thing. If in doubt, certificates are buttons to purchase, so use that for testing purposes to prove the concept.
I have two webroles, without a WCF communication between them (this is intentionally)
Communication and authentification is one sided. Thus one webrole allways sends requests and the other one allways accepts requests.
To make sure said controller only accepts requests from the other webrole we want to use an ssl certificate.
i installed the certificate - and iam now able to make https requests to said controller.
however this is now active for the whole webrole.
In the final version users should be able to connect to the webrole over https with a global trust certificate for obvious security reasons.
This would require one azure https endpoint.
another endpoint then would be needed for our internal communication ( with our internal certificate).
But: How to restrict the controller which is used only for internal communication to its specified https request? (based on the interrnal certificate)
On the other hand how do i validate on the client side ( the webrole which makes the request) that said certificate was valid ?
Is there a better way to ensure a secure communication between two webroles? maybe using internal endpoints?
Thanks in advance
I think you should look at defining internal endpoints for the role-to-role communication. Something like this should work:
<NetworkTrafficRules>
<OnlyAllowTrafficTo>
<Destinations>
<RoleEndpoint endpointName="InternalTCP2" roleName="WorkerRole1"/>
</Destinations>
<AllowAllTraffic/>
<WhenSource matches="AnyRule">
<FromRole roleName="WebRole1"/>
</WhenSource>
</OnlyAllowTrafficTo>
</NetworkTrafficRules>
If you're communicating between roles through internal endpoints you shouldn't really need to invoke HTTPS.