Hi,
I am trying to add ISRG's new root CA certificate to our old platform, but the test site (https://valid-isrgrootx1.letsencrypt.org/) seems only allows ciphers with PFS as followings.
Since PFS has not been supported on that platform because of memory compatibility of applications, the handshake fails with "Client hello" before "Server Hello, Certificate" .
It would be enough for me to be allowed any of the following:(https://letsencrypt.org seems to support these)
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
Yes, even if the cipher does not match, the certificate could be verified.
I think that it is not a cipher test site, but a certificate test site, so I made this request.
Playstation3.
On game platforms, applications use up all memory and makes the best representation.
In order not to break the compatibility of existing applications, the system needs to keep up with the new features of TLS without increasing the memory of the text segment and heap.
Optimizing the memory of the existing implementation, it has added support for TLS1.2, SHA2 and SNI, but it has not yet been able to support AEAD and PFS.
There are various servers depending on the application, but some applications use the server certificate of let's encrypt.
We are trying to add ISRG X1 in the system so that nothing needs to be done in the applications.
We don't directly manage the server using Let's Encrypt certificate, so I'm happy that we can use the test site as it is.
I'm sorry I didn't explain where the site came from.
The issues I originally wanted to solve are following.
On July 8, 2020, we will change the default intermediate certificate we provide via ACME. Most subscribers don’t need to do anything. Subscribers who support very old TLS/SSL clients may want to manually configure the older intermediate to increase backwards compatibility.
Since Let’s Encrypt launched, our certificates have been trusted by browsers via a cross-signature from another Certificate Authority (CA) named IdenTrust. A cross-signature from IdenTrust was necessary because our own root was not yet widely trusted. It takes time for a new CA to demonstrate that it is trustworthy, then it takes more time for trusted status to propagate via software updates.
Now that our own root, ISRG Root X1, is widely trusted by browsers we’d like to transition our subscribers to using our root directly, without a cross-sign.
On July 8, 2020, Let’s Encrypt will start serving a certificate chain via the ACME
protocol which leads directly to our root, with no cross-signature. Most subscribers don’t need to take any action because their ACME client will handle everything automatically. Subscribers who need to support very old TLS/SSL clients may wish to manually configure their servers to continue using the cross-signature from IdenTrust. You can test whether a given client will work with the newer intermediate by accessing our test site.
The PS3 game console still only includes IdenTrusts DST Root X3 now,
I am trying to add ISRG Root X1.
Https://valid-isrgrootx1.letsencrypt.org/ was introduced as "our test site" using ISRG Root X1, which is not cross-signed above, but it requires PFS cipher.
I am glad enough if I can use this site.
Currently, no site is experiencing the problem yet.
I'm trying to add ISRG Root X1 so that the problem doesn't happen after July 8, 2020.
Thank you very much.
True, the workaround is effective.
However, the problem remains because we are a platform holder.
While we can verify by workaround that the platform is fine with ISRG Root X1, game developers using Let's Encrypt may also want to make sure that our platform supports ISRG Root X1.
That is, even after we add ISRG Root X1, game developers using Let's Encrypt may visit the test site and fail for the same reason.
This can waste game developer time.
Each game developer can also take the workaround, but If cipher is added to the official test site, it will not be necessary.
For that reason, even if there is the workaround, I'm happy if the official test site will be resolved.
But they can also solve it getting information from this topic.
For example, if a game developer using Let's Encrypt searches for "Playstation3" and finds this topic, they can know that they don't need to do anything.
Therefore, this topic may work well with just the current information.
Of course, I would be very happy if cipher is added to official test site.
Assuming you work with Sony/Playstation: why not publish an official test site with the ciphers your support… along with an integration guide and warning to developers about unsupported ciphers and what their servers must support. That would probably be most useful to your use-case.
A matrix table of supported cipher suites list for each our platform is published as technical information on a closed developer support site.
Information that supports ISRG Root X1 will also be published as release notes.
// From a personal point of view, I'm sorry that there are no human resources and stop updating non-closed documents for Playstation3.
// This is a technical request to the test site as an engineer, so I can't publish an opinion as an organization here.
Therefore, if the administrator of the game server is viewing information on the Playstation3 support site, no problem occurs.
However, the server operator of a game that is more than 10 years old may not be the development team itself.
The development team will be breakup and will develop another new game.
// Not all games are, this depends on the kind of the game.
// There are various games.
As a result, server maintainers may not be accustomed to visiting support sites on older platforms.
Because they don't need to update client-side software, basically.
Of course, they can hear the support site from predecessor, create a support site account, search for information, and if they are still unsure, they can ask us.
As such, the problem is not critical.
There might be cases where they can save their time with this request, nothing more.
It is perfectly acceptable not to respond to this request because of the risk-to-benefit ratio.
I’m not really familiar with these older platforms or anything but would like to throw my $0.02 in.
By supporting older and often broken ciphers people developing new products using outdated libraries inadvertently, or using outdated / misconfigured clients that prevent pfs from working could get the wrong idea and assume that everything is correct, when really there is a major problem which leads to little security.
There are great sites such as badssl.com and www.ssllabs.com, which are better for noticing the problem, but it is possible that they would be saved by this test site when they didn't use those.
It is the same in that it is better to be able to save even with a small possibility, so I can understand your opinion well.