<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Some additional thoughts below.<br>
    </p>
    <div class="moz-cite-prefix">On 1/4/25 3:45 AM, Tim Jacomb wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAH-3BifzeDGPz_toYjCJeOYFbhMERvPv4WjL4rN7UZB5VGZHUg@mail.gmail.com">
      <div>Following on from:</div>
      <div><a href="https://bugs.openjdk.org/browse/JDK-8320362" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8320362</a></div>
      <div><br>
      </div>
      <div>It's now possible to get system roots on macOS devices in the
        truststore: KeychainStore-ROOT.</div>
      <div>That's quite useful.</div>
      <div><br>
      </div>
      <div>Unfortunately it doesn't cover everything though.</div>
      <div>In practice there's two issues I've found in trying to use
        it:</div>
      <div><br>
      </div>
      <div>1. It is missing custom CA certificates, (which would have
        been included if Apple APIs
        - SecTrustCopyCustomAnchorCertificates were used, see discussion
        at
        <a href="https://github.com/openjdk/jdk/pull/16722#issuecomment-1948542783" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/pull/16722#issuecomment-1948542783</a>)<br>
      </div>
    </blockquote>
    <p>I don't think you are suggesting this, but I don't think it
      should include custom CA certificates if they are stored or
      trusted differently than roots. <span class="bold">KeychainStore-ROOT
        should represent the System Roots that have been approved by
        Apple's root program. It is important that we don't change that
        meaning. If there is a way to import a custom CA into System
        Roots and mark it trusted, then maybe it would just work. Have
        you tried that?<br>
      </span></p>
    <blockquote type="cite" cite="mid:CAH-3BifzeDGPz_toYjCJeOYFbhMERvPv4WjL4rN7UZB5VGZHUg@mail.gmail.com">
      <div>2. It is missing intermediate certificates which are required
        for custom CA certificates, (these are not included with
        SecTrustCopyCustomAnchorCertificates although the root CAs above
        are).</div>
    </blockquote>
    Why do you need to include intermediate CA certificates? Typically,
    these would be sent by a TLS server and validated as part of a
    certificate chain. If you are sending a truncated chain and
    short-circuiting the validation process by trusting the intermediate
    CA directly, then maybe those intermediate CAs should be treated
    just like a root CA, as they really are anchors.<br>
    <blockquote type="cite" cite="mid:CAH-3BifzeDGPz_toYjCJeOYFbhMERvPv4WjL4rN7UZB5VGZHUg@mail.gmail.com">
      <div><br>
      </div>
      <div>The architecture at my company that is using ZScaler MiTM
        proxy is:</div>
      <div>Root CA -> Intermediate 1 -> Intermediate 2 -> Leaf</div>
      <div><br>
      </div>
      <div>Where:</div>
      <div>
        <ul>
          <li>All certs are in admin domain kSecTrustSettingsDomainAdmin</li>
          <li>Root CA is marked as always trust</li>
          <li>Intermediate 1 and 2 are Unspecified</li>
        </ul>
        <div>Not all certificates get re-signed by Zscaler, some URLs
          are bypassed.</div>
        <div>So I need to be able to trust both custom CAs and the
          predefined roots.</div>
        <div><br>
        </div>
        <div>I was thinking of creating a new truststore:
          KeychainStore-ALL.</div>
        <div>I think it could just reuse all the existing code, and work
          pretty seamlessly, (I have a separate patch for intermediate
          certs not working correctly -
          <a href="https://github.com/openjdk/jdk/pull/22911" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/pull/22911</a>).</div>
      </div>
    </blockquote>
    Based on my questions above, I am not sure yet whether this
    Enhancement is something that would be useful.<br>
    <br>
    If you are proposing that we look at your contribution, have you
    signed the OCA?: <a class="moz-txt-link-freetext" href="https://openjdk.org/guide/#sign-the-oca">https://openjdk.org/guide/#sign-the-oca</a>. But even
    before we look at that, I think you need to describe the use case
    more, and the motivation. Can you explain how your server
    certificate is configured and how the TLS handshake fails and why?<br>
    <br>
    Thanks,<br>
    Sean<br>
    <br>
    <blockquote type="cite" cite="mid:CAH-3BifzeDGPz_toYjCJeOYFbhMERvPv4WjL4rN7UZB5VGZHUg@mail.gmail.com">
      <div>
        <div><br>
        </div>
        <div>It could be improved at the expense of more code to use the
          Apple APIs directly (SecTrustCopyCustomAnchorCertificates) and
          not read the keychain file.</div>
        <div><br>
        </div>
        <div>What do you think?</div>
      </div>
    </blockquote>
  </body>
</html>