Or https://whatsmychaincert.com/ 
That's by far the fastest analyse for this case.
I have removed the PS3 section (hope you don't mind, @mrtux 
). 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
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.
and this is one of the problems in the CA system (well rather with how it's used in the real world rather than the system itself), many certs dont get restraint where they should, beacuse if someone would be able to get a fraudulent signature they can do code signing with it even though it isnt suposed to do that in the first place.
and dont come with CT. CT just cannot work with code signing as a signed software supposed to work offline, so have fun trying that.
In order to implement the standard clients verifying a code signing certificate should verify that the code signing EKU is present in the certificate. As Letâs Encrypt does not issue these certificates (as long as clients implement the standard correctly) there is no real risk of code signed by a Letâs Encrypt certificate being trusted.
but it still should be constrained because IF anything bad happens (greetings from murphyâs law) and if such a cert appears it will be quite a problem because offline systems cant verify its revocation status.
1 Like
A post was split to a new topic: XP compatibility issues