For some Android ver. 7.0 device, Security Risk (Firefox) or Connection Not Secured (Chrome) or Connection is not private (Edge) warning are displayed when browsing all websites running on one webserver. Strangely, on other devices (Windows Desktop, iPhone) these sites run perfect without any warning. Please have a look at www.ashiro.ca
Websites are running on IIS10 web server on Win 2016 OS with TLS 1.0, 1.1 and 1.2 enabled.
Android versions < 7.1.1 need Let's Encrypts "long" chain, which includes a signature to the now expired DST Root CA X3, because they do not trust ISRG Root X1.
Let's Encrypt provides this chain by default to all subscribers, but IIS servers build their own chain and will usually build a different chain that equals the "short" chain. The short chain is not compatible with Android < 7.1.1.
Do not know exactly when but some months before, it was working fine on Android 7.0 device.
win-acme command line application is used to auto-renew and install certificates.
Anyways, is there way to prevent IIS building own "short" chain? Any work around?
DST Root CA X3 expired on Sep 30, 2021. IIS only started refusing building the long chain after the expiry.
Yes, there is a workaround, as pointed out in the thread I linked above. It revolves around setting ISRG Root X1 to untrusted, but this comes with side effects.
Better would be to use one of the other options, such as switching CA's or using another software for TLS termination.
SSL report at Qualys shows two messages in summary
"This server supports TLS 1.0 and TLS 1.1. Grade capped to B"
"This site works only in browsers with SNI support."
Is there a need to turn off SNI support at webserver?
Secondly, while browsing on Andriod ver. 7.0 it is showing following information in error details.
"The identity of the website has not been verified.
"Server certificate is not trusted"
SSL certificate is up to date. Is certificate not trusted because IIS building own chain?
It also shows following affirmative messages
"Your connection to site is encrypted using a modern cipher suite."
"The connection uses TLS 1.2"
"The connection is encrypted and authenticated using AES_256_GCM and uses ECDHE_RSA as the key exchanges mechanism"
Thirdly, is DST Root CA X3 expired globally on Sep 30, 2021 for all servers and browsers?
If answer is yes then there would be some updates/fixes available for Windows IIS to accept long chain after expiry. Any comments on this?
SNI is not a feature that can be turned on or off at will. SNI means Server Name Indication. Its a mechanism used by TLS to indicate what server the clients intends to connect to. It is a necessary mechanism for all systems that host multiple websites behind the same server. Without SNI, the server has no idea which certificate to send (because it has multiple for different hosts). The only way to work without SNI is to either have one certificate for all websites (e.g many wildcards in the same certificate) or to use a dedicated IP for each single website.
The vast majority of TLS clients supports SNI nowadays, especially in the https/browser domain.
Whether something is trusted very much depends on your viewpoint. The certificate chain served by your IIS system uses ISRG Root X1 as its trust anchor and sends the short chain that does not include Let's Encrypts compatibility extension for old Android devices. Systems that trust ISRG Root X1 will have no issues, while systems that don't won't trust the chain.
The lowest Android version that trusts ISRG Root X1 is 7.1.1. For older Androids, Let's Encrypt has made a specific cross-sign to another root certificate, that is trusted by older Androids. Most webservers serve this chain for this reason. However, IIS servers will usually refuse to send that chain.
It is not clear to me how to fix the problem. We cannot move away from existing webserver. I am looking for a fix for IIS server with step by step instructions.
Followed instructions mentioned in the article and downloaded ISRG Root X1.der and installed certificate with default settings and rebooted. It looks like problem is fixed for Android 7.0.
However few strange things were observed.
In first attempt of ISRG Root X1 certificate installation, it did not fixed the problem so made two more attempts, rebooted and started seeing changes on few sites.
Chrome browser on android 7.0 was intermittently showing site secured and unsecured when refreshed.
After few 30 minutes, it is identifying certificate for sites but can not trust that it will stay as is for long. I will monitor sites for few more days and hope it will not repeat again.
I have few more questions.
There are two sets of certificates for each site. One set certificate name begins with [IIS] and another set certificate name begins with [Manual]. All sites are now assigned certificates whose name begins with [Manual] I guess certificates starting with [IIS] should now be removed to keep certificate list organized. What do you think. Is this good idea?
IIS server has feature called "Automatic Rebind of Renewed Certificate". I guess it would be good to keep this feature turned on. Any suggestion?
The prefixes on the cert names are likely generated by your ACME client. Perhaps I missed it, but I don't see that you mentioned what client you're using to obtain these certs. In any case, I'd be worried that a cert labeled [Manual] would not auto renew. Whether you remove the old certs is a personal preference. I'd probably wait until after your next renewal to make sure everything is working properly.
This feature (sadly) only works with certs obtained using Windows' native autoenrollment. There's no reason to keep it on, but it also won't hurt anything if you do. All it does is create a scheduled task that is triggered by a specific event log entry the autoenrollment process writes when it does a renewal.
Hey! It is back again.
Solution applied as mentioned in above post ( ISRG Root X1 certificate installation) does not fixed. Android browser 7.0 is showing invalid certificate and security warning, again!
without any warning. Please have a look at www.ashiro.ca
