<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 9/20/2017 2:25 PM, Viktor Dukhovni
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3B0606C4-DA55-431B-A74A-F35CD203B9D1@dukhovni.org">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">On Sep 20, 2017, at 12:33 PM, Jordan Brown <a class="moz-txt-link-rfc2396E" href="mailto:openssl@jordan.maileater.net"><openssl@jordan.maileater.net></a> wrote:
Q: Does OpenSSL's trust-list verification support trusting multiple certificates with the same subject name and overlapping validity periods?
In more detail:
We have customers who issue replacement certificates with the same subject name and different validity periods. We'd like to be able to straightforwardly add the new certificates to the trust list and have them work, but seem to find that certificate verification doesn't handle the case. (Mozilla NSS does seem to handle it.)
</pre>
</blockquote>
<pre wrap="">
Generally speaking, if the latest certificate has the same key, then
it should cover the older ones, which can be dropped from the trust list.
If, however, the newer certificates have a different key, then everything
should work, provided the certificates issued under the new key carry
an "authority key identifier" extension, which matches the corresponding
"subject key identifier" in the issuer CA certificate.
The above also works with "authorityCertSerialNumber", see
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc5280#section-4.2.1.1">https://tools.ietf.org/html/rfc5280#section-4.2.1.1</a>
If, however, the newer certificate has a different key, and the same
subject DN, but does not place matching distinct subject key identifiers
in the certificates it issues, then OpenSSL will not correctly handle
multiple candidate issuers that differ in the public key, but provide
no hints in the issued certificates which issuer to use.</pre>
</blockquote>
<br>
I'm not familiar with those extensions and will need to do more
research.<br>
<br>
However, it sounds like you're assuming a CA-issued certificate
where we have the CA certificate in the trust list.<br>
<br>
That's not the case. These are (in the most relevant cases)
self-signed certificates or CA-issued certificates where we have
only the leaf certificate in the trust list.<br>
<br>
I suspect that they are indeed falling into that last case, where
the only way to know which certificate in the trust list is "right"
is to try the crypto verification on each trusted certificate until
one succeeds. (Or just compare the certificate presented with the
ones in the trust list.)<br>
<pre class="moz-signature" cols="72">--
Jordan Brown, Oracle Solaris</pre>
</body>
</html>