Please use SSL Labs on your domain to verify there are no certificate chain issues.
Intermediate certificates have no trust status of their own, they don’t have to be “in” a browser, they simply need to be served along with the site certificate and help build a trust path back to the root certificate.
There was no point censoring your domain there as the fingerprint can be used to look it up in the CT logs. Anyway it appears that the server is sending a cert for a completely different domain (issued by a different CA as well).
Thanks for the tips guys.
I think the problem lies with the conversion to a Java Keystore. I’ve sucessfuly done it just last week when the intermediate was X1 but now the cert chain is missing.
I can convert it to jks with the X3 intermediate but now the root is missing.
Any handy command line resources to convert the pfx to jks? So i can verify what is wrong? Thanks.
If there are no trust or chain issues in your certificate/server configuration, you can safely assume all the browsers with a correctly negotiated cipher will work.
https://crt.sh/ has added some trust information for issuers, so if you care about whether a particular major trust store currently trusts a certificate you can find that certificate on crt.sh, then click Issuer (which is a link to the CA that issued the certificate), and scroll down to the Trust table.
https://crt.sh/?caid=16418 shows that for Microsoft, Mozilla and Apple the current Let’s Encrypt issuer, X3, is indeed trusted as you’d expect.
There’s no green in the Chrome EV column because Let’s Encrypt doesn’t offer or plan to offer EV certificates and Chrome doesn’t use its own trust store for other certificates.
Typically the oldest extant CAs are the most widely trusted. This is because the root application processes for all the major trust stores except Mozilla’s are largely opaque and can take a very long time to complete (Apple is rumoured to be worst), and because once active support for software or hardware ceases it is impossible to get your CA added to the trust store for that software or hardware, so the set of trusted CAs becomes set in stone for older appliances.
The Verisign and Thawte roots, which date back to the fairly early days of SSL, are very widely trusted indeed. These are today both controlled by Symantec. If it is essential that every possible older device or program should work with your certificates, the relatively expensive certificates offered by Symantec may be worth it to you.
The more popular CAs do often have a list somewhere of compatible software on their “support” pages. If you’re considering purchasing a certificate from a CA you should check that the Issuer of the certificate you receive will be the exact one listed for that compatibility. Purchasing from a reseller, or discount site for a lower price doesn’t matter, so long as the certificate Issuer is the right one.
Okay, but why on hell does Apple trust LE certs for code signing and secure email (the latter also Microsoft trusts)? LE does not offer any S/MIME certs (for mail) and if you could use an LE cert to sign your software code and Apples accepts this, this would be a huge risk as well.... anybody can get LE certs and code signing certs are meant to show the author (authentication) of a software.
I also don't know what "IP security user" is, where Apple trusts LE too.