@Jochen Bern <jochen.b...@binect.de> Thanks for your reply! I didn't describe the problem clearly due to lack of tls domain knowledge. Now I know my cert is self-signed end entity cert, and the statement I found on openssl website does not apply to me. The behavior is similar(Actually not the same, since my two certs have different serial number, at first I did not notice this, mistakenly thought my two certs are the same) is just because I hit another unofficial/non-standard support like you and David pointed out.
The way you suggested to add timestamp to OU definitely works, because in my test I actually noticed this result(different certs can be distinguished correctly), but I'm just not sure if it is acceptable to my current case, but anyway David's solution works for me. @Michael Wojcik <michael.woj...@microfocus.com> Thanks again for your help! in my case, the CN and sAN part are easy, since we only need to support one FQDN, it does not change. Looks like I missed this email since the title changed. Regards, Dingping Michael Wojcik <michael.woj...@microfocus.com> 于2020年12月29日周二 上午7:16写道: > > From: openssl-users <openssl-users-boun...@openssl.org> On Behalf Of > Jochen > > Bern > > Sent: Friday, 25 December, 2020 03:37 > > 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: > > > For server > > certs, where you need the CN to match the FQDN, you might want to add an > > OU with a timestamp so as to have the *DN* as a whole differ ... > > 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. > > That is, if the client wants to connect to "www.foo.com", the server's > certificate should have a DNS-type sAN with the value "www.foo.com". 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. > > 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. > > 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. > > -- > Michael Wojcik >