<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    -----BEGIN PGP SIGNED MESSAGE----- <br>
    Hash: SHA256 <br>
     <br>
    <br>
    <br>
    <br>
    <br>
    This looks like. Root CA doesn't send. Subordinate CA uses as signer
    for mimicked. All and any clients got security alert.<br>
    <br>
    16.12.15 1:38, Alex Rousskov пишет:<br>
    <span style="white-space: pre;">> On 12/14/2015 04:48 PM, Marcus
      Kool wrote:<br>
      >> On 12/14/2015 09:16 PM, Amos Jeffries wrote:<br>
      >>> Squid may be horribly sending<br>
      >>> all-but-one of the certs needed, on the assumption
      that the signing cert<br>
      >>> is itself installed on the client.<br>
      ><br>
      ><br>
      >> The RFC says that it is not necessary to send the signing
      CA certificate.<br>
      ><br>
      ><br>
      > Sending the CA certificate is usually both unnecessary
      (because the<br>
      > clients must have it) and borderline dangerous (because some
      clients do<br>
      > not expect this extra information). This is why, I bet, Squid
      does not<br>
      > send the signing certificate in some cases.<br>
      ><br>
      > On the other hand, sending the signing certificate is
      necessary if that<br>
      > signing certificate is not the CA certificate expected to be
      stored by<br>
      > clients. IIRC, we have fixed at least one Squid bug in this
      area in<br>
      > 2015, but I do not have a reference handy.<br>
      ><br>
      > And there are actually situations in-between the two extremes
      above<br>
      > because a CA (well-known and not) often has its own CA
      certificate<br>
      > hierarchy, and some clients may trust intermediate CA
      certificates [with<br>
      > or without storing the root CA certificate].<br>
      ><br>
      > The above does not answer the OP question. The answer may go
      something<br>
      > like this:<br>
      ><br>
      > If you expect your clients to store your signing certificate,
      then you<br>
      > can configure Squid to sign with that certificate and not
      worry about<br>
      > any higher-level (closer to root) certificate that may or may
      not exist.<br>
      > On the other hand, if your clients are storing a higher-level<br>
      > certificate, then you need to test whether Squid does the
      right thing<br>
      > (i.e., sends the intermediate certificate which also happens
      to be the<br>
      > signing certificate). If Squid does not do the right thing,
      file a bug<br>
      > report.<br>
      ><br>
      ><br>
      > HTH,<br>
      ><br>
      > Alex.<br>
      ><br>
      > _______________________________________________<br>
      > squid-users mailing list<br>
      > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBCAAGBQJWcoqdAAoJENNXIZxhPexGykoIAJsF/fkG0HvtMH6ACAYyc9WN
<br>
    4+1z/UpVrNID4tSJapFPaCBFJ6pGcSQrAXzSzT+94nQZJMMStverO94x+YJ8a4bp
<br>
    hpVzewc0jVu4PCW0+V8YyvCvx0O4/sbEhWywc/dNz22KdAt6JhyWmaJTn22/JYMb
<br>
    xlvEYQ0wZ0r/u2+WMTbcMq1cyAESCYouZSxsmhQubM60d3ZUs25I3AUULEHguzXp
<br>
    JO29tZcy1ZUzQZ9bCmVIwJTHfAjK3jTFRw66LpB2sooMb1O/Xfm+HGbndnpi1+ab
<br>
    98/1Lhz4hTNJRFu4fxMbt1+VqXxp1q3OQA8OOOrbBu8vluFdB3WqwwqV/ACGsPo=
<br>
    =zzWl
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>