E.g. I generated a CSR with domain: www.domain.com
If now i want to setup a SSL sub-domain with test.domain.com
Do i need to generate another CSR for the certificate installation?
Or i can just reuse the previous CSR generated for www.domain.com?
You need a new Certificate.
Wildcard certificates
The Next time you can consider buying Wildcard certificates, that will do what you describe above. I was unable to find a good describtion online ( That was not on a vendors site).
So il do my best:
Wildcard certificates allow you to buy for a whole domain like MyCompany.com, and then you can use unlimited amount of subdomains.
But there is restrictions:
1) Not all software support them, so make sure your web server and the application your gonna host does ( Dont think it will be a issue with web servers).
2) Not all client software supports it ( Mostly the issue where would epic old web browsers ( Older then IE 6 ) and Cell phones.
3) They can also support multiple physical servers
4) They are more expensive, so you should do the math.
Related
I have below domains, buying a single wild card certificate beneficial? Or do I need to buy separate SSL certificates.
abc.example.com.au
abc.example.com.nz
abc.api.module.example.com
abc.api.global.example.com
Do I need to consider anything, when buying the SSL for the above domain. Appreciate your inputs.
Probably a better question for ServerFault or SuperUser, but since you're here, a wildcard certificate will only work for subdomains and only one level deep, so it would not work for any of the examples you mentioned.
Example: A cert with cn=*.example.com would work with a.example.com or b.example.com, but not 1.a.example.com. See https://en.wikipedia.org/wiki/Wildcard_certificate for more details.
Also, when using a wildcard does make it simpler to manage your certificates and renewals and applying updated certs and whatnot because the generation process only has to be done once and the same files and configs can be copied to all servers. Consider though that, if there is some kind of security issue with the wildcard cert, then it would affect all servers that use that cert. So a breach on one server would affect all servers and a problem with one would require an update to all servers that use it.
For these reasons, I generally use wildcard certs for non-production systems, and individual certs for production systems.
Single Wildcard SSL Certificate will not work in your all sub-domains.
You have now 3 options.
Get two different wildcard domains
Get a Multi Domain SSL (it will allow you to add sub-domains as well)
Get a Multi Domain Wildcard SSL Certificate (combination of 100 multiple domains and unlimited number of level-1 sub-domains).
I have a SSL cert installed on http://example.com. I've finished a mobile version of the same site and it sits on http://mobile.example.com. I need to secure that subdomain as well so I purchased another SSL. But now I'm trying to understand how to set it up.. because I know you can only have one SSL per server, correct?
So what's the correct way to go about this? Do I need to change the original SSL to wildcard? Do I need two SSLs?
You can use a wildcard certificate or a certificate that allows multiple SANs (Subject Alt Names). How you set them up is very dependent on your web server. A wildcard certificate only works for subdomains, while SANs can be used for completely unrelated domains.
With Apache (don't know about others) you can also use two separate certificates as long as you're willing to drop support for XP-users (see e.g. http://www.digicert.com/ssl-support/apache-multiple-ssl-certificates-using-sni.htm for details).
I've got a webserver that has a single domain SSL certificate: https://secure.example.com
I also have a couple of subdomains that point to different servers:
http://www.example.com, which points to the main server.
http://subdomain.example.com which points to a completely different server.
What is the best way to add SSL to the subdomain https://subdomain.example.com
Is it possible to configure something like this with a wildcard certificate? Or is it better to purchase another single-domain certificate and install it on the seperate server?
You can get a wildcard cert but that is probably more expensive than you need and you'd need to copy your private key to each server -- which really is not recommended unless you are a crypto expert. You are better off simply purchasing two more certs for the two additional machines.
Wild card certificates only cover domains on the same server. I believe it's because the key used in the certificate is tied back to the server.
If you want to add a certificate for sites on other servers you will need specific certificates for those server/domain combinations.
We're having an issue with securing an intranet / internet website with SSL where
we can't know the qualified domain name in advance.
Basically, I'm trying to make a program that will be installed on a webserver
outside my direct control, to be accessable over intra- or internet. In either case
I want it to be secure via SSL (https). To do this, I would like to include and
install a SSL certificate on the target machine. My installer is fully prepackaged
and should not require any particular during- or postinstall intervention from my
end. Problem is, I can't know ahead of time the target machine's name or domain
name, so as far as I can tell the SSL connection will be returning warnings (or
worse?) when accessed, since the certificate I include will (must) have a different
name on it.
I really want to avoid those warnings, but I still want to keep it secure. Is there
any way to install a SSL connection without certificate warnings without the domain
name known ahead of time?
Thanks for any help you folks can give.
What you want to do is not possible. Here's why.
A certificate will include a set of names (Common Name, possibly along with Subject Alternative Names, possibly including wildcard names).
The client's web browser will do the following:
The user wanted to visit "https://myapp.mydomain.com/blog/posts/1".
The request is via SSL and the domain name in the request is "myapp.mydomain.com".
Get the certificate from the Web server.
Ensure that at least one of the names in the certificate is exactly equal to, or wildcard-matches, the domain name in the request.
Display the page.
Therefore, you need a certificate with the exact domain name (or a wildcard matching the exact domain name) by which the application will be used. And the certificate needs to be available at the same time as, or later than, the time when the exact domain name of the website becomes known, and cannot be made available any earlier.
You seem to be under the misapprehension that somehow a certificate can "create" or "install" an SSL connection. That is false. The Web server - Apache, IIS, Nginx, LigHTTPD, or whichever one you happen to use - is the program that knows how to every aspect of SSL connectivity. The certificate is just a file that the Web server sends to the client, without even opening or using in any way.
Additionally, the author of a webapp to be distributed is not responsible for creating or distributing certificates, and should not be under the misapprehension that he is responsible. Only the website maintainer should be responsible for obtaining a certificate for his website. As another person remarked, in your installation process or perhaps in a post-installation process, you may ask the person installing the webapp for a certificate. But that is the best you can do.
The best you can do is to buy a wildcard SSL certificate - but wait, it's not what you think. You still need to know the second-level domain (the TLD being ".com") ahead of time. You can effectively ask for a cert that covers *.foo.com - then any site, a.foo.com, b.foo.com will be covered. Of course, these certs are more expensive that FQDN certs because you are doing the buggers out of some extra coin.
-Oisin
Each of those sites should have their own SSL certificate. Why not prompt the user to provide the cert file during installation?
In most (if not all) cases, the SSL certificate is associated with the webserver (apache, IIS, etc.) and is not part of your application. It's up to the admin of the web server to install the certificate and not you as the author of the program.
If your installation program does have the ability to modify the web server configuration, and you are willing to have it use a self-signed certificate, you can script the creation of the certificate to allow the domain name to be input. However, I sense this is not really available to you. Also, a self-signed certificate will generally cause certificate warnings.
If I understand you correctly there might be a solution to your problem now. This solution won't help you, however, if you have no control over specifying what SSL certificates are served from the web server where your program is installed (as mentioned by someone else). If your program itself contains a web server you won't have this issue.
If you start with a trusted https website, you can make cross-domain TLS (SSL) XmlHttpRequests to the web servers that are running your application. This is made possible using the opensource Forge project. The project uses a TLS implementation written in JavaScript and a small Flash swf to handle the cross-domain requests. Your program will need to serve an XML Flash policy file that grants the trusted website access to the web server running the application.
Your program will also need to generate a self-signed SSL certificate and upload it to the trusted website. From there, each program's certificate can be included as trusted via the JavaScript TLS implementation. Alternatively, you can have your program upload its certificate to be signed by a CA you create, using a common or subject alternative name that is appropriate for your use (it doesn't have to be the domain name). Then you can use JavaScript to trust the CA certificate and look for the correct name on each certificate.
For more details check out the Forge project at github:
http://github.com/digitalbazaar/forge/blob/master/README
The links to the blog posts at the end provide more in-depth information about how it works.
I've got an ssl certificate for what I think is my domain and I want to apply it to two separate applications in that domain that run under ASP classic in IIS on Windows 2000.
I have the following stupid questions:
Are certificates issued for URLs or domains? Or subdomains?
Can I use the same cert for multiple websites (applications) within that domain, or do I need a separate one?
Can I inspect the cert file to determine for what or to whom it's issued?
Thanks!
1) Web certs are issued to a domain. Specifically the CN attribute of the certificate must match the domain used to access your site.
2) Certs are usually install per host (or virtual host). If you had cert for the domain wwwapps.domain.tld you could have one app at /calendar, and one app at /contacts.
3) Yes, depending on the format and where it is, this can be easy or hard. If you have a crt file and you are running under windows, just click on it. You should see the details.
If you want to inspect a certificate that is installed on a site, you usually have to click on the padalock icon.
On windows you can also open up the MMC, add the certificate snapin and see any/all installed certificates on the local machine, or your profile.
They are issued for domains. Subdomains require their own certs. You can buy a special wildcard cert for your domain that lets you create certs for your subdomains, but they are more expensive.
If you buy a cert for mydomain.com, you can use it for anything that starts with https://mydomain.com/
Yes. You can do this for any certs. check out the lock icon in your browser's address bar.
It's usually issued to a single web server host (basically a computer cname or a record) like foo.bar.com where foo is one name for the host which the certificate request was generated for and bar.com is its domain.
Thus it will work for any application or virtual directory that responds to https://foo.bar.com - like https://foo.bar.com/planner/ - but nothing more.
For https://*.bar.com you can get a wildcard certificate that lets you handle any number of hosts without any hassel - at a greater cost.
There are also multiple-SAN (UCC) certificates that can contain a specific number of host names in a single certificate like webmail.bar.com and autodiscover.bar.com for an Exchange 2007 server serving both web access and Outlook Anywhere from the same physical machine and NIC.
If it's in .cer format simply opening it in Windows will show the details, if it's a pfx or in some other transport format you'd need to import it.
You basically install the certificate on a Web Site node in IIS and anything you can fit beneath that (or modify using a modern firewall in front of it to still respond to the issued common name foo.bar.com) will work.
Thanks! I enabled port 443 for the site at the domain on the cert, loaded the cert via directory security in IIS for each subfolder, and enabled 128-bit encryption. Worked like a champ!