openssl-users Digest, Vol 73, Issue 29

[Jochen Bern]

On 25.12.20 00:35, openssl-users-request at openssl.org digested:
> Message: 3
> Date: Fri, 25 Dec 2020 07:35:40 +0800
> From: ??? <pkudingping at gmail.com>
> 
> @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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20201225/140c4d10/attachment-0001.bin>