I have to use SSL for my subdomain as well for main domain. My requirements are to crete sub domain on the go,
for ex
sub1.mydomain.com
sub2.mydomain.com
etc
There is wildcard domain, please explain and also provide the link to buy it ans set up it.
BR
Gopal
Almost all CA offer wildcard certificates. If you purchase a certificate for *.domain.com, it will basically cover your main domain and any first level sub-domains.
I got one from here
Setting it up depends on the type of server you are using. There is a simple guide here
Related
As a complete newbie, I've been skulking through this site for about the past twelve months to find solutions to errors. The following issue has driven me to distraction to such a degree that I decided to join the fun and see if anyone can help.
I have a main site which has an essential SSL certificate. I recently created another site as an add-on domain to the main hosting. However, this means the add-on tries to run as https, causing a security error and blocking most of the html and css document. I'd be very grateful if anyone could offer advice on how to work around this.
The certificates are valid only for the domain specificed in the CN.
However you are not only one with this requirement, so what you can do:
use a wildcard certificate - the wildcard certificates are usually more expensive, but they cover all subdomain on that level (*.domain.com covers www.domain.com, mail.domain.com, ... but not domain.com itself)
use Subject Alternative Name - it is an explicit list of domiains covered by the certificate
I have created a small online market in a sub domain like this:
shopName.mainDomainName.com
I need to install SSL certificate in this shop and possibly other shops in the future.
Can i install once in the main domain and reference that in the sub-domains?
Also, there are many options in SSL certificates that i got confused.
there are Dedicated,Business,and many other plans. from different companies such as comodo,symantech,...
How to choose the right according to my small needs which are simplicity and price.
Thanks in advance for any hint or help.
Based on the comments, you can avail a Wildcard SSL that works for these domain formats
Wildcard SSL
Secures all subdomains but not the base domain itself
Example:
*.mainDomainName.com
Where the * represents any subdomain but not mainDomainName.com
itself.
Subject Alternative Name
Secures all of the specified IP and DNS on the Subject Alternative Name of the Certificate.
Example:
mainDomainName.com
mainDomainName2.com
login.mainDomainName.com
*.mainDomainName.com
As you can see, SAN SSL Certificates offer greater flexibility.
Choose among the given options above that meet your requirements
I run a website affectionaries.com that has a valid SSL certificate hosted by Hostgator.
It has come to my attention that when searching in Google for terms such as "Affectionaries" or "Cupcakes Runcorn" an other domain appears higher up the SERP's using my meta data an is unrelated to my business. If you click the link for (https://www.miamiboxpanama.com/) then it takes you to an insecure warning page! Under advanced it tells you:
www.miamiboxpanama.com uses an invalid security certificate. The certificate is only valid for the following names: affectionaries.com, www.affectionaries.com Error code: SSL_ERROR_BAD_CERT_DOMAIN
I can not figure out what is going on here...
So far I can see that this domain is on the same nameservers and IP address as my site.
Has anyone have experience with this and know a solution to resolve this matter?
www.miamiboxpanama.com resolves to the same IP address as affectionaries.com (192.254.231.2). So both names lead to the exact same web server, and therefore also the exact same SSL certificate. Since that certificate is only for the name affectionaries.com, the browser correctly issues a warning when the name it used was www.miamiboxpanama.com.
This looks like a configuration error at Hostgator. You may want to contact them and ask what's going on.
I would like to have an SSL cert for *. That is, for any domain whatsoever. The idea is to sign it with a custom CA cert, install that CA cert on a target device, and use that device to connect to ip-based addresses (e.g. https://192.168.1.123). There's no DNS available, and the address may be different each time. The browser on the target device should work without warnings, but only as long as the wildcard cert presented is signed by the known CA (which is our custom CA the cert of which was installed on the device), to prevent any possible MITM attacks.
Would browsers understand such a wildcard cert? Is there any other workaround possible to allow using browsers to connect to arbitrary IP-based SSL servers without warning and with MITM protection at the same time (assuming that it's possible to customize the client list of CAs)?
There are two specifications about certificate identity validations for HTTPS: RFC 2818 (the HTTPS specification itself) Section 3.1 and RFC 6125 (a more recent RFC trying to harmonise how this is done for any protocol).
As far as I can interpret RFC 2818, it doesn't forbid it (although I guess it doesn't consider the use case at all):
Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., .a.com matches foo.a.com but
not bar.foo.a.com. f.com matches foo.com but not bar.com.
RFC 6125 generally discourages the use of wildcard certificate altogether (section 7.2) and only allows it in principle in the left-most label (section 6.4.3). This more or less implies that there should be more than one label.
There is an additional errata for RFC 6125 on the subject: "RFC6125 bug: Checking of Wildcard Certs lacks spec of how many labels in presented identifier":
Note also that this issue begs the question of being able to determine what constitutes a so-called domain name "public suffix" (e.g. ".com", ".co.uk") -- we can't simply write into the spec "the wildcard must be in the left-most label position and there must be at least one? two? three? labels to the right of the wildcard's position".
Specifications aside, this is unlikely to work in practice. No commercial CA should ever issue one of those. They make mistakes once in a while perhaps, but hopefully nothing so foolish. You might be able to achieve this by deploying your own CA (or perhaps with a local automated CA within a MITM proxy you'd approve). Even if this was the case, some clients will simply refuse to validate such certificates. For example, Chromium even forbids *.com or *.co.uk.
Note that in both cases, wildcards are for DNS names, not IP addresses. Having a certificate for * as you would like wouldn't work for your use-case anyway. Perhaps looking into alternative DNS solutions (e.g. mDNS) to be able to use a name might help.
Yes there are wild card certs. You may please check with SSL cert provider to get more details .I doubt if this can be based on IP
While the public key infrastructure is broken, it is not that broken that you will get an certificate for * and the browser will accept it. The relevant RFC is RFC2818 and if you read it you'll see that the browser accept *.example.com and www*.example.com, but not www.*.example.com, www.*.com or even *.
I am currently building an application that I will host and will have multi-tenants (SaaS) called over the web, I would like them to be able to have subdomain.theircompany.com be able to point to subdomain.mycompany.com (or if they wish, point a full TLD to a subdomain with me).
The way I have been expecting this to work is to simply have a wildcard 'ServerAlias *.mycompany.com' in my Apache config pointing to my application, which then extracts the host being called...They then redirect via a CNAME entry on their host.
My question is, would this approach allow external subdomains to be pointed to a CNAME URL instead of IP? As this runs on one account on my system, am I able to install an SSL for a single wildcard if that customers wants to be running on SSL?
Any other suggestions/approaches would be greatly appreciated!
Thanks
A CNAME will work for the purposes of naming, but not for the purposes of a wildcard SSL cert.
Specifically, example.theircompany.com can have a CNAME record with a value of example.yourcompany.com. This will mean that example.theircompany.com will transparently resolve to your site. In other words, a browser still sees example.theircompany.com, not example.yourcompany.com.
As such, the SSL cert must be for the theircompany.com domain, not the yourcompany.com domain.