The identity you need to put in the certificate needs to be the one you're looking for via the URL. For example, if you're using https://www.example.net, your certificate needs to be valid for www.example.net; if you're using https://10.0.0.1/, your certificate needs to be valid for 10.0.0.1.
The Common Name RDN in the Subject DN of the certificate is normally only used when (a) there is no Subject Alternative Name DNS entry and (b) it's looking for a host name, not an IP address. This is defined in 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.
[...]
In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.
In general, using IP address in certificates is not recommended (see problems mentioned in RFC 6125. However, if you really need to, you'll need a certificate with the IP address is a SAN entry of IP address type, which you can generate as described in this answer.
