On 25.12.20 00:35, openssl-users-request@xxxxxxxxxxx digested: > Message: 3 > Date: Fri, 25 Dec 2020 07:35:40 +0800 > From: ??? <pkudingping@xxxxxxxxx> > > @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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
