Maybe an intermediate certificate is missing?

[Nummer378]

@swelljoe

e.g. this is a cert issued after the expiration:

I can reproduce this same broken certification path on a certbot-generated certificate, as well, again with no Virtualmin or Webmin involved. In this case, Virtualmin isn't doing anything unique to cause this problem, and I don't know how to solve it, if certbot also generates a certificate that can fail for some clients.

That's not a broken chain, that's all correct and intended.

Let's Encrypt is intentionally serving a chain up to the now expired DST Root CA X3, because that helps with Android compatibility. All clients that are not Android shall use the path leading up to ISRG Root X1 for validation, ignoring the expired DST Root CA X3.

We're aware that there are some libraries (e.g older OpenSSL) that can't do this*, which is why Let's Encrypt offers an alternate chain which does not include the certificate leading up to DST Root CA X3 (instead terminating at ISRG Root X1). This alternate chain can be requested by the ACME client, if Android compatibility is not desired.

*Some libraries, e.g OpenSSL 1.0.2 have a workaround where simply removing DST Root CA X3 from the trust store makes them compatible with the default chain. This is also why some vendors (Ubuntu) have recently started shipping patches which remove DST Root CA X3.