For a valid X509 certificate, the raw string provided in CertificateString will have that information; my understanding is you cannot have a valid X509 certificate without those details. Clients will provide the full certificate body via CertificateString so that the service can manage the certificate in its entirety within its certificate store or any other certificate repository it contains. While the service is not required to return the full certificate string, at this point it will have all of these details internally in order to represent other properties, like the subject and issuer information.
Ah, my understanding was incorrect then. Looks like it's possible to have several of the fields missing (I would expect common name to always be there though since that's what the certificate is supposed to represent in the first place).
But if a user passes in a certificate without certain fields, then I would expect those respective properties to be omitted from responses when a client performs a GET on the resource. If your implementation has a requirement that a certain field needs to exist in the certificate, then you'll need to add processing of the raw certificate string when the client attempts to create the resource.