Which browsers and operating systems support Let's Encrypt


#44

Or https://whatsmychaincert.com/ :smiley:
That’s by far the fastest analyse for this case.


#45

I have removed the PS3 section (hope you don’t mind, @mrtux :blush:). More details here:


#47

Here’s a complete list from a new certificate tested on Qualsys Labs yesterday.


#48

The list of browsers presented by sslabs doesn’t mean that the certificate is accepted there, it only checks the negotiated ciphers.


#49

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.


#50

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.


#51

It doesn’t check certificate trust in the browser section? :anguished:


#52

As I said, I just checks the cipher compatibility.


#53

Trust is only checked against the Mozilla store, the browser section only show which cipher will be used (if any).


#54

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.


#55

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?


#56

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.


#57

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.


#58

Because the DST root is trusted for those purposes and the intermediate does not have any EKU constraints.


#59

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.


#60

Orly?


#61

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.


#62

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.


#63

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.


split this topic #64

A post was split to a new topic: XP compatibility issues