Have you included the X3 intermediate cert in your config ? ( not the X1 intermediate)
Yes, X3 is there but still not trusted by firefox 45.0.1
Bag Attributes
localKeyID: E2 43 99 C5 23 2A 7B 66 C8 C2 9F 79 89 83 71 CA C5 B2 63 AE
subject=/CN=(removed)
issuer=/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----
Bag Attributes:
subject=/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
issuer=/O=Digital Signature Trust Co./CN=DST Root CA X3
-----BEGIN CERTIFICATE-----
XXX
-----END CERTIFICATE-----
Bag Attributes
localKeyID: E2 43 99 C5 23 2A 7B 66 C8 C2 9F 79 89 83 71 CA C5 B2 63 AE
Key Attributes:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,C9E7EE848C4ED263
XXX
-----END RSA PRIVATE KEY-----
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).
1 Like
For just checking cert validity and chain, you can also use www.sslshopper.com that only perform test on that and so is quicker than SSL Labs.
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.
This problem is also discussed here How to use the certificate for Tomcat
For some weird reason, ended up having to create the cert chain again this way…
openssl pkcs12 -in certificate-all.pfx -out clientcert.pem -nodes -clcerts cat clientcert.pem lets-encrypt-x3-cross-signed.pem dst-root-ca-x3.pem >> clientcertchain.pem openssl pkcs12 -export -in clientcertchain.pem -out clientcertchain.pfx keytool -importkeystore -srckeystore clientcertchain.pfx -srcstoretype pkcs12 -destkeystore clientcertchain.jks -deststoretype JKS
There seems to be a problem with the PS4 Browser and let's encrypt:
). More details here:
The list of browsers presented by sslabs doesn’t mean that the certificate is accepted there, it only checks the negotiated ciphers.
3 Likes
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.
This is not correct specifically for Java 6 and older Android. The Browser part is only be based on cipher suite and Protocol not certificate related.
2 Likes
It doesn’t check certificate trust in the browser section? 
As I said, I just checks the cipher compatibility.
Trust is only checked against the Mozilla store, the browser section only show which cipher will be used (if any).
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.
1 Like
Out of interest, is there a Root CA that’s known to be more widely distributed than “DST Root CA X3”?
Are there lists similar to this list for other Root CAs?
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.
1 Like