fyi: RFC 9525 obsoletes commonName check

[Viktor Dukhovni]

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:

       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):

       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?

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?

-- 
    Viktor.