<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 15.02.15 um 19:17 schrieb Jacob
Hoffman-Andrews:<br>
</div>
<blockquote cite="mid:54E0E2CD.9020402@eff.org" type="cite"> Good
point! I think we are also missing some of the most current
certificates from Firefox, which I plan to update: <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://support.google.com/dfp_sb/answer/2524536?hl=en">https://support.google.com/dfp_sb/answer/2524536?hl=en</a>.
If we still have issues after updating those, we may want to
install the transitive closure of those certificates, from the SSL
Observatory.<br>
<br>
</blockquote>
<br>
<br>
<div class="moz-cite-prefix">Am 23.04.15 um 11:40 schrieb Alexander
Buchner:<br>
</div>
<blockquote cite="mid:5538BE22.2040609@posteo.de" type="cite">
<pre wrap="">What should we do with sites with incomplete certificate chains?
I just noticed that my Firefox will download extra certificates on the
fly (and so doesn't complain about the missing certificate(s)) while the
Firefox instance that starts by calling ./test.sh --justrun will not
(and perhaps neither other clients).
Should we write a rule for such a site (e.g. bundesrat.de) or should
their implementation be regarded as broken?
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
HTTPS-Everywhere mailing list
<a class="moz-txt-link-abbreviated" href="mailto:HTTPS-Everywhere@lists.eff.org">HTTPS-Everywhere@lists.eff.org</a>
<a class="moz-txt-link-freetext" href="https://lists.eff.org/mailman/listinfo/https-everywhere">https://lists.eff.org/mailman/listinfo/https-everywhere</a></pre>
</blockquote>
<br>
</body>
</html>