<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 10/03/18 14:20, John Fawcett wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:2bd58f53-ba34-226f-358f-4ad33bc51eb4@voipsupport.it">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div class="moz-cite-prefix">On 10/03/18 14:06, Aki Tuomi wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:1749469943.270.1520687176178@appsuite-dev.open-xchange.com">
        <meta charset="UTF-8">
        <div> <br>
        </div>
        <blockquote type="cite">
          <div> On 10 March 2018 at 14:49 John Fawcett < <a
              href="mailto:john@voipsupport.it" moz-do-not-send="true">john@voipsupport.it</a>>
            wrote: </div>
          <div> <br>
          </div>
          <div> <br>
          </div>
          <div> On 08/03/18 18:43, Peter Linss wrote: </div>
          <blockquote type="cite">
            <div> I just added an ECDSA certificate to my mail server
              using ssl_alt_cert (the RSA certificate is specified by
              ssl_cert), both certificate files contain the certificate
              and a single intermediate (which currently happens to be
              the same intermediate from Let’s Encrypt). </div>
          </blockquote>
          <blockquote type="cite">
            <div> When connecting to the server using either RSA or
              ECDSA ciphers, the server sends the proper certificate,
              but also sends two intermediates. Apparently it’s reading
              the intermediate from both files and using both for all
              situations, rather than using only the intermediate in the
              RSA file for RSA certificates, and the intermediate in the
              ECDSA file for ECDSA certificates. I expect this will be a
              bigger problem when Let’s Encrypt starts using ECDSA
              intermediates. </div>
          </blockquote>
          <blockquote type="cite">
            <div> Removing the intermediate from the ssl_alt_cert file
              solves the problem (but then doesn’t allow an ECDSA
              intermediate to be specified). </div>
          </blockquote>
          <div> I believe that supplying multiple unrelated intermediate
            certificates is </div>
          <div> an incorrect behaviour, though I don't know if this is a
            problem that </div>
          <div> can be solved in Dovecot or has to be addressed in
            openssl itself. </div>
          <div> <br>
          </div>
          <div> Do you get any issue in certificate validation in the
            client? </div>
          <div> <br>
          </div>
          <div> John </div>
        </blockquote>
        <div> <br>
        </div>
        <div> You sure your cert file does not contain unrelated
          certificates? </div>
        <div class="io-ox-signature"> --- <br>
          Aki Tuomi </div>
      </blockquote>
      <p>Aki</p>
      <p>I'll leave Peter to respond about his cert files, but in the
        test I did, each the ssl_cert and ssl_alt_cert each contained
        the server cert and the next cert in the chain. However, both
        intermediates were supplied whether using RSA or ECDSA.</p>
      <p>John<br>
      </p>
    </blockquote>
    May need to look into using SSL_CTX_add1_chain_cert() instead of
    SSL_CTX_add_extra_chain_cert()<br>
    <br>
    John<br>
  </body>
</html>