Multi domain SSL? - ssl

A co-worker told me that when you visit a website over SSL the certificate no longer guarantees that you're actually dealing with the intended recipient. This is due to something called "multi-domain SSL certificates". A quick google search seems to show these exist - but I was always under the impression SSL provided encryption and authentication. Is this no longer the case? Surely this is a step in the wrong direction?

There are wildcard certificates, which allow all hosts in one domain to be covered by the same cert. They're more expensive to get issued (since the CAs wouldn't make as much money as if you'd ordered multiple separate single-domain certs), but when you need to cover multiple hostnames in your domain with ssl, it can be quite a savings.
A properly issued cert will cover at LEAST one host name, like www.example.com. And with wildcarding, can cover *.example.com.
SSL by itself guarantees nothing in the way of identification - simply that the link is encrypted. Any certificate will do that for you - even self-signed ones. What you get with the "commercial" certs is a (theoretically) trustworthy third party saying "we've verified that the person who this www.example.com certificate was issused to really is www.example.com"

In addition to given answer, i would like to add few points about SAN (multidomain SSL). First of all, wildcard is not a multi-domain ssl, it only protects unlimited sub-domains as already explained by Marc.
To protect multiple domains like:
domain.net
domain.com
mail.domain.com
newdomain.com
you will require SAN certificates that start from just $60.

you can configure multi domain with SSL on both UBUNTU and REDHAT by following the document Multi domian with ssl

Related

Can i implement Wild card SSL certificate on Two Domains?

I have Wild Card SSL Certificate and i need to implement it on multiple domains. on first it is being implemented and on second i have to implement. Is it possible that i can implement the same certificate on Two Domains. Domains are hitting the same IP Address, means hosted on same server. But having different Domains first is like: https://erp.example.com and Second is http://app.example.com. Both application are differently hosted on IIS.
Please suggest.
If the certificate is a *.example.com cert, then yes, you can. That is, after all, the whole point of a wild card certificate: to support any domain combination of the base domain.
We do it ourselves.
I'm unsure if that is your actual question though.
If you have enabled your Wildcard SSL certificate for your domain *.example.com then yes you can secure both subdomains erp (.dot) example.com and app (.dot) example.com.
Below resources will help you to install Wildcard SSL certificate on IIS server very easily:
https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=SO19990
https://www.clickssl.net/blog/how-to-install-wildcard-ssl-certificate-in-iis-7
You are questioning about two domains, but actually you have two sub-domains under single domain and if you already have Wildcard SSL certificate, your all sub-domains will be protected. Wildcard SSL issued on *.example.com will automatically secure unlimited number of sub-domains. It does not really matter your sub-domains are hosted on same server or differently, you can secure all with Wildcard Certificate.
What will be secured with single Wildcard SSL;
https://app.example.com
https://erp.example.com
https://anything.example.com
Ps: Wildcard certificate will help you secure sub-domain only first level.

Can we Use multiple domain SSL Certificates on same IIS Web site?

I have one website will be accessed by multiple different domains and will have separate SSL certificates for each.
Is it possible?
IF no then Is there any work around to install multiple certificates for single web site?
Instead of having separate SSL certificate for each domain you can go for Multi domain certificate using Subject Alternative Names (SAN). It will be single certificate with multiple domains. Following image shows SAN certificate.
Image Courtesy : DigiCert
SSL Certificate can only be issued to a FQDN (fully qualified domain name).
You better have elaborated your question with examples. By the way, let me guess and try to answer. As you said “You have one website – will be accessed by multiple different domains” - if I'm not wrong your are talking about one website which may be www.domain.com and multiple domains may be sub-domains like, blog.domain.com, photos.domain.com or anything.domain.com. If I have hit bulls eye, you don't need to get different SSL Certificates because all this domain can be secured with single Wildcard SSL Certificate. Wildcard SSL works on asterisk, so it will issued on *.domain.com and anything in place of asterisk will be covered.
But make a note, Wildcard SSL can work only on single level so something like blog.photos.domain.com will not be secured if you have got certificate for *.domain.com
Different Scenario: If you have something like this, domain.com, domain.co.uk, domain.com.eu etc. and it can be secured with different certificates. It may be costly deal if you have 20-30 or more domains, ideally you can get one multi-domain certificate to secure all these. Visit this article which will help you understand difference between Wildcard SSL and SAN functionality more deeply.

