Re: openssl-users Digest, Vol 73, Issue 29
@Jochen Bern 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 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 于2020年12月29日周二 上午7:16写道： > > From: openssl-users 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 >
RE: openssl-users Digest, Vol 73, Issue 29
> From: openssl-users 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
RE: openssl-users Digest, Vol 73, Issue 29
> From: openssl-users 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
Re: openssl-users Digest, Vol 73, Issue 29
On 25.12.20 00:35, openssl-users-requ...@openssl.org digested: > Message: 3 > Date: Fri, 25 Dec 2020 07:35:40 +0800 > From: ??? > > @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 - -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 Description: S/MIME Cryptographic Signature
