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.
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:
The list of browsers presented by sslabs doesn’t mean that the certificate is accepted there, it only checks the negotiated ciphers.
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.
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.
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.
Because the DST root is trusted for those purposes and the intermediate does not have any EKU constraints.
As I understand it Apple don’t have a very fine-grained trust system unlike Microsoft. Remember that crt.sh is only a service from Rob at Comodo, it’s not an official communication of any trust store’s policies, and Apple might internally have some mechanism that makes certificates issued by LE not work for these purposes, but equally they might not.
Although there are a lot of X.509 certificates in the world, my personal opinion is that in terms of public systems only the Web PKI (ie for TLS certificates on the public Internet) is subject to any real weight of oversight. So, if you can be trusted in the Web PKI, that’s good enough.
In the SHA-1 exception process all the payment suppliers basically keep saying, well, probably we should have some sort of trust relationships for financial stuff, but we’d have to agree what the rules were and we’ve never gotten around to it, so actually everything basically depends on the major Web PKI trust stores, Mozilla, Microsoft, Apple and Oracle. Some proprietary backend systems aren’t tied to the Web PKI, but a huge proportion of financial transaction stuff is.