Today, on the weekend, I encountered one of those Exchange Server issues that makes you question everything you know about Microsoft's documentation. What should have been a simple certificate assignment to a Send Connector turned into hours of frustration, multiple failed attempts, and eventually discovering yet another undocumented Exchange bug.
The Simple Task That Wasn't
This means I need to manually assign a TLS certificate to an Exchange Send Connector. Simple enough, right? I had a perfectly valid DigiCert certificate with both server and client authentication capabilities, already enabled for SMTP services. The certificate looked good:
FriendlyName : autodiscover.bythepowerofgreyskull.com
Subject : CN=autodiscover.bythepowerofgreyskull.com, O=By The Power of Greyskull Limited, L=Castle Grayskull, C=GB
Thumbprint : 7B8E9A2C5F1D6349AB0C8E7F2A9B4D6E8C1A5F73
Services : SMTP
Perfect. Now I just needed to assign it to my Send Connector using Microsoft's documented approach.
Bind the new Certificate to the Send Connector
I started with the standard Microsoft-documented method:
$TLSCert = Get-ExchangeCertificate -Thumbprint 7B8E9A2C5F1D6349AB0C8E7F2A9B4D6E8C1A5F73
$TLSCertName = "$($TLSCert.Issuer)$($TLSCert.Subject)"
Set-SendConnector -Identity "Snake Mountain Mail Relay" -TlsCertificateName $TLSCertName
Result: FAIL
Powershell gave be some nasty red outputs:
Cannot process argument transformation on parameter 'TlsCertificateName'.
Cannot convert value
"CN=DigiCert G2 TLS EU RSA4096 SHA384 2022 CA1, O=DigiCert Ireland Limited, C=IE
CN=autodiscover.bythepowerofgreyskull.com,
O=By The Power of Greyskull Limited, L=Castle Grayskull, C=GB" to type
"Microsoft.Exchange.Data.SmtpX509Identifier".
Error: ""CN=DigiCert G2 TLS EU RSA4096 SHA384 2022 CA1, O=DigiCert Ireland Limited,
C=IECN=autodiscover.bythepowerofgreyskull.com, O=By The Power of Greyskull Limited,
L=Castle Grayskull, C=GB" isn't a valid Certificate Identifier."
The Descent Into Madness
Thinking I was doing something wrong, I tried every "logical" variation I could think of:
Attempt 1: Just the Subject
$TLSCertName = $TLSCert.Subject
Set-SendConnector -Identity "Snake Mountain Mail Relay" -TlsCertificateName $TLSCertName
Same error.
Attempt 2: Just the FriendlyName
Set-SendConnector -Identity "Snake Mountain Mail Relay" -TlsCertificateName
$TLSCert.FriendlyName
Same error.
Attempt 3: Just the FQDN
Set-SendConnector -Identity "Snake Mountain Mail Relay" -TlsCertificateName
"autodiscover.bythepowerofgreyskull.com"
Same error.
Attempt 4: Just the Thumbprint
Set-SendConnector -Identity "Snake Mountain Mail Relay"
-TlsCertificateName "7B8E9A2C5F1D6349AB0C8E7F2A9B4D6E8C1A5F73"
Same error.
Attempt 5: Various Thumbprint Formats
# With colons
Set-SendConnector -Identity "Snake Mountain Mail Relay" -TlsCertificateName "7B:8E:9A:2C:5F:1D:63:49:AB:0C:8E:7F:2A:9B:4D:6E:8C:1A:5F:73"
# Lowercase
Set-SendConnector -Identity "Snake Mountain Mail Relay" -TlsCertificateName "7B8E9A2C5F1D6349AB0C8E7F2A9B4D6E8C1A5F73"Same errors, every time.
The Frustration Builds
At this point, I was convinced something was fundamentally wrong. The certificate was valid, it was enabled for SMTP, and I was following Microsoft's own documentation. Yet every single approach resulted in the same SmtpX509Identifier conversion error.
I even tried the "proper" X509 format with the uppercase tags:
$TLSCertName = "<I>$($TLSCert.Issuer)<S>$($TLSCert.Subject)"
Set-SendConnector -Identity "Snake Mountain Mail Relay" -TlsCertificateName $TLSCertNameStill failed.
The Breaking Point
After exhausting every "logical" approach, I decided to research this specific error online. Surely someone else had encountered this madness before.
Discovery : Exercise caution - There be dragons
While the Internet can be quite a helpful place there will be many articles that will lead you down a rabbit hole that was never going to get you to the solution to start with, for example, if you’re a fan of forums like Reddit other such community forums included people, jumping into conclusions without understanding the problem.
I would also like to add that many forum posts told me I had an invalid certificate and I need to regenerate a new certificate that had the correct certificate attributes added to the certificate - this was also incorrect because there was nothing wrong with the certificate - this advice would’ve been potentially dangerous to the stability and availability of Exchange.
If you were just going to search for the error without understanding where the problem could potentially be located then do exercise caution at the advice you follow - just because it fixed one person’s problem does not mean it will fix your problem unless the scenario matches exactly - I also avoid community lead forums because they are usually full of unhelpful comments that people will take as commands.
The Discovery: Microsoft's Hidden Bug
After digging through Microsoft forums and other blog posts, and various Exchange blogs, I discovered the ugly truth: This is a known bug in Exchange Server that Microsoft has never properly documented or fixed.
The issue occurs when certificate fields contain quotes in the Issuer or Subject lines. Looking at my certificate's full Issuer field:
CN=DigiCert G2 TLS EU RSA4096 SHA384 2022 CA1, O="DigiCert Ireland Limited", C=IE
Notice the quotes around "DigiCert Ireland Limited"- well those quotes break PowerShell's parsing of the certificate identifier, causing the SmtpX509Identifier type conversion to fail.
The Undocumented Fix
The solution that actually works is completely undocumented by Microsoft but widely known in the Exchange community:
Use lowercase <i> and <s> tags instead of uppercase:
$TLSCert = Get-ExchangeCertificate -Thumbprint 7B8E9A2C5F1D6349AB0C8E7F2A9B4D6E8C1A5F73
$TLSCertName = "<i>$($TLSCert.Issuer)<s>$($TLSCert.Subject)"
Set-SendConnector -Identity "Snake Mountain Mail Relay" -TlsCertificateName $TLSCertNameThis worked immediately.
Restore email delivery
Now you have fixed The problem with the send connector being bound to the wrong certificate due to the details above, you’ve just been through, you now need to restart all the transport service on your Exchange servers:
Get-ExchangeServer | ForEach-Object {
Invoke-Command -ComputerName $_.Name -ScriptBlock {
Restart-Service -Name MSExchangeTransport -Force
}
}When this command has successfully executed, the emails will be delivered in order of time and date as the queue update from “retry” to “active” - this process is usually pretty rabbit and it managed to clear all our queues down within the next 15 minutes (that time will depend on how many messages you have)
Verify the send connector
This step is optional but recommended, you have obviously just run a command in Powershell against the send connector, however, if you would like to check that, you’re now using the correct certificate, you can use this command:
Get-SendConnector | Select-Object Name, TlsCertificateNameWhen you execute this command, this should confirm the new certificate as below:Name TlsCertificateName
---- ------------------
Snake Mountain Mail Relay CN=autodiscover.bythepowerofgreyskull.comThe Frustrating Truth
Here's what's infuriating about this entire experience:
- Microsoft's documentation is wrong - The official docs show uppercase
<I>and<S>tags, which fail with quoted certificate fields - The error message is useless - It gives no indication that the issue is with quote parsing
- This has been a known issue for years - I found forum posts dating back to Exchange 2013 with the same problem
- No official fix or acknowledgment - Microsoft has never updated their documentation or fixed the underlying parsing issue
Lessons Learned
- Microsoft's Exchange documentation can't always be trusted - Sometimes the community knows better than the official docs
- Certificate field formatting matters - Quotes in Issuer/Subject fields can break Exchange in unexpected ways
- Case sensitivity matters in Exchange certificate identifiers - Who would have thought lowercase tags would work when uppercase ones fail?
- Always research the error, not just the task - The specific
SmtpX509Identifiererror led me to the real solution
Resolution : The working commands
For anyone else who stumbles into this nightmare, here are the commands that actually work:
# Get your certificate
$TLSCert = Get-ExchangeCertificate -Thumbprint <YourCertThumbprint>
# Create the certificate name using LOWERCASE tags
$TLSCertName = "<i>$($TLSCert.Issuer)<s>$($TLSCert.Subject)"
# Apply to Send Connector
Set-SendConnector -Identity "Snake Mountain Mail Relay" -TlsCertificateName $TLSCertName
# Apply to Receive Connector (if needed)
Set-ReceiveConnector -Identity "Castle Grayskull Frontend" -TlsCertificateName $TLSCertName
Final Thoughts
This experience perfectly encapsulates what's frustrating about working with Exchange Server - what should be straightforward tasks can turn into multi-hour debugging sessions due to undocumented bugs and incorrect official documentation.
The fact that this bug has existed across multiple Exchange versions (2013, 2016, 2019) and Microsoft has never bothered to fix it or update their documentation speaks volumes about their commitment to administrator experience.
At least now you know: when Exchange certificate assignment fails with SmtpX509Identifier errors, try the lowercase tags. It might just save you hours of frustration.