There are some cheaper SSL certificates out there. Would a certificate from Verisign perform better/faster than a certificate from a discount provider?
My gut is telling me that it does not make a difference b/c ultimately the certificate is installed on the server.
You might check out this information from IBM. They looked at several different cipher suites with regards to SSL and measured the relative performance of each.
Note that the MD5 algorithm is pretty much broken and useless (also here) when trying to secure anything. So stay away from it.
From my experience it doesn't make any difference. They all generally use the same set of algorithms behind the scene for the encryption of the traffic and thus it is the implmentation of those algorithms that are more likely to make a difference.
The only consideration I would make would be if the client machines have the Certifying authorities certificate installed. This generally leads to Verisign or a large one being chosen but that was a few years ago now, I believe the coverage is now a lot better.
Related
We have dozens of thousands of domains which we host. We want to provide SSL/TLS for all of them, on a single I.P. Apparently, SNI allows us to do this. However, this suggests having literally dozens of thousands of certificates at our SSL termination server.
Are there any "natural" or "artificial" limitations on the number of certificates that may be installed on an SNI server?
A "Natural" limitation is imposed by nature, such as the performance of searching a cert from a list of thousands
An "Artificial" limitation is imposed by human rules, such as software that would prevent us from installing too many certs, perhaps some rule in the SNI protocol.
.... Or any other problems you can come up with?
I believe we can divide the number of certs necessary by ~100 by bundling them into SAN certs, but for the purposes of this question, please assume that's either not possible, or has already been done and we still have dozens of thousands of certs to serve.
What are the limitations? Do you think this is possible?
Purely for posterity since I received no answer submissions:
We're now in production with hundreds of certs by compressing domains into 100 per SAN cert. While we haven't tested dozens of thousands of certs yet, it appears that there are no artificial limitations as I described above. I would assume there are only natural limitations. I assume performance will scale inversely with number of certs to serve. To what degree that performance might change is still unknown to me entirely, and is surely dependent on hardware and architecture.
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.
I need to set up https communication between a Tomcat application server and a back end system. The web server hosts a public website, so is in a DMZ.
My question is if there any advantage in using official CA certificates, over using self signed certificates in this situation (machine to machine communication)?
I keep hearing self signed certificates should not be used on production systems, but I'm not sure I understand why (for machine to machine communication).
The risk lies in how effective the defenses protecting the hosts in question are, including the network connection between them. Given that weaknesses and exploits are being found all the time, it is reasonable to say there could be issues with self-signed certificates used in a production environment - which includes hosts in a DMZ.
Here's the reason: man-in-the-middle. In short, if either host - or the network between them - becomes compromised, then the traffic between them will still be encrypted, but because the certificate is self-signed, a man-in-the-middle (aka "MITM") would be able to introduce a transparent proxy using a self-signed cert, which will be trusted by both sides.
If instead your hosts use a public CA, then the MITM approach cannot work.
If the annual $15-50 investment per host is more costly than the information on and between them - including what could be on them (e.g., compromised, serving malware), then the choice is simple: don't worry about buying certs. Otherwise, it's important to look into them.
The comment by Adam Hupp on this webpage provides a good, simple scenario:
http://www.vedetta.com/self-signed-ssl-certificates-vs-commercial-ssl-certificates-how-mozilla-is-killing-self-signed-certificates
And here's a more fleshed out description of the risk:
http://blog.ivanristic.com/2008/07/vast-numbers-of.html
And finally a balanced look at the two scenarios, though this article only considers self-signed OK when there is a fully-functional, properly protected and implemented Certificate Authority server installed:
http://www.networkworld.com/news/tech/2012/021512-ssl-certificates-256189.html
I see no advantage in using official certificates for this task - besides the fact that your marketing dept. could claim your infrastructure is "100% certified by $CA". Encryption algorithm/strength and cert duration can be the same, depending on how you configure it.
The recommendations you hear probably focus on the far more common usage of HTTPS for communication with browsers, which nowadays complain about self signed certs. For data transfer between servers, I think it's good practice to encrypt traffic the way you plan on doing it!
I was recently requesting a SSL cert via GoDaddy and noticed this message:
In the past I have always generated 2048-bit CSR requests, but this time it got me thinking that perhaps I should "step it up," and it seems like the next step would be a 4096-bit version.
There isn't much info available on 4096-bit SSL certs - but apparently many people have been using 1024-bit certificates until they absolutely had to upgrade and now some browsers won't support the 1024-bit certificates anymore.
How is browser support for 4096-bit certificates? If GoDaddy requires "at least" a 2048-bit certificate, is that enough, or should I try and do something more? If so, what are the advantages and disadvantages?
PS: the two links in GoDaddy's message are CSR Help and Learn more, neither of which I found very helpful.
Pretty much all* browsers will support 4096-bit keys. The issue you'll run into is that key exchange is slower with larger keys, which will increase load on the server and slow down page loading on the client.
2048-bit keys are generally considered safe for the time being. If you want an intermediate step, though, 3072-bit keys are right smack-dab in the middle.
*: Only exception might be a couple of weird, old mobile / embedded browsers.
If you are going to use Amazon CloudFront, they only supports up to 2048 bit keys as of today.
References:
Having trouble associated SSL cert with Amazon Cloudfront
SSL certs with keys larger than 2048 bits?
If you have a 4096 bit SSL certificate, in order to support some clients (especially Java-based clients and some older clients) you will want to generate a 2048 bit or 1024 bit Diffie-Hellman Key and add it to your server certificate. However, if you support a 1024 bit DH key you should also be aware of the Logjam attack. You can accommodate these clients easily by adding a DH key of the appropriate size, but first carefully consider which clients you want to support.
Hi sorry for answering SOOO OLD thread, but the main point in "NOT" creating 4096 cert is, your CA cert will be 2048, so creating sub cert 4096 is pointless... when even having 2049 bit long cert will make attacker attack your CA cert instead yours.
I'm not quite sure if this question applies to this forum but if it does maybe someone knows if it is possible using Open SSL to create a SSL sertificate that browsers wouldn't throw warning messadges that our created SSL sertificate is untrusted?
Technically it is possible if you have CA's private key to sign the newly created certificate. As you probably don't have a key, the answer is probably no. Just go ahead and purchase a certificate from one of CAs. If you do minimal research, you will find that some CAs offer very affordable prices.
This is probably better handled on server fault, but I will tell you that NO you cannot do this. The reason browsers don't like your certificate is that you are not a recognized certificate authority. As such, a browser will always warn about your certificate being untrustworthy, since the browser does not know who you are, or why anyone should trust you.
EDIT: As Alex K points out, you can install your certificate on machines you know will access your site, which works reasonably well for scenarios where the site will only be accessed by a limited number of known users/machines. My point still stands regarding wider distribution. Thanks, Alex.