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.
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'm doing a network security course and trying to wrap my head around all the concepts. One of which is:
What technology other than firewall can be used to allow only a specific customers while block some other customers? Why is firewall not suitable?
During the course, I've been learning about all the security tools such as: firewall (static, dynamic, DPI), Proxy, VPN, Tunnel, all sorts of IDS (signature, anomaly, darknet/greynet and honeypot) then mod_security to secure apache but still puzzled by this question.
Any insights here will be greatly appreciated.
A firewall implied that you block based on the customer IP address. This may work if the customer has his own range of addresses and all requests from him are legitimate.
It gets complicated when he is with a large cloud provider who who provide a wide range of possible IPs, including IPs from other people.
For an application one good solution would be to use client-side certificates. In that case, during the TLS handshake (the process of putting in place a TLS (was: SSL) tunnel), the server will request the client to provide a certificate he (the server) trusts. Failure to providing one will break the connection.
This way, you can distribute the certificate to the clients you want to be able to reach your service and others will be rejected. This solution is better as it uses technologies which were developed exactly to solve this problem. The drawback is that you have to maintain and distribute the certificates (and usually run a PKI).
Recently one more TLS attack was published: Logjam. The issue has a really clear description and demonstrated that sites that use 512 key size are vulnarable and it takes up to 10 mins to "decrypt client server keys exchanges".
Based on the attack nature it's understandable that clients and servers should be vulnarable to this type of attack. It seems only recent browsers have implemented security fixes to mitigate this vulnerability. Hovewer if you're working with "commonly used" Web Applications and also forced to support IE 8, 9+, other browsers it's unlikely that majority of users will have security patches on the client side.
And it's interesting to know if server is vulnerable or not if key size is 1024 bit. Based on Logjam description it's only a suggestion/recommendation: "it's preferable to have a key 2048 bit".
This online test provides the following information:
Warning! This site uses a commonly-shared 1024-bit Diffie-Hellman
group, and might be in range of being broken by a nation-state. It
might be a good idea to generate a unique, 2048-bit group for the
site.
Does this mean that site is potentially vulnerable?
I'm looking for a wildcard certificate for a company *.domain.com.
I don't need extended validation.
Entry level questions:
Should I buy level 2 or level 3 certificate? What's the main difference?
Can I install (use) the same certificate/key pair in different machines (different IPs)? Some CAs ask for dedicated IP as a requirement, but I'd like to use SNI for multiple virtual hosts.
In general, is it a good idea to rely on SNI support?
Should I buy level 2 or level 3 certificate? What's the main difference?
The difference is the number of intermediate CAs, which should not matter. Different CAs might have additional differences between the certificates, like life-time etc but this depends on the CA.
Can I install (use) the same certificate/key pair in different machines (different IPs)? Some CAs ask for dedicated IP as a requirement, but I'd like to use SNI for multiple virtual hosts
There is no restriction using the same certificate for different IP, different ports, multiple machines etc as long as the host name in all cases matches the certificate. Of course each of the machines needs access to the private key, so you increase your attack surface with more machines.
In general, is it a good idea to rely on SNI support?
It depends what kind of systems you need to support. If you expect only newer browsers as clients SNI is ok. But, SNI is not supported by IE8 (Windows XP), some Android applications (because of an old version of Apache HTTP library), older versions of Java and older versions of script languages like Python, Perl etc which often gets used to automate tasks.
If you want to use the certificates not only for web but also for mail the situation might be even worse.
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.