do i need an ssl certificate for testing environment on subdomain?

I can't use my SSL certificate on subdomains because it is for the top level domain www.tld.com only. When I force it on a subdomain e.g. dev.tld.com I get a warning.
What I want to achieve is a development subdomain on the same shared hosting webspace where I can test under real conditions, especially concerning payment systems where an SSL connection is mostly mandatory.
My question is: Do I have to get an extra certificate or is it possible to just click the warning away and make use of https? Am I obliged to buy a certificate in order to use SSL technically? At least it seems to work once I've told my browser to trust the subdomain ...
The warning is telling you that the domain name listed in the certificate does not match the domain name you browsed to. You will still have an SSL connection. Since you are the one that configured the environment, you can ignore the warning.
Having said that, a wildcard SSL certificate is not much more expensive than one for a single domain (shop around!). I would suggest your next SSL certificate be for a wildcard domain (*.tld.com). That will avoid the issue of the warning entirely.

Make subdomain die if not defined on ssl

I am currently running nginx and have an ssl certification that is only on my domain and no sub domains. I do however have some sub-domains I like to use on the non-ssl so I want to keep my wildcard subdomains.
I was wondering if there was a way to make all ssl subdomains die and not resolve to anything. I would make them redirect but because of my ssl certification, the scary error message pops up before the server redirect them. I would rather have the page come up as nothing.
THanks
Because of how SSL works, you will always have a "scary error message" if someone comes to https://sub.domain.com/ and your SSL certificate doesn't list sub.domain.com as one of its canonical names.
The only ways around this are:
old good "Dedicated IP+Dedicated certificate" for every subdomain you host in SSL
Wildcard certificate
Web server with SNI support in SSL and per subdomain certificates
A certificate with SAN propogated with all your subdomains
Which one to choose depends on your budget and how many browser/OS combinations you have to support.
I hope it answers your question, feel free to clarify it if not.

Generating a CSR for root domain (includes www or not?)

I am trying to set up SSL for the first time. I purchased my domain and SSL certificate from Gandi.net. Their docs say
subdomain.example.com indicates the subdomain that you want to
protect. This is the most important part. If you have a single-address
certificate to activate, you should put in the full subdomain (e.g.
foo.example.com). The www subdomain is added automatically by the CA,
for example, example.com will secure both example.com and
www.example.com If you have a wildcard certificate, you should put in
a * for the subdomain (e.g. *.example.com). Wildcard certificates also
secure the raw domain (with no subdomain).
- http://wiki.gandi.net/en/ssl/csr
I am hosting my app on Heroku and their docs say:
The Common Name field must match the secure domain. You cannot
purchase a certificate for the root domain, e.g., example.com, and
expect to secure www.example.com. The inverse is also true.
Additionally, SSL Endpoint only supports one certificate per app.
Please keep this in mind for multi-domain applications and specify a
Common Domain that matches all required domains.
- https://devcenter.heroku.com/articles/ssl-endpoint#acquire-ssl-certificate
These seem to conflict. Please advise!
You'll want to get a certificate from an authority that supports the Subject Alternate Name X.509 extension.
This will let you get a domain with its Common Name set to www.mydomain.com, and an Alternate Name set to mydomain.com(as Lloeki noted, you should provide both names as alternate names).
It depends what Certificate Authority(CA) you have been choosen to purchase certificate.
Some of them provide alternate domain name including "www" like option some of them no.
As you have written above:
I am hosting my app on Heroku and their docs say:
The Common Name field must match the secure domain. You cannot
purchase a certificate for the root domain, e.g., example.com, and
expect to secure www.example.com. The inverse is also true.
Additionally, SSL Endpoint only supports one certificate per app.
Please keep this in mind for multi-domain applications and specify a
Common Domain that matches all required domains. -
https://devcenter.heroku.com/articles/ssl-endpoint#acquire-ssl-certificate
It is true - because yourdomain.com and wwww.yourdomain.com are considered as different domains (multi-domain) and your certificate has to be trusted to recognize both of them. So before generating CSR string please attentively read requirements for CSR string and features provided by a CA.