You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a server side's certificate with no SubjectAltNames, client side should use Common name field in the subject field. But conscrypt only check SubjectAltNames while not subject when it verifies the certificate from server side.
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.
The text was updated successfully, but these errors were encountered:
RFC 2818 is over 20 years old now and the use of CN was deprecated even then, in the text you quote:
Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead
Use of CN led to many security issues over the years and starting in 2017 all the major browsers stopped allowing its use. This was followed in 2018 by okhttp, Android and Conscrypt all dropping support for CN.
If a server side's certificate with no SubjectAltNames, client side should use Common name field in the subject field. But conscrypt only check SubjectAltNames while not subject when it verifies the certificate from server side.
Per RFC 2818 section 3.1,
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.
The text was updated successfully, but these errors were encountered: