<div dir="ltr"><a class="gmail_plusreply" id="plusReplyChip-11" href="mailto:Jochen.Bern@binect.de" tabindex="-1">@Jochen Bern</a><div>Thanks for your reply!</div><div><br></div><div>I didn't describe the problem clearly due to lack of tls domain knowledge.</div><div>Now I know my cert is self-signed end entity cert, and the statement I found <br></div><div>on openssl website does not apply to me. The behavior is similar(Actually not the same,</div><div>since my two certs have different serial number, at first I did not notice this, mistakenly thought my <br></div><div>two certs are the same) is just because I hit another unofficial/non-standard support like you and David pointed out.</div><div><br></div><div>The way you suggested to add timestamp to OU definitely works, because in my test</div><div>I actually noticed this result(different certs can be distinguished correctly), but I'm just not sure</div><div> if it is acceptable to my current case, but anyway David's solution works for me.</div><div><br></div><div><a class="gmail_plusreply" id="plusReplyChip-12" href="mailto:Michael.Wojcik@microfocus.com" tabindex="-1">@Michael Wojcik</a> Thanks again for your help!</div><div>in my case, the CN and sAN part are easy, since we only need to support one FQDN, it does not change.</div><div><br></div><div>Looks like I missed this email since the title changed.<br></div><div><br></div><div>Regards,</div><div>Dingping<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Michael Wojcik <<a href="mailto:Michael.Wojcik@microfocus.com">Michael.Wojcik@microfocus.com</a>> 于2020年12月29日周二 上午7:16写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> From: openssl-users <<a href="mailto:openssl-users-bounces@openssl.org" target="_blank">openssl-users-bounces@openssl.org</a>> On Behalf Of Jochen<br>
> Bern<br>
> Sent: Friday, 25 December, 2020 03:37<br>
<br>
I believe David von Oheimb has already provided a solution for the original problem in this thread (setting subjectKeyIdentifier and authorityKeyIdentifer lets OpenSSL pick the right certificate from the trust-anchor collection). I wanted to comment on this tangential point:<br>
<br>
> For server<br>
> certs, where you need the CN to match the FQDN, you might want to add an<br>
> OU with a timestamp so as to have the *DN* as a whole differ ...<br>
<br>
If your entity certificate is X.509v3 and the client complies with RFC 5280, the CN of the Subject DN shouldn't matter, as long as the server name *as expected by the peer* appears in a subjectAlternativeName extension.<br>
<br>
That is, if the client wants to connect to "<a href="http://www.foo.com" rel="noreferrer" target="_blank">www.foo.com</a>", the server's certificate should have a DNS-type sAN with the value "<a href="http://www.foo.com" rel="noreferrer" target="_blank">www.foo.com</a>". If the client wants to connect to the unqualified hostname "foo", the server's certificate should have a DNS-type sAN with the value "foo". If the client wants to connect to "192.168.2.1", the server's certificate should have an IPADR-type sAN with that value. And so on. If any sANs are present, the CN (if any) of the Subject DN should be ignored.<br>
<br>
Here "wants to connect" is defined by the application and/or its TLS implementation. The implementation may provide a way for a client to specify the subject-name it wants to find in the entity certificate, or it may simply take whatever hostname or IP address string it's asked to connect to, and use that.<br>
<br>
Also remember that OpenSSL prior to 1.0.2 didn't have support for checking hostnames at all. With 1.0.2 you have to make some non-obvious calls to set the expected name, and with 1.1.0 and later you need to use SSL_set1_host (or the 1.0.2 method); there's a page on the OpenSSL wiki for this. I don't remember if this has changed again in 3.0.<br>
<br>
--<br>
Michael Wojcik<br>
</blockquote></div>