On an Exchange 2016/2019/M365/Azure you want to change the TLS Certificate of your Receive Connector.
Your SAN (Subject Alternate Name) or Wildcard Certificate has no Common Name [CN] (Empty).
When you try to assign the cert the regular way you get an error. Nothing wrong with the Cert company just the other side (Requester/Converter) as per RFC.
https://www.rfc-editor.org/rfc/rfc2818
RFC 2918 describes the Common Name
- 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
Below: You can clearly see that Azure/M365 does not solve all 😉 Poor Cloud customer who believe all that sales tells them…..
ERROR:
Cannot process argument transformation on parameter ‘TlsCertificateName’. Cannot convert value “<TLSCertName>” to type “Microsoft.Exchange.Data.SmtpX509Identifier”. Error:
“”<TLSCertName>” isn’t a valid Certificate Identifier.”
+ CategoryInfo : InvalidData: (:) [Set-ReceiveConnector], ParameterBindin…mationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Set-ReceiveConnector
This happens because your Multi Domain/SAN/Wildcard cert was issued without the correct COMMON NAME = CN attribute
Here is a sample shown in Exchange that is correct:
CN= Has a value behind it right side
Here is what the Certificates looks:
Above one with the Common Name, Below one with Common Name missing.
Solution sample for a Receive Connector called “RELAY_SERVER_TLS_PORT_26” on SERVER1
$cert = Get-ExchangeCertificate –Thumbprint 21B5FA4FA9E8D555444A37644437DCE4B9DDC4AACFD
$tlscertificatename = “<i>$($cert.Issuer)<s>$($cert.Subject)”
Set-ReceiveConnector “SERVER1\RELAY_SERVER_TLS_PORT_26” -TlsCertificateName $tlscertificatename
EXTERNAL > DIGICERT Common Name for Wildcard: