Forum Discussion
Trouble Renewing self-signed Exchange 2019 certificate
I have an Exchange 2019 CU14 server whose self-signed certificate (for IIS and SMTP) has expired. I used the Get-ExchangeCertificate cmdlet to find the thumbprint for the expired certificate. However, when I use example from this page:
https://learn.microsoft.com/en-us/exchange/architecture/client-access/renew-certificates?view=exchserver-2019
to renew the certificate it does not work. Can anyone help me to solve this issue? Thank you. The cmdlet and the response is listed below.
Get-ExchangeCertificate -Thumbprint 64AB20ED34134811522D298904D135A25E6A86BD | New-ExchangeCertificate -Force -PrivateKeyExportable $true
The input object cannot be bound to any parameters for the command either because the command does not take pipeline
input or the input and its properties do not match any of the parameters that take pipeline input.
+ CategoryInfo : InvalidArgument: ([Subject]
CN...135A25E6A86BD
:PSObject) [New-ExchangeCertificate], ParameterBindingException
+ FullyQualifiedErrorId : InputObjectNotBound,New-ExchangeCertificate
+ PSComputerName : mail1..com
5 Replies
It's sad to see that no one replied here yet. I've just stumbled upon the same problem with an Exchange 2016 CU23 server.
In my case, it's a CA provided certificate I have to renew, but the issue is the same. As the method described above has also worked for me a couple of times and still is the documented procedure by Microsoft, one has to assume that this somehow has been broken by a recent security update. (Checking the current documentation for "New-ExchangeCertificate", there is only the parameter "Instance" that allows PipelineInput, and that is listed as "deprecated").
In any case, I have found a workaround. In reality, Exchange is not really "renewing" the old certificate, but creating a new certificate (or in my case, certificate signing request) based on the properties of the old one. The most important ones (from my perspective the only relevant) being the SubjectName and the Subject Alternate Names. So you can just read those values from the old cert and use them for the new one, like this:
$oldThumb = "DB3BE1841EED1D9DD5DCF18956BBABE1BF69056B" $oldCert = Get-ExchangeCertificate -Thumbprint $oldThumb $request = New-ExchangeCertificate -GenerateRequest -PrivateKeyExportable $true -FriendlyName "MSX-Certificate-2024-04-05" -DomainName $oldCert.DnsNameList.Unicode -SubjectName $oldCert.SubjectEMR88 : I assume you have fixed your issue on your own by now, but if not: for directly creating a new self-signed certificate, you would skip the "-GenerateRequest" parameter and you might not need the "FriendlyName", and you would not get a result you need to write into an $result variable, but apart from that, I think it should work the same way.
For me to get this totally working, I still need to get the new cert back from my CA, but I'm quite confident I was able to create a proper CSR.
Generally speaking, you wouldn't even need to base the new cert on the old one, but as the subject name is configured in a couple of places (hybrid setup, I think), you wouldn't want the need to also change that.
You got it all you need to add to export your certificate request is :
[System.IO.File]::WriteAllBytes('C:\yourpath\renew.req', [System.Text.Encoding]::Unicode.GetBytes($request))
- Thanks for your post. Although no one replied, I did find the solution using Powershell.
$newAuthCertificate = New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName @()
SAY N (No) to overwriting the existing SMTP certificate
Set-AuthConfig -NewCertificateThumbprint $newAuthCertificate.Thumbprint -NewCertificateEffectiveDate (Get-Date).AddHours(49)
You may find this article helpful:
https://learn.microsoft.com/en-us/answers/questions/597361/how-to-renew-microsoft-exchange-server-auth-certifEMR88 Well, the Auth certificate from my understanding is something else than the one used for IIS and SMTP, although when only using self-signed certs it might not matter to Exchange. I think the important thing which you then also used is that you may just generate a new certificate and don't necessarily need to "renew" the old one.
Again, from my understanding: For a regular webserver, you can just let the CA renew the certificate and use that with your given private key (which obviously can't work for self-signed certs when there is no CA involved). But in Exchange this seems not to be possible even for CA certs. Which is not a problem once you have figured out how it works.
But the important thing is that we both found a solution!
