Skip to content
Andy Kemp Consulting

Troubleshooting#

Every Exchange command the app runs, and every error, is in the log panel and in C:\ExchangeCertManager\Logs. Start there.

Connect fails#

"The WinRM client cannot process the request" or "Access is denied"

  • Use the server's FQDN, not an IP address or a load-balanced name. Kerberos needs the host's real name.
  • Check the account has Organization Management, or the Exchange Server Certificates role.
  • Check http://<server>/PowerShell isn't blocked by a firewall or proxy between you and the server.

"The connection to the specified remote host was refused"

The PowerShell virtual directory or its app pool isn't working. On the Exchange server:

Get-PowerShellVirtualDirectory | fl Server, InternalUrl, *Authentication*
Get-WebAppPoolState MSExchangePowerShellAppPool

Kerberos (Windows authentication) must be enabled and the app pool started.

Creating a request fails#

  • "The certificate request couldn't be generated": check the subject. Country must be a two-letter code (for example GB), and names must be valid DNS names.
  • Public CA rejects the CSR: the CSR includes an internal name such as .local. Remove it and create the request again.

Completing a request fails#

  • "The certificate can't be imported because a pending request couldn't be found": you're completing it on a different server from the one that created the request. Pick the pending request on the right server.
  • Chain errors after completing: install the CA's intermediate certificates on the server, or complete with a .p7b that includes the chain.

Export or deploy says the key isn't exportable#

The certificate's private key was created or imported as non-exportable, so Exchange can't copy it. Certificates created by this app, and PFX imports through it, are exportable. For an existing one, request a new certificate, or import the original .pfx on each server with Import PFX.

Let's Encrypt HTTP validation fails#

"Let's Encrypt couldn't validate mail.contoso.com: … 404"

Let's Encrypt reached a web server but not the challenge file.

  • Check the web root for each server is the Default Web Site's physical path (IIS Manager > Default Web Site > Basic Settings).
  • Check the name in public DNS points at Exchange (or your load balancer) and not at something else.
  • If a reverse proxy or WAF sits in front, allow /.well-known/acme-challenge/ on port 80 through to Exchange.

"… Connection refused" or "Timeout"

Port 80 isn't reaching Exchange from the internet. Open it to Exchange, at least for /.well-known/acme-challenge/, or use DNS validation.

"… redirect" errors

Something before IIS (a load balancer or proxy) redirects port 80 to HTTPS. Let the challenge path through on HTTP. The app already turns off IIS's own redirect for the challenge folder.

Automatic renewal didn't run#

  1. Open Task Scheduler and find Exchange Certificate Manager - Let's Encrypt renewal. Check its last run result.
  2. Check the app is still at the path in the task's action. If you moved it, register the task again from the Let's Encrypt page.
  3. Check the task account's password hasn't changed or expired.
  4. Read that night's log in C:\ExchangeCertManager\Logs.

To try it straight away, run ExchangeCertManager.exe --renew-acme --force as the task account.

Mail flow to Microsoft 365 stopped after a renewal#

A connector's TlsCertificateName still names the old certificate. Run the Mail flow health check: it names the connector and shows how to fix it.