I can set them up one-by-one with self-signed certs, but it's not practical for how many subdomains I'm working with.
Is there an easier way to do this?
Easiest is to use a wildcard certificate signed by a recognized authority. That also makes the certificates valid and validatable which is not the case for self signed certificates.
A wildcard certificate costs a fee for the signing service. Some 20 Euros a year currently. And you obviously have to go through a verification process, typically per telephone. The Let's Encrypt certificates are great, but they do not offer wildcard certificates. You certainly can automate the creation of their certificates by scripting, though, if you are willing to invest effort into that.
I personally used startssl in the past. Their portal is a bit difficult to use, but things work, and I failed to find anything comparable if it comes to prices. You need their "level 2" for a wildcard certificate, the free certificates are always for a single host name only. Each wildcard certificate will cost extra, obviously, but similar obviously you can use a single wildcard certificate with all host names within a given domain name which is what you are looking for I think.
Related
I work for advertising seo company. They have dedicated server and want also use SSL for the clients. They asked me to find the best option regarding that, I need help from you guys. I suppose some of you are more experienced in this.
Should they buy certificates separately for each client?
Create self signed certificate (Is there any way avoid security warnings).
Use wild card or multiple domain SSL
Other option (please suggest)
Thanks
I would recommand using LetsEncrypt.
It is free, you can do wildcard, automatic renewal every 3 month, documentation, etc.
I'm a big fan of it.
You can also use your registrar, sometimes they also sell certificates for the domain they sell. Like Gandi for example, you got 1 year free certificate with a domain, and they guide you all along on how to install it.
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).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 months ago.
Improve this question
I'm wanting to cover the a few domains with an SSL Certificate.
e.g.
portal.domain.com
app.domain.com
app1.domain.com
app2.domain.com
I'm a bit confused as to whether I can go for the cheaper Unified Communications Certificate, or whether I need to fork out for a wildcard certificate.
Is the only difference that the wildcard can have an unlimited number of subdomains, where the UCC only covers a set number under the SANs?
Thanks in advance
Yes, you are right Unified Communications Certificate covers a set on SANs but it can secure multiple domains, and hosts configured in your Exchange server where a traditional wildcard SSL cannot. For e.g. A wildcard ssl can secure first level of sub-domains like *.example dot com where a Unified Communications Certificate secures www.example dot com, www.example dot net etc.
Yes. Keep in mind that some old X.509 implementations might not support SAN, but that's pretty rare today (some Symbian OS phones for example, see http://www.digicert.com/subject-alternative-name-compatibility.htm).
Generally, a domain name or URL requires just one certificate to be secure. But what if you need to secure multiple domains? How can you manage their security without sacrificing budget and time?
Securing Multiple Domains
Securing multiple domains can be achieved with 2 approaches, Wildcard certificates and Unified Communications Certificates (UCC), also known as SAN (Subject Alternative Name). SAN lets you specify additional host names (sites, IP addresses, common names, etc.) to be protected by a single SSL Certificate, while a Wildcard certificate can support a single domain and an unlimited number of first-level subdomains. SAN/UCC can also be combined as an extension with a Wildcard to add functionality to the certificate. You can combine these two certificates as a Multi-domain Wildcard SSL Certificate depending on your needs. This makes managing the security of multiple websites much easier and cheaper than managing a separate SSL certificate for every domain you own.
Read More: Wildcard Vs SAN/UCC Certificates
It's only cheaper up until a certain number of domains, because UC and SAN certs charge by each domain name. You'll notice the price changes as you enter and subtract domains from this UCC link
If you know that you will have more than say 5 subdomains, save some cash with the wildcard because it's a set prices regardless of the number of sub domains.
UCC and SAN is only recommended for exchange server. your requirement seems like you need ssl with common name *.domain.com so that single ssl works for all sub-domains.
Know what exactly UCC and SAN is..
UCC / SAN cert is recommended only if you need to secure different tld like urdomain.com urdomain.co.uk urmydomain.net. This kind certs cost too much as it starts from $200.
Answering your question, I checked few brands wildcard ssl RapidSSL wildcard, comodo positive ssl wildcard, globalsign alphassl wildcard, geotrust wildcard ssl. I tested these brands installed ssl website in my iPhone and Samsung android phone. All works perfect.
I reviewed many ssl providers for UC certificates pricing. Apart from the pricing, I found some ssl providers sell same product with different names, like multi-domains ssl, san certificate and uc certificates.
Microsoft exchange server requires typical UC certificate, strongly recommended by Microsoft. I decided to purchase UC certificate but it costs too much, starts from $300 to $600 with veriour providers like comodo, globalsign, digicerts etc. First I purchase single domain ssl and failed in exchange server installation. I thought could save $$$ with single domain ssl.
Later I searched for UC certificate prices $50 to $100 and found ssl2buy ssl company provides comodo uc certificates for $60 only and it includes 4 domains.
https://www.ssl2buy.com/comodo-multi-domain-ssl.php
I purchased this uc certificate and installed on my exchange server. It works fine! No error - No installation issue, nothing.
If I sign Adobe Air with godaddy certificate, how it will be different from list of recommended by Adobe (for example, here).
The main difference is the name of the issuing authority as shown in the root certificate. If someone were to inspect your certificate, they would see "Go Daddy Class 2 Certification Authority Root Certificate". I suppose it depends on how much confidence your users would place in this name. Security paranoids would have the root certs installed already, low level users probably wouldn't even know such a thing existed, but mid-level "power" users who haven't heard of GoDaddy might be suspicious (or at least more so than say VeriSign for example).
Technically speaking there is not much difference - they are all standard X.509 certificates. I generally find that if you can get the cert in .PFX format (with the private key embedded) it works well across platforms. If you can only get another format (.cer) it's fairly straightforward to convert it using the Certificates snap-in in Microsoft Management Console.
Here's a possible scenario.
Let's say I have a website "https://www.mywebsite.com" and there is a valid SSL certificate purchased for this domain.
I want to "mimick" this website on my LOCAL machine for a testing purpose.
So let's say I set up a locally-configured "https://www.mywebsite.com" (which is in essence https://localhost/mywebsite or something similar).
Would I be able to re-use the SSL certificate on my local testing website?
You can re-use your SSL certificate if you configure your DNS so that your test machine is the same domain name as server, which is probably a bad idea.
You can also re-use it on your test machine if you don't mind clicking the box "accept this whacked out ssl cert"... So I suppose that the answer is technically yes, although I wouldn't personally do it.
It depends what you are trying to test and why you need a certificate for testing.
If you use the certificate, it will correctly encrypt connections using SSL, but any client will get a certificate mis-match error. If you use a self-signed certificate instead, most clients will give you a warning about that, so it might be just as annoying or not.
If you are testing, for instance, a deployment script to make sure everything gets installed in the right place, it will work. If you are testing to make sure your code correctly redirects a non-secure connection to a secure one, it will work.
If you want to test the your website for functionality, usability, bugs, etc. then your testers will likely complain about the certificate warnings or errors, and you're probably better off doing something else.
I am not sure since the SSL certificate is bound by the domain name that was registered with the certificate. But you may be able to dupe the certificate by editing your hosts file to change localhost 127.0.0.1 to be mysite.com 127.0.0.1, ...in theory at least...if not this is a question for serverfault.com.
Hope this helps,
Best regards,
Tom.
You can't use it since the SSL cert is tied to the domain www.mywebsite.com unless you do a bit of trickery.
You can put an entry in your hosts file saying that domain is at 127.0.0.1, but that's not ideal as you could no longer reach the website.
If you just need a valid cert to test with, then a better alternative is to self-sign using the IIS Resource Kit.
I'm no expert on DNS, but this would introduce a pretty major vulnerability.
Basically if this was allowed, DNS poisoning could be used defeat the whole purpose of third party trust.
Think about it:
I infect your computer so that when you go to www.amazon.com it resolves www.amazon.com to a different domain. That domain uses amazon's ssl cert to fool you into thinking it's legit, so you send me your credit card information.
So, the answer to your question is, no you can't do this. You will still get errors, My guess is that somewhere on the verfication chain, it compares the domain that initiated the request with what its internal dns resolves the domain, to verify there is a match.
As others have said, you can test SSL with a Self Signed Cert, you just have to instruct your testers to import the cert, or go through the trouble of building your own trusted CA, and have testers add that CA as a trusted CA.
There is no point in stealing another sites SSL Cert.
Of course you could use the vulnerability in MD5 to create your own valid SSL cert.
http://www.digicert.com/news/2009-01-05-md5-ssl.htm