But, if you didn't need alternatives, you didn't need to use this field. Except, apparently (I was not previously aware) for some time this behaviour was deprecated and we were not supposed to be using the CN/Subject field: the SAN field was to be used even if only one entry was required.
Chrome is now enforcing this: so if you have an otherwise perfectly good certificate, that only has CN but no SAN, you will get a NET::ERR_CERT_COMMON_NAME_INVALID error:
You can of course use the Advanced link to add an exception.
Now, Discovery's Certificate Signing Request creation does not currently have any mechanism to support SANs. I am hoping a new feature to be released in the next major product release, but of course I can't guarantee that. Regardless, your CA that signs CSRs should be able to add the appropriate single-SAN entry even if the CSR doesn't contain any SAN data - but if it doesn't - you should now know why you get the above error.