Old Android: .pem works on CentOS, but .pfx derived from it with openssl does not

Help
1

My question: What is the proper openssl command?

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

certbot renew -q --deploy-hook "systemctl reload nginx"
Works on old Android:
https://forum.wordreference.com

Then I create the .pfx file that IIS needs:

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:

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

openssl.x86_64                        1:1.0.2k-21.el7_9              @updates   
openssl-libs.x86_64                   1:1.0.2k-21.el7_9              @updates   
openssl11-libs.x86_64                 1:1.1.1g-3.el7                 @epel

Thanks!

2

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.

3 Likes
3

Thank you. I followed the instructions there, but it didn't work.

  1. My Android 6 phone didn't care. It still showed the expired R3 cert and nothing "above" it. I cleared caches and certs many times.
  2. "partially break" - yes, I couldn't view the forum server (CentOS) from the IIS server, at least in Chrome while the one cert was listed as untrusted.

Note: I couldn't get PSedit to work, so I just opened CertMgr directly

I really appreciate any suggestions.

1 Like
4

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.

1 Like
5

Quote of the day!:

1 Like
6

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.

7

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.

8

And/or the cipher suites and TLS versions they support will be disabled on most web servers.

2 Likes
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.