New-Mailbox: Invalid certname – EXO PS Module Fails on Passwords Whose Length Is a Multiple of 4
If you’re hitting this error when calling New-Mailbox via the Exchange Online PowerShell module:
New-Mailbox: Invalid certName .
{
"error":{
"code":"InternalServerError",
"message":"Internal server error",
"innererror":{
"message":"Internal server error",
"type":"Microsoft.Exchange.Admin.OData.Core.ODataServiceException",
"stacktrace":"",
"internalexception":{
"message":"Invalid certName .",
"type":"Microsoft.M365.Security.CredSMART.M365SecretException",
"stacktrace":""
}
},
"adminapi.warnings@odata.type":"#Collection(String)",
"@adminapi.warnings":[]
}
} This post explains exactly what’s happening, how it was diagnosed, and what you can do about it.
Background: The Encrypted Password Deprecation
Until recently, the EXO PowerShell module encrypted the -Password parameter before transmitting it to the EXO REST API. This encryption was handled by CredSMART, a Microsoft internal subsystem responsible for secure credential transmission, using a certificate embedded in the temporary .psm1 file generated at connection time.
Microsoft silently removed this encrypted password pathway, and the clear-text transmission that replaced it has since developed its own failure mode.
The New Failure: Passwords Whose Length Is a Multiple of 4
With recent versions of the EXO PS module, New-Mailbox -Password fails with Invalid certName . for passwords whose length is a multiple of 4 – confirmed failing at 12, 16, 20, and 24 characters. All other lengths succeed.
The error message is deeply misleading: it implies a certificate configuration problem on the tenant side, sending you down a rabbit hole of tenant health checks that lead nowhere.
The pattern points directly to a % 4 boundary condition in Microsoft’s CredSMART processing code – most likely a modulo operation on the password length used to derive or index a certificate name, where a zero result maps to a null/empty value instead of a valid cert.
# 11 characters — succeeds
PS C:\> $pass = ConvertTo-SecureString "123456789Ab" -AsPlainText -Force
PS C:\> New-Mailbox -Name "New User1" -ImmutableId "fRBSX+IGQ0Smq3NCKrvP0g==" -PrimarySmtpAddress "new.user1@azure.skrubbeltrang.com" -Alias "new.user1" -FirstName "New" -LastName "User1" -DisplayName "New User1" -MicrosoftOnlineServicesID "new.user1@azure.skrubbeltrang.com" -Password $pass -ResetPasswordOnNextLogon:$false
Name Alias Database ProhibitSendQuota ExternalDirectoryObjectId
---- ----- -------- ----------------- -------------------------
New User1 new.user1 eurprd09.prod.outlook.com/26c… 99 GB (106,300,440,… 77ddecf8-b258-4233-89ae-b63347f1f4a3
WARNING: After you create a new mailbox, you must go to the Office 365 Admin Center and assign the mailbox a license, or it will be disabled after the grace period.
# 12 characters — fails
PS C:\> $pass = ConvertTo-SecureString "123456789AbC" -AsPlainText -Force
PS C:\> New-Mailbox -Name "New User2" -ImmutableId "fRBSX+IGQ0Smq3NCKrvP0g==" -PrimarySmtpAddress "new.user2@azure.skrubbeltrang.com" -Alias "new.user2" -FirstName "New" -LastName "User2" -DisplayName "New User2" -MicrosoftOnlineServicesID "new.user2@azure.skrubbeltrang.com" -Password $pass -ResetPasswordOnNextLogon:$false
New-Mailbox: Invalid certName .
# 13 characters — succeeds
PS C:\> $pass = ConvertTo-SecureString "123456789AbCd" -AsPlainText -Force
PS C:\> New-Mailbox -Name "New User2" -ImmutableId "fRBSX+IGQ0Smq3NCKrvP0g==" -PrimarySmtpAddress "new.user2@azure.skrubbeltrang.com" -Alias "new.user2" -FirstName "New" -LastName "User2" -DisplayName "New User2" -MicrosoftOnlineServicesID "new.user2@azure.skrubbeltrang.com" -Password $pass -ResetPasswordOnNextLogon:$false
Name Alias Database ProhibitSendQuota ExternalDirectoryObjectId
---- ----- -------- ----------------- -------------------------
New User2 new.user2 eurprd09.prod.outlook.com/35f… 99 GB (106,300,440,… f599a509-ed7d-41e7-9919-dcee19f92364
WARNING: After you create a new mailbox, you must go to the Office 365 Admin Center and assign the mailbox a license, or it will be disabled after the grace period.
Same cmdlet, same tenant, incrementally longer password. 11 works. 12 fails. 13 works. Further testing confirmed the same failure at 16, 20, and 24 characters – every multiple of 4.
How It Was Diagnosed
The failure was first observed as an intermittent Invalid certName . error affecting some users but not others. Suspicion initially fell on tenant configuration, module version headers, and JSON serialization differences – all of which were ruled out using Fiddler to capture and surgically replay modified requests.
The methodology: capture a failing request and a successful one, then replay the working body against the failing session with individual values substituted one field at a time. Headers were normalized first (serialization level, trailing slash, consistency headers) – no effect. JSON key ordering and parameter ordering within the body – no effect. ImmutableId, address format, alias – no effect.
When the Password field was isolated as the sole remaining variable and tested with incremental lengths, the exact 12-character boundary emerged. The CredSMART error is not a cert misconfiguration – it is an unhandled internal exception triggered by a specific input length.
Workarounds
Definitive fix – drop -Password entirely. For hybrid accounts provisioned via -ImmutableId, authentication runs through on-premises AD. The EXO password field is irrelevant. For cloud-only accounts, EXO generates a random internal password; set it afterward via the Graph API if you need a specific value:
Invoke-MgGraphRequest -Method POST ` -Uri "https://graph.microsoft.com/v1.0/users/{id}/authentication/methods/password" ` -Body @{ newPassword = "YourNewPassword123!" } | ConvertTo-JsonTemporary workaround – if you must pass -Password for now, ensure your password generator never produces a length that is a multiple of 4 (i.e., avoid 4, 8, 12, 16, 20, 24… characters). This is a fragile hack against an undocumented server-side bug, but it unblocks provisioning while waiting for Microsoft to address it.
Report It to Microsoft
If you can reproduce this, please open a support ticket. Specific, reproducible bugs with clear evidence get prioritized.
Reference the following when filing:
- Cmdlet:
New-Mailbox - Error:
Microsoft.M365.Security.CredSMART.M365SecretException - Message:
Invalid certName . - Reproduction: passwords whose length is a multiple of 4 (12, 16, 20, 24…) trigger the failure; all other lengths succeed
Summary
| Password length | Result |
|---|---|
| Not a multiple of 4 | Succeeds |
| Multiple of 4 (4, 8, 12, 16, 20, 24…) | CredSMART.M365SecretException: Invalid certName . |
This is a regression in Microsoft’s CredSMART clear-text password handling, introduced as part of the transition away from encrypted password transmission in the EXO PS module. The error message is misleading and the failure boundary is non-obvious. The correct fix is to remove -Password from New-Mailbox calls entirely – and given the instability of this parameter across recent module versions, that is the only robust long-term approach.
Supplemental Note: Broader EXO Instability – April 2026
It is worth noting that this bug surfaces against a backdrop of significant active instability in Exchange Online. As of April 17, 2026, the Microsoft 365 Health Center lists the following open advisories:
| ID | Service | Summary | Since |
|---|---|---|---|
| EX1280763 | Exchange Online | Admins unable to progress mailbox migrations | Apr 17 |
| EX1275040 | Exchange Online | Users unable to download or open attachments in OWA | Apr 17 |
| MO1282907 | Microsoft 365 suite | Delays in certain reports in the M365 admin center | Apr 17 |
| EX1280216 | Exchange Online | Failures running admin operations in the EXO admin portal | Apr 16 |
| EX1233142 | Exchange Online | Meeting room availability changes unexpectedly when scheduling | Apr 16 |
| MO1280165 | Microsoft 365 suite | Delays in several M365 Admin Center reports | Apr 15 |
| MV1240680 | Microsoft Viva | Action count shows zero for Copilot email metrics | Apr 14 |
| EX1254044 | Exchange Online | Classic Outlook unusable with Teams Meeting Add-in enabled | Apr 10 |
| PB1224494 | Power BI | Subscription emails to external users failing | Apr 7 |
If you are troubleshooting New-Mailbox failures today, a quick sanity check is to retry with a password whose length is not a multiple of 4. If that succeeds, you are hitting the CredSMART bug described in this post. If it still fails, check EX1280216 – broader admin operation failures in the EXO portal may be the contributing factor.
Update, 2026-04-28, Issue Resolved
We received notice today from Microsoft support that the issue has now been resolved.
Testing confirms this is now working again:
PS C:\> $pass = ConvertTo-SecureString "123456789AbC" -AsPlainText -Force
PS C:\> New-Mailbox -Name "New User2" -ImmutableId "fRBSX+IGQ0Smq3NCKrvP0g==" -PrimarySmtpAddress "new.user2@azure.skrubbeltrang.com" -Alias "new.user2" -FirstName "New" -LastName "User2" -DisplayName "New User2" -MicrosoftOnlineServicesID "new.user2@azure.skrubbeltrang.com" -Password $pass -ResetPasswordOnNextLogon:$false
Name Alias Database ProhibitSendQuota ExternalDirectoryObjectId
---- ----- -------- ----------------- -------------------------
New User2 new.user2 eurprd09.prod.outlook.com/f... 99 GB (106,300,44... aabbd762-f2d0-43af-a22b-ee94de87fb2e
WARNING: After you create a new mailbox, you must go to the Office 365 Admin Center and assign the mailbox a license, or it will be disabled after the grace period.
PS C:\> $pass = ConvertTo-SecureString "123456789AbCDEF0" -AsPlainText -Force
PS C:\> New-Mailbox -Name "New User3" -ImmutableId "fRBSX+IGQ0Smq3NCKrvP0g==" -PrimarySmtpAddress "new.user3@azure.skrubbeltrang.com" -Alias "new.user3" -FirstName "New" -LastName "User3" -DisplayName "New User3" -MicrosoftOnlineServicesID "new.user3@azure.skrubbeltrang.com" -Password $pass -ResetPasswordOnNextLogon:$false
Name Alias Database ProhibitSendQuota ExternalDirectoryObjectId
---- ----- -------- ----------------- -------------------------
New User3 new.user3 eurprd09.prod.outlook.com/f... 99 GB (106,300,44... 186b7461-dead-46f2-b7bf-6bcfc45129d1
WARNING: After you create a new mailbox, you must go to the Office 365 Admin Center and assign the mailbox a license, or it will be disabled after the grace period.
