这是一个社区编辑的列表，列出了哪些操作系统/浏览器可以连接到使用我们加密证书的服务器。更具体地说，这些系统信任交叉签署ISRG颁发的证书的IdenTrust“DST Root CA X3”证书。

莫兹拉

窗口

Internet Explorer(和其他使用Windows CryptoAPI的软件)工作正常(Windows信任存储中包括“DST Root CA X3”；如果Windows>=Vista；XP SP3在本地丢失，则会自动下载，请参见下面的内容)

Google Chrome可以工作(Windows信任存储中包含“DST Root CA X3”；Windows XP上没有，见下文)

Git for Windows>=2.6(包括“DST Root CA X3”)

Windows XP SP3-需要一些额外的工作才能支持。不支持SNI，并且在支持的密码方面也有问题。在XP SP3上，在2016年3月25日之前颁发的证书不受Chrome、IE和Safari信任。但是，如果您手动配置密码，则在该日期之后颁发的证书可以与XP SP3一起使用。

苹果

爪哇

Linux

Ubuntu>=12.04已知工作正常(“DST Root CA X3”受信任，请参阅Pidgin不信任LE)

黑莓手机

版本>=10.3.3起作用

图书馆

亚马逊FireOS(Silk浏览器)

氰化物10，

Jolla SailFish OS 1.1.2.16

Kindle v3.4.1

不清楚

BlackBerry OS 6、7和10.3.2及更低版本(>=10.3.3应支持根据包含的ISRG根进行加密)

安卓2.3.5(HTC Wildfire S，股票浏览器)

任天堂3DS

Windows XP-SP3之前版本-无法处理SHA256签名证书

Windows Live Mail(2012邮件客户端，不是WebMail)-根据Windows Live Mail吊销警告，如果没有CRL，它无法处理证书。信任链是(深入的)

您的服务器

让我们加密X1(必须作为链的一部分发送)

DST根CA X3(锚点)

对于(几乎)任何其他权威机构来说

您的服务器

中间(必须作为链的一部分从服务器发送)

CA Anchor(锚，在浏览器存储中)

因此，正如您所看到的，信任链中的证书计数没有差别，

即使目前没有ISRG锚，DST Root CA X3也像它一样。

更糟糕的例子是信任链：

您的服务器

中级

根CA(一些较旧的客户端不信任，因为CA捆绑包不经常更新)*交叉签名

其他根CA(锚定)

(WoSign有这样的链，其他根CA是StartCom)

LE在这里很好，在被客户端信任的问题上，传播新的锚点要花费很多时间，如果根CA不在浏览器中，则基于该CA的证书不受信任。而对于较老的Android设备，即使是(老牌？)“DST根CA X3”根CA不是受信任的…因此，大多数CA都会写上“99%的设备都信任”，并列出浏览器/操作系统的位置和时间。这也将对LE有所帮助。-如果你的用户主要使用较旧的Android le不是也不会是一个选项，我已经尝试使用仍然隐藏的根…签名的中间证书结果好坏参半。根(S)丢失，不支持主证书链，也许有人能告诉我请求的是什么信任库和包含？

还有没有其他的跟踪号码可以包括在内？

对于不在上升CA列表中的Mozilla：

也不在包括的名单中：

SP3之前的版本永远不会运行，因为它缺乏对SHA2的支持。

由于我们中间层的名称限制，Chrome和IE目前不能运行。我们将看看从长远来看是否有可能解决这个问题，但目前它不起作用。

Firefox之所以能工作，是因为它有自己的验证码。

Windows XP：-SP3之前的版本永远不会运行，因为它缺乏SHA2支持。+SP3：Chrome和IE目前不能工作，因为我们的中间层受名称限制。我们将看看从长远来看是否有可能解决这个问题，但目前它不起作用。-Firefox之所以有效，是因为它有自己的验证码。

另一个原因是服务器配置的SSL密码首选项，有些人可能会配置他们的服务器与Windows XP不起作用的SSL密码，有任何地方收集信息，关于LE是否支持各种防病毒和MITM安全供应商？我遇到了Avast的麻烦。@mholt在另一个帖子中提到了有关其他Windows杀毒软件的“多个报告”

除了操作系统/浏览器支持之外，收集这些信息将是有用的；由于Avast的信任问题，我们不得不暂时停止使用letsEncrypted。你能提供更多关于你在Avast遇到的麻烦的细节吗，包括操作系统版本，浏览器版本，Avast产品和版本，以及屏幕截图？谢谢！，谢谢@jsha。我做出了协调一致的努力，试图在一个VM中重现Avast的问题，但我无法做到。在跟踪客户端后，我发现他们使用的是Windows XP SP3，他们的系统与上面的已知问题一致：在IE和Chrome中存在信任问题，但在最近的Firefox中可以工作。

长话短说：我认为我们的问题不是Avast，而是客户端使用的是Windows XP SP3。在我测试的所有迭代中，Avast在Win7上运行得很好，而在客户的XP SP3机器上禁用Avast没有任何效果(这并不令人惊讶)。

除了@mholt在另一个帖子中的轶事，我没有任何迹象表明Avast有问题，即使它被配置为MITM HTTPS连接。对于FUD，很抱歉，cdetar：

除了@mholt在另一个帖子中的轶事，我没有任何迹象表明Avast有问题，即使它被配置为MITM HTTPS连接。对于FUD我很抱歉。

这并不完全是FUD。诚然，在这种情况下使用的证书不是来自We‘s Encrypt，但我总体上仍然对MITM保持警惕，特别是反病毒软件。，mholt：

总的来说，我仍然对MITM保持警惕，特别是杀毒软件。

浏览器版本很有趣，因为浏览器有自己的CA列表，tlussnig：

如果您使用的浏览器没有自己的CA列表，则操作系统很重要。浏览器版本对于有自己的CA列表的浏览器很有趣

这就是我使用火狐的原因。他们不仅有自己的证书，还有NSS，这意味着MS的问题不是我的问题。->TLS 1.2，AES和EC，甚至在XP上(我不使用它，但你明白我的意思)。