> From: openssl-users <openssl-users-boun...@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
