On Sat, Nov 18, 2023 at 11:21:16AM +0100, Georg Höllrigl wrote: > > CN was deprecated in May 2000 - RFC 2818: > If a subjectAltName extension of type dNSName is present, that MUST > be used as the identity. Otherwise, the (most specific) Common Name > field in the Subject field of the certificate MUST be used. Although > the use of the Common Name is existing practice, it is deprecated and > Certification Authorities are encouraged to use the dNSName instead. Note the **If**, and the mandatory fallback to CN. So at that time it was superceded by SAN, but not yet effectively deprecated. > In 2017 Chromium enforced use of SAN, and to my knowledge the other browsers followed: > > https://chromestatus.com/feature/4981025180483584 > https://textslashplain.com/2017/03/10/chrome-deprecates-subject-cn-matching/ These actually removed support for CN-ID, and it is great that the browsers are in a position to do that. OpenSSL, however, is used in all kinds of intramural legacy systems, and backwards-compatibility is an important consideration. If we stop accepting CN-ID fallback by default, barring evidence that "nobody" still relies on CN-ID, OpenSSL should at least initially (in the first LTS release that changes the default) provide a flag that reënables the fallback, and only remove support in a subsequent release, giving users ample time to make the transition. What is the aim of this thread, is it a question, feature request, bug report, or preliminary discussion? -- Viktor.
