As one of the main contributors on Webcompat.com I often look at issues regarding website problems, such as A/V codecs and SSL issues. And today, let me present you one of the main issues we recently have, and surprisingly this affects one of the extranet service in BINUS University, BINUSMAYA Praktikum (bluejack.binus.ac.id).
Note:
- In order to access the site (in normal days), you’ll need a valid account on BINUSMAYA, which is only available for existing BINUS University students and lecturers.
- This issue seems to occur only on select devices, especially macOS and iOS. I’ve tested the site on Linux and instead I got another error that portal.bluejack.binus.ac.id is offline.
TL;DR: Migrate to ISRG Root X1
At Webcompat.com we often use the SSL Test service from Qualys’ SSL Labs to check the SSL/TLS configuration of websites.
When comparing the SSL Test results for both bluejack.binus.ac.id and reinhart1010.id (this site), I’m quite surprised that my certificate was issued 2 days later than BINUSMAYA Praktikum.
Here’s what the SSL Test results for bluejack.binus.ac.id (as well as *.bluejack.binus.ac.id) looks like:
and here’s mine:
The difference? BINUSMAYA Praktikum seems to use the older IdentTrust DST CA Root X3 root certificate, while I’m already using the newer Let’s Encrypt R3 root certificate which is based on ISRG Root X1.
The same issue also affects other services, too.
Even since the end of 2020, the team behind Let’s Encrypt have worried that one of the root certificates are expiring this year affecting compatibility with many older Android devices, and now, it happens recently. While the team have found workarounds for this, server administrators need to, at least, migrate their Let’s Encrypt certificate chain from DST CA Root X3 to Let’s Encrypt R3 to make sure that things are going fine.
To quote from Let’s Encrypt regarding this issue:
If your client handled the X3 to R3 transition smoothly, then you shouldn’t need to take action. Ensure that your client correctly uses the intermediate certificate provided by the ACME API at the end of issuance, and doesn’t retrieve intermediates by other means (e.g. hardcoding them, reusing what is on disk already, or fetching from AIA URLs).
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
This issue doesn’t mean that Let’s Encrypt service should not be trusted. In fact, large organizations such as Red Hat, OpenStreetMap, and Shopify start to use Let’s Encrypt, while the service itself is now funded and supported by some of the world’s prominent internet companies and organizations. Even at HIMTI BINUS University we also changed our TLS certificate from Comodo to Let’s Encrypt, not because of a fee, but since the older Comodo certificate only covers for the main himti.or.id site, but not their subdomains (e.g. hishot.himti.or.id).
Leave a Reply