openssl-users Digest, Vol 73, Issue 29

定平袁 pkudingping at
Fri Jan 1 11:32:08 UTC 2021

@Jochen Bern <Jochen.Bern at>
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
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.Wojcik at> 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.


Michael Wojcik <Michael.Wojcik at> 于2020年12月29日周二 上午7:16写道:

> > From: openssl-users <openssl-users-bounces at> 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 "", the server's
> certificate should have a DNS-type sAN with the value "". 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 "", 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openssl-users mailing list