fyi: RFC 9525 obsoletes commonName check

[Steffen Nurpmeso]

Viktor Dukhovni wrote in
 <ZVfL71uXm9bO-ozv at straasha.imrryr.org>:
 |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)