SAN or Single Domain Certificate? - security

I want to use a multi-domain SAN certificate for 5 of my public-facing domain. All of these domains point to the same ingress server (SSL is terminated at LB), but the backend may be different.
Now I want to understand if SAN is a good choice or I should go with a single domain certificate for each of the domains considering the security?.
If I go with a single domain certificate, does the compromise of one domain affects all other domains since all are terminated to the same ingress server controller?

Related

Azure SSL Certs Can I change the subdomain later?

I don't quite understand SSL certs. I have a website, www.contoso.com , from WIX, and then I have a subdomain, book.contoso.com , as an Azure web app.
I want to make the subdomain secured, and I was going to purchase an SSL cert from Azure. I was thinking that I might change the subdomain later, as in the "book." part. I was thinking that I might even make the subdomain my main website, as in point the "www." towards the Web App.
If I purchase the SSL cert, can I do this, change the subdomain and will the cert still be valid?
Thanks
Get a Wildcard SSL certificate to secure the domain name and unlimited subdomains under a single SSL installation. Azure supports third-party Wildcard certificates, but I'd consider a cheaper option from an SSL vendor than the one offered by Azure.
When you request the Wildcard certificate, add an asterisk (*) in front of the domain name you want to secure. For instance, *.contoso.com. This way, you can secure as many subdomains as you want.
The trickiest part is to install your Wildcard cert. Here's an Azure SSL installation guide you may find useful.

Service to add HTTPS to an API without my own SSL certificate or domain

I have an api served at a hypothetical address http://82.12.61.115:8000 (note the port).
I want to have a domain point at that IP address and then secure that domain with an SSL certificate.
Is there any service I can use (e.g. AWS) to do this without buying the domain and SSL certificate? Since it is just an API, it doesn't have to be pretty, it can be a subdomain of another domain as long as it's secured.
On a related note, will using port 8000 be a problem (as opposed to 80 or 443)?

Azure Traffic Manager and SSL Certificates

I have 6 different micro services with an Azure Traffic Manager setup for each of them. The services are running in 3 different regions to improve their performance but I need to come up with the certificates for the Azure Traffic Manager.
I have seen that there are two options available in the Azure Portal: The Standard and the Wild Card. While the latter is much more expensive, I was wondering if the same SSL Certificate can be used in all my 6 services so in the end, I will save money.
All my sites are like this:
http://foo1.trafficmanager.net
http://foo2.trafficmanager.net
http://foo3.trafficmanager.net
http://foo4.trafficmanager.net
http://foo5.trafficmanager.net
http://foo6.trafficmanager.net
As you can see the, the domain is the same (I do not have any custom domain, just the by default trafficmanager.net), so I am wondering whether one certificate will be enough. I have not seen any information about the wildcard certificate and it is pretty expensive to just give it a try...
Also, is there any security concern if I use the same certificate for all the sites? Is there a best practice recommendation? 1 certificate per site vs. 1 certificate for multiple sites.
Lastly, if I decide to use Custom Domains in the future, will I be able to reuse the issued certificate? (the domain will not be trafficmanager.net anymore)
Actually, a valid SSL certificate must match the access FQDN domain name. One Standard certificate only could be used for one FQDN domain name, such as "foo1.trafficmanager.net" while one WildCard certificate could be used for all like "*.trafficmanager.net" FQDN domain name, so usually we use the same WildCard certificate for all different services.
If you use Custom Domains in the future, you need to deploy new certificate to match the new Custom domain.
You can get more details about SSL Certificate Names

Azure Application Gateway - Multiple SSL Certificates?

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.

Supporting SSL for multiple catch-all sites in IIS

Scenario
We have a multi-tenant SaaS application deployed on a VM hosted with a service provider. We have multiple domains pointing to this VM (let us call them abc.com and xyz.com). Each of our tenant gets a unique sub-domain URL from one of these domains.
In our IIS installation no domains are explicitly defined - as a result, when a request hits the IIS, as no domains are defined, all requests are automatically routed to the default site.
With this arrangement, we are able to serve a any number of sub-domains for each of the primary domains pointing to the VM without having to explicitly create these sub-domains. For example, t1.abc.com, t2.abc.com, t3.xyz.com, t4.xyz.com are all served by our application without having to create these sub-domains in IIS instance.
In our application, when we get the request, by checking the requested URL, we can easily identify the tenant from which the request is coming. All further data access is automatically restricted to the data created by the particular tenant.
Issue
We need to provide secure communication to all our application users through SSL. We can purchase wildcard SSL for each of the domains (viz abc.com, xyz.com). Now the issue is, how do we deploy multiple SSLs on a single website/application defined in IIS?
This will require us to have two separate sites defined in IIS for abc.com and xyz.com. Unfortunately, these will not be "catch-all" sites for the corresponding sub-domains. By default, IIS allows only one "catch-all" site.
From what I understand from some of the posts, we can have multiple "catch-all" site (for separate domains) in IIS, provided each of them is bound to a separate IP address. Though I could not find any document providing the steps for the same. Can someone point me to the document / steps for doing this?
It is not necessary to have 2 separate boxes for abc.com and xyz.com domains. You can request your CA to combine all DNS records into single SSL certificate with all required Subject Alternative Names SAN.
We also ran into this problem before and SAN certificate worked really well with our multi-tenant configuration. I would also recommend to use load balancer like Nginx for SSL offload to serve your client faster and even more secure. In this case you can just point new client to the Load Balancer.

Resources