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.
