openssl-users Digest, Vol 73, Issue 29

[定平袁]

@Jochen Bern <Jochen.Bern at 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.Wojcik at 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.Wojcik at microfocus.com> 于2020年12月29日周二 上午7:16写道：

> > From: openssl-users <openssl-users-bounces at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20210101/ae3080dd/attachment.html>