Re: openssl-users Digest, Vol 73, Issue 29

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: openssl-users Digest, Vol 73, Issue 29

Jochen Bern
On 25.12.20 00:35, [hidden email] digested:
> Message: 3
> Date: Fri, 25 Dec 2020 07:35:40 +0800
> From: ??? <[hidden email]>
>
> @Jochen actually, the certs have different SN, which indeed is not
> consistent with the man doc.

... how so? Different certs having different SNs is what is supposed and
most often *required* to happen, and what OpenSSL's "ca" command will
actually do, so I'd be rather surprised if one of the man pages implied
the opposite. Short of the user overriding OpenSSL defaults outright, of
course.

> below is my ca.crt file, I am not sure where it went wrong, maybe just my
> wrong behavior?

(For the records:

*Different* keypair, SN, validity period (but see below), signature.
*Identical* DNs, algos, keysizes, extension (one DNS SAN).
*Self-signed* certs, no actual CA invoved.

CN and SAN indicate "nsxmanager.pks.vmware.local", so it might play a
role what kind of DNS (public or internal) is used while verifying an
actual server.

Validity periods of 10 years, but differ only by a shift of ~39h ...
you're still *testing*, not fixing a legacy installation, right?)

> Re post my code here, since I send it alone to Michael.

I don't do actual *coding* (much), but this here:

> After I compile curl with openssl backend, the new binary failed too.
>
> ./curl.openssl -vvvv -u admin:'Admin!23Admin'
> https://nsxmanager.pks.vmware.local/api/v1/spec/vmware/types/Tag --cacert
> ./ca.crt
[...]
> * SSL certificate problem: self signed certificate
> * Closing connection 0
> curl: (60) SSL certificate problem: self signed certificate
> More details here: https://curl.se/docs/sslcerts.html
[...]

suggests that it might play a role that you're working with
*self-signed* certs ...

As I said, I don't *code*, but the verify(1) command line tool shows the
exact same behavior of only OKing the one out of your two certs that
appears *first* in the CAfile:

> $ openssl verify --CAfile TMP-AB TMP-A TMP-B
> TMP-A: OK
> C = US, ST = CA, L = Palo Alto, O = VMware, CN = nsxmanager.pks.vmware.local
> error 18 at 0 depth lookup: self signed certificate
> error TMP-B: verification failed

> $ openssl verify --CAfile TMP-BA TMP-A TMP-B
> C = US, ST = CA, L = Palo Alto, O = VMware, CN = nsxmanager.pks.vmware.local
> error 18 at 0 depth lookup: self signed certificate
> error TMP-A: verification failed
> TMP-B: OK

Whereas, when I throw in another, entirely *different* cert ... :

> $ openssl verify --CAfile TMP-ABC TMP-C
> TMP-C: OK

So, yeah, it seems that OpenSSL dislikes seeing multiple
partially-identical "CA" certs in a CAfile. Which doesn't surprise me
quite *that* much, because I remember *stronger* adverse reactions to
CAfiles where certs had identical DNs and overlapping(!) validity
periods back in 2012. IIRC I also found docs saying that that was an
officially unsupported scenario.

Back then, I "fixed" the "problem" by appending A,B,C,... to the CN -
which was possible because we're using *actual CAs* there. 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 ...

Kind regards,

Jochen Bern
Systemingenieur

Binect GmbH


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: openssl-users Digest, Vol 73, Issue 29

Michael Wojcik
> From: openssl-users <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

RE: openssl-users Digest, Vol 73, Issue 29

Michael Wojcik
In reply to this post by Jochen Bern
> From: openssl-users <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: openssl-users Digest, Vol 73, Issue 29

定平袁
[hidden email]
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.

[hidden email] 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 <[hidden email]> 于2020年12月29日周二 上午7:16写道:
> From: openssl-users <[hidden email]> 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