@Jochen Bern
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 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.Wojcik@xxxxxxxxxxxxxx> 于2020年12月29日周二 上午7:16写道：
> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> 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
