Old Android OSes work fine on the servers using the .pem files, but get a security warning on the IIS servers using .pfx. The .pfx is created with openssl. This was working before the recent changes.
On one server, I create a wildcard cert (.pem) and it works fine
openssl pkcs12 -inkey privkey.pem -in cert.pem -export -out /home/certificate.pfx -passout pass:
Does not work for some old Android devices: https://www2.wordreference.com
How can I create a .pfx file that works properly?
What is the proper openssl command? I have tried a few options and nothing has worked
More background:
I see this on an Android 6 phone that I have.
Certificate viewer:
forum site, using .pem files: I see the full chain. (*.wordreference.com, R3, ISRG RootX1, DST Root CA X3)
www2 site, using .pfx file: Just *.wordreference.com & R3
Required info:
My domain is: wordreference.com
I ran this command:
It produced this output:
See above
IIS 10.0
Windows 2016
CentOS 7 centos-release-7-9.2009.1.el7.centos.x86_64
nginx 1:1.20.1-2.el7
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 1.11.0
Unlike many Linux web servers that have explicit config options for choosing which chain to serve, IIS on Windows has no such control. It automatically chooses which chain to serve based on what's in the various trust stores on the system. But even if you import the long chain into the appropriate places, it will still choose to serve the short chain.
There's a way to trick it into serving the long chain, but it's kind of a hack will partially break Let's Encrypt validation for processes running as the SYSTEM account. Have a look at the doc I made for Posh-ACME users on this topic.
The only alternative is using a different CA to get a cert for your Windows server.
This will be the main reason why you couldn't browse the forum server. The PSExec instructions are important because they only modify the SYSTEM user's store. When you ran certmgr.msc as yourself, you only made those change in your current user context. So not only did you break yourself, you also didn't fix IIS because it only cares about the Local Computer or SYSTEM user's context.
I'd advise you reverse the changes you made in certmgr.msc and either continue trying to make PSExec to work or just use the registry file I linked in Option 2. You'll want LetsEncrypt-DefaultChain-SYSTEM.reg.
And again, it you want a less hacky, better supported workaround, you should switch to a different ACME CA such as ZeroSSL or even a paid certificate from a non-free CA.
It is an old phone that I am using for testing. Unfortunately, I have hundreds of thousands of users that use old Android OSes and they are not happy about this Letsencrypt situation. It is rather sad.
I have some old Android phones as well.
But I'm realistic about what they can do - and how long they will be able to do it.
It's only a matter of time before all their trusted certs are expired.