: Thawte/GeoTrust/VeriSign 2048 Bit Root migration and Intermediate SSL Certificates Thawte, GeoTrust, VeriSign and other Certificate Authorities are currently in the process of changing from a 1024
Thawte, GeoTrust, VeriSign and other Certificate Authorities are currently in the process of changing from a 1024 bit MD5 based root certificate to a 2048 bit SHA-1 based root to "keep in line with industry best practices". In addition all certificates will now require Intermediate Certificate Authorities, creating a Chained Root certificate instead of the single root certificates that were previously issued by preferred providers. Having recently gone through this upgrade with one of our sites I now realize that I do not fully understand how SSL works and that I am in need of some clarifications.
Question 1: How does a 1024 bit root differ from a 2048 bit root?
I understand the switch from MD5 to SHA1, as MD5 has been proven vulnerable to collisions, but my question is what benefit does a 2048 bit root give over a 1024 bit root? Does it increase the SSL encryption strength between client and server or does it simply make it more difficult to compromise the root certificate?
Question 2: How do Intermediate Certificates work and what benefits/detriments do they have?
After updating our site everything worked fine except when the site was accessed by an older browser (Windows Mobile specifically). I was a bit confused since the Thawte SSL123 2048-bit Test Site worked fine on the device where as our site prompted a warning message regarding an "Untrusted Root Certificate". Both sites had the exact same certificate chain, of which neither the root or intermediate certificates were trusted by the device. Stranger still was that after visiting the testing site, our site would magically start working without any warnings.
I contact Thawte regarding the issue, and they said that our SSL certificate was not installed correctly. They said that we needed to download and install the intermediate certificate into the trusted intermediate certificate store of the server, and that we could use their installation checker to verify the results. The certificate had been installed by our hosting provider (probably using an automated script configure for single root certificates), but once we followed their instructions our site started working on the older browsers without needing to install or approve the new root or intermediate certificate on the device.
How is it that installing the intermediate certificate on the server causes older browsers to accept the certificate as being valid?
More posts by @BetL925
1 Comments
Sorted by latest first Latest Oldest Best
Having recently gone through this upgrade with one of our sites I now realize that I do not fully understand how SSL works and that I am in need of some clarifications.
To put it simply, SSL keys (of any order) are a series of keys on a chain. There is a handshaking method that goes through the PUBLIC-PRIVATE process (the chain) of multiplying very large prime numbers (keys).
Question 1: How does a 1024 bit root differ from a 2048 bit root?
Firstly, the key is twice as large. In terms of computational "cracking" this causes and exponential more amount of time. The last I heard, (so I could be wrong) massive-multisharing, such as Seti@home was able to crack a 256 bit key in under 6 months. However, a key twice this size takes 4 times as long, minimum. It is a Bachmann–Landau notation problem. Naturally a 1024 bit key takes 16 times, and 2048 takes 32 times.
Because a brute-force to a 512b key was considered to take 1.2 trillion processing years at XYZ MhZ speed at one time, it was lunacy to think we would need to upgrade the key size ever.
But alas, we have.
Now with "P versus NP" as a millennium prize, more people are looking at filtering down the guesswork in factoring big big big primes.
Question 2: How do Intermediate
Certificates work and what
benefits/detriments do they have?
...
How is it that installing the
intermediate certificate on the server
causes older browsers to accept the
certificate as being valid?
It is possible different browsers have different Extend Verification routines or providers. (possibly none!)
It is also possible different webservers have different Extend Verification routines or providers. (possibly none? not as likely!)
An example of a codebase that actually performs the SSL, is OpenSSL for PHP.
There are many types of libraries such as this for different servers and different code-bases. The servers, library builds, or even the keys themselves may have issues with legacy code.
Because the security of the internet goes through upgrades and changes in process-flow from time to time, I would say it is safe to say that the newer 2048-bit keys have more keys and/or more chains. In a very real aspect, this can cause abnormal behavior on what is considered a depreciated routine.
Hence the reason why the intermediate certificate fixes the issue, it patches the incompatibility with an optional backwards-compatible certificate.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.