Microsoft docs say to use something like clustername.eastus.cloudapp.azure.com, but what about custom DNS for the cluster?
Will the certificate properly validate or should the custom DNS (i.e. clustername.domain.com) be used?
The dns provided by the docs is just an example, I don't think you will be able to register a certificate against a domain you don't own like .azure.com.
In this case, you will register a certificate against a domain you own, and you either:
Register a CNAME record on your damain to redirect to the cluster domain clustername.eastus.cloudapp.azure.com or
Configure the DNS A Record to point to you cluster Load Balancer IP
In the demo, the Commom Name is just used to identify the certificate installed in the node(vm) certificate store.
The following links describes the use of certificates in more details:
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-creation-via-portal
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-security-update-certs-azure
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-windows-cluster-x509-security
Related
I am tryin to create a Google Managed SSL Certificate for my compute engine instance. However, I am required to enter a domain. The issue is, I do not have a domain associated with my instance, I only have its external ip address.
How can I use the ip address of my instance for the certificate, or how do I associate it with a domain?
You might be confusing what Google is asking for.
In order to create an SSL certificate, you must own / manage /control a domain name.
Next, in order to use the SSL certificate that Google created (or by other means such as Let's Encrypt), you map the Google Service, such as a load balancer, to a backend such as Google Compute Engine VM instances.
If your goal is to create an SSL certificate using an IP address - you cannot. SSL certificates require a domain name. There are exceptions to this, such as using a machine name to create a self signed certificate, but this does not apply to your situation.
Another important item. Once you create a Google Managed SSL certificate, you cannot use it on your VM instance. You can only use it for Google managed services such as Load Balancer. The Load Balancer will then sit in front of your VM instance.
If your goal is to create an SSL certificate that you can install on your VM instance, look into Let's Encrypt. Let's Encrypt is simple to work with and their certificates are free. You will still need to own a domain name, but you will be able to control where it is installed.
Once you install a Let's Encrypt SSL certificate, you modify the DNS servers that your domain registrar setup to point your domain name to an IP address.
Say, for example, I have an Azure web app named MyApp and is hosted on Azure as MyApp.azurewebsites.net. It's my understanding that there is nothing I need to do to secure the URL with SSL, as it's done, by default, with a single certificate. So I can already have my users access the app via https://MyApp.azurewebsites.net, and it will be secure right out of the box.
However, say I have another URL named www.MyApp.com that I want to point (redirect) to https://MyApp.azurewebsite.net. Do I have to secure www.MyApp.com with a certificate?
Do I have to secure www.MyApp.com with a certificate?
Yes, we could get more detail info from the official document .
To secure your custom domain name with HTTPS, you bind a custom SSL certificate to that custom domain in Azure.
Before binding a custom certificate, we need to do the following:
Configure the custom domain - App Service only allows adding a certificate for a domain name that's already configured in your app. For instructions, see Map a custom domain name to an Azure app.
Scale up to Basic tier or higher App Service plans in lower pricing tiers don't support custom SSL certificates. For instructions, see Scale up an app in Azure.
Get an SSL certificate - If you do not already have one, you need to get one from a trusted certificate authority (CA).
Yes, if you use a custom host name, then you will need to have a certificate for it. There is really no way around this, based on how SSL works.
I see that we need to setup our DNS to point to our new router with SSL configured. My question is can we just use the CloudBees DNS entries if we don't have our own domain name? I.e. is there a way to point myapp.mycompany.cloudbees.net to the router with my SSL cert setup on that? Or do I have to go purchase a domain name from a 3rd party provider?
No, you will have to purchase a certificate for your router/IP service.
We are looking into a shared SSL service for this (which will probably do what you want) - this requires a flattening of names, however, as SSL certs aren't issued with 2 levels of "wild cards" at this time.
We would like to setup an application on Windows Azure at abc.cloudapp.net which would have a CNAME record for www.mydomain.com pointing to it and then allow clients to do the same. Our application would then look at the requested URL and then pull out relevant data based on the requested domain (abc.theirdomain.com or www.theirotherdomain.com).
Our initial tests show that this should work, however the problem lies in that we need the site to be secure. So we'd like clients to be able to setup shared SSL certs with us that we would upload to our Azure subscription that then allowed them to create a CNAME record (abc.theirdomain.com or www.theirotherdomain.com) that points to either www.mydomain.com or abc.cloudapp.net.
Is this possible?
Edit: I'm not sure if this is the same question as Azure web role - Multiple ssl certs pointing to a single endpoint.
We've used a multi-domain certificate in this situation - see http://www.comodo.com/business-security/digital-certificates/multi-domain-ssl.php for details. This will work for up to 100 different top-level domains.
The problem with a multi-domain certificate is that it is more expensive than a "normal" certificate and that every time you add a new domain, you will have to deploy a new package with the updated certificate.
On the other hand, you could have multiple SSL certificates (one for each domain) and then the answer you seek is here Azure web role - Multiple ssl certs pointing to a single endpoint.
No, I don't think your setup would be possible with a single SSL cert. In general, SSL certs are tied to the hostname (e.g. foo.domain.com and foo.domain2.com need different certs). However, you can purchase a wildcard SSL cert that will help if you use the same root domain, but different subdomains (e.g. foo.domain.com and foo2.domain.com can share a wildcard cert).
So, in your case, since you are allowing different root domains, then you need a different SSL cert for each. If instead you choose to allow different sub-domains on same root domain, you can get away with the wildcard cert.
I've asked my provider for a SSL certificate. They said the CSR must be generated from a host having the ip address which blongs to the certificate. Otherwise it will not be vaild later.
As far as I know one can only assign a CNAME to a load balancer and it is not possible to generate the CSR on the load balancer. Apart from that the lb ip might change. So do you get your valid certificates?
Regards,
Jim
You don't have to generate the CSR on the load balancer. You only have to generate it with a name consisting of the required domain name. You can do that anywhere.
Jim, I had the very same question as you. This is my first foray into the realm of multi-server deployments with SSL.
I found this: http://www.martfox.com/customer/knowledgebase/140/Why-a-SSL-Requires-Dedicated-IP.html
It looks like it is commonly said that you must have a static IP address to run ssl, but it really looks like you don't need a Static IP as much as an IP that you are the only one using at the time. The IP address is not needed when signing a certificate, or creating a signing request. It is not attached to your keys in any way, so you change Static IP addresses or even move hosting providers without reissuing your SSL cert.
It appears that the limitation is because VHOSTS and other server aliasing methods don't have access to the HTTP request string before they have to connect the SSL layer, so they aren't able to route it like they do unauthenticated requests.