Viktor Dukhovni wrote in <ZVfL71uXm9bO-ozv@xxxxxxxxxxxxxxxxxxx>: |On Fri, Nov 17, 2023 at 07:15:11PM +0100, Steffen Nurpmeso wrote: | |> RFC 9525 changes the way TLS certification is done: |> |> * The server identity can only be expressed in the subjectAltNames |> extension; it is no longer valid to use the commonName RDN, known |> as CN-ID in [VERIFY]. |> |> Not such a big surprise as already the book "Network Security with |> OpenSSL" (O'Reilly, ISBN 0-596-00270-X, June 2002; Thank you!) |> states: |> |> The common practice with X.509v1 certificates was to put the |> FQDN in the certificate's commonName field of the subjectName |> field. This practice is no longer recommended for new |> applications since X.509v3 allows certificate extensions to hold |> the FQDN as well as other identifying information, such as IP |> address. The proper place for the FQDN is in the dNSName field |> of the subjectAltName extension. |> |> Nonetheless commonName is tested (and sometimes even falsely in |> addition to subjectAltName, as just recently fixed for the MUA |> i maintain (then removed entirely as a fixup)). | |Is this is an observation, feature requestion, bug report or something |else? The documentation of X509_check_host(3) includes: Oh! Wait!! I have no idea of how OpenSSL does that, i was talking about software which implements a verify callback. Interesting, actually, i did not know this function exists, or have it forgotten. Do you know a software which uses it?? (Except openssl / libcrypto itself?) Hm, usr.sbin/rpc.tlsservd of FreeBSD does, other than that no software of any BSD nor those which i track via git uses it. | The flags argument is usually 0. It can be the bitwise OR of the | flags: | | X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT, | X509_CHECK_FLAG_NEVER_CHECK_SUBJECT, | X509_CHECK_FLAG_NO_WILDCARDS, | X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS, | X509_CHECK_FLAG_MULTI_LABEL_WILDCARDS. | X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS. | | The X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT flag causes the function to | consider the subject DN even if the certificate contains at \ | least one | subject alternative name of the right type (DNS name or email \ | address | as appropriate); the default is to ignore the subject DN when \ | at least | one corresponding subject alternative names is present. | | The X509_CHECK_FLAG_NEVER_CHECK_SUBJECT flag causes the function to | never consider the subject DN even if the certificate contains no | subject alternative names of the right type (DNS name or email \ | address | as appropriate); the default is to use the subject DN when no | corresponding subject alternative names are present. If both | X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT and | X509_CHECK_FLAG_NEVER_CHECK_SUBJECT are specified, the latter takes | precedence and the subject DN is not checked for matching names. | |In practice, applications should not use X509_check_host(3) directly, |and instead configure the verify parameters that will be used for |build-in checks: | | X509_VERIFY_PARAM_set1_host(3): That is used by some more. Unbound, usr.bin/ftp/ of NetBSD. Hm. :) | When a hostname is specified, certificate verification automatically | invokes X509_check_host(3) with flags equal to the flags argument \ | given | to X509_VERIFY_PARAM_set_hostflags() (default zero). Applications \ | are | strongly advised to use this interface in preference to explicitly | calling X509_check_host(3), hostname checks may be out of scope with | the DANE-EE(3) certificate usage, and the internal check will be | suppressed as appropriate when DANE verification is enabled. | |See also SSL_set_hostflags(3): | | SSL_set_hostflags() sets the flags that will be passed to | X509_check_host(3) when name checks are applicable, by default the | flags value is 0. See X509_check_host(3) for the list of available | flags and their meaning. | |Are you asking for | | X509_CHECK_FLAG_NEVER_CHECK_SUBJECT | |to become the default? Should there then be a new flag to override the |new default? | |How soon do we expect various non-public intramural certificate issuance |processes to switch away from relying on the Subject CN and to be sure |to always include a DNS (or perhaps email) SAN? That is an interesting question. |The new RFC is certainly fair warning to issuers that 20+ years on they |**really** should no longer rely on the subject CN to carry the |presented identifier. But when can OpenSSL realistically break |backwards compatibility and start failing name checks for CN-only |certificates? I was really more about programs doing TLS verification. Interesting that so few actually do it like you say, aka all the above. I have to read about that! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
