Automating SSL Certificate Tasks in Exchange Server 2007 (Certificate Manager)

Troubleshooting Certificates in Exchange Server 2007 with Certificate ManagerExchange Server 2007 relies on digital certificates for securing SMTP, IIS (Outlook Web Access, Exchange ActiveSync), Outlook Anywhere, and server-to-server authentication. When certificates fail, mail flow, client connectivity, and mobile device synchronization can break. This article walks through common certificate-related problems in Exchange 2007, how to diagnose them using Certificate Manager and built-in tools, and practical remediation steps and best practices.

Overview: certificates used by Exchange 2007

Exchange 2007 commonly uses certificates for:

• TLS for SMTP (opportunistic or enforced TLS for mail transport).
• HTTPS for OWA, ECP, OAB, ActiveSync, Autodiscover (IIS/HTTP services).
• Client RPC-over-HTTP / Outlook Anywhere (encrypted RPC traffic over HTTPS).
• Server authentication for internal service-to-service authentication and federation scenarios.

Key certificate properties to verify:

• Subject / Subject Alternative Name (SAN) entries include all service names clients use (internal FQDNs, external names, autodiscover.domain.com, mail.domain.com).
• Validity period (not expired).
• Trusted chain: certificate issued by a CA trusted by clients and servers (intermediate CA chain present).
• Private key presence on the Exchange server.
• Intended purposes (Enhanced Key Usage: Server Authentication, Client Authentication where relevant).
• Correct bindings in IIS and Exchange services.

Common problems and immediate checks

1. Certificate expired or not yet valid

   • Check certificate validity dates in the certificate store or Exchange Management Console (EMC).
   • If expired: renew with the issuing CA and re-import/bind the renewed certificate.

2. Missing Subject Alternative Names (SAN) or wrong subject

   • Ensure SAN includes external hostnames (e.g., mail.domain.com) and internal names (e.g., server01.internal.domain.local) if clients use them.
   • Autodiscover requires autodiscover.domain.com in SAN for many clients.

3. Private key not present

   • Certificates must have an associated private key in the Personal store. Without it, Exchange cannot present the certificate.
   • Check in the Certificates MMC (Computer account → Personal → Certificates): certificates with private keys show a key icon and the phrase “You have a private key that corresponds to this certificate.”

4. Untrusted CA / Intermediate certificates missing

   • Clients will reject certificates if they can’t build a trust chain to a trusted root CA.
   • Ensure intermediate CA certs are installed in the Intermediate Certification Authorities store on Exchange servers and clients (or deployed via AD Group Policy).

5. Wrong bindings in IIS/Exchange services

   • The certificate must be bound to the Default Web Site (IIS) for HTTPS and assigned to Exchange services (IIS, SMTP, UM, POP, IMAP) as needed.
   • Use the Exchange Management Shell (EMS) to check/service assignment and IIS Manager to inspect site bindings.

6. Name mismatch errors (CN/SAN vs requested name)

   • Browsers and Outlook will warn when CN/SAN do not match the host name used by the client. Add missing names to SAN or change client configuration to the certificate’s valid name.

7. CRL/OCSP validation failures

   • Clients validate certificate revocation. If the CRL distribution points or OCSP responders are unreachable (firewall, connectivity), validation may fail.
   • Verify CRL/OCSP URLs in the certificate and ensure network access.

Tools for diagnosing certificate issues

• Certificate Manager (Certificates MMC snap-in, Computer account) — view cert properties, private key presence, validity, intended purposes.
• Exchange Management Console (EMC) — view and assign certificates to Exchange services.
• Exchange Management Shell (EMS) — detailed certificate commands:
  • Get-ExchangeCertificate — lists certificates and thumbprints, services assigned, expiration, subject.
  • Enable-ExchangeCertificate — assign services to a certificate.
  • New-ExchangeCertificate / Import-ExchangeCertificate — create/import certs.
  • Test-OutlookWebServices — checks Autodiscover and web services connectivity.
  • Test-ServiceHealth / Test-MapiConnectivity — check service health and client connectivity.
• IIS Manager — inspect site SSL bindings and certificate usage for the Default Web Site.
• OpenSSL or certutil — inspect certificate chains and details from command line.
• Browser developer tools / TLS scanning utilities — check server TLS configuration and presented certificate chain.
• Event Viewer — application/system logs for Schannel or Exchange-related TLS errors.

Step-by-step troubleshooting workflow

1. Reproduce the problem and gather symptoms

   • Identify exactly what is failing (OWA, mobile sync, Outlook Anywhere, SMTP TLS). Note error messages (certificate warnings, ⁄₅₀₀ errors, mail delivery failures).
   • Determine whether the issue affects all clients or a subset (internal vs external, specific OS/version).

2. Confirm certificate presence and validity on the Exchange server

   • Open Certificates MMC (Computer account → Personal → Certificates). Verify the certificate is present, not expired, and has a private key.
   • Run Get-ExchangeCertificate in EMS:

     
     Get-ExchangeCertificate | fl Thumbprint,Subject,NotAfter,Services 

   • Note the certificate thumbprint and which services it’s assigned to.

3. Check bindings and service assignments

   • For IIS: open IIS Manager → Default Web Site → Bindings → HTTPS. Ensure the correct certificate is selected.
   • In EMS, assign certificate to services if needed:

     
     Enable-ExchangeCertificate -Thumbprint <thumbprint> -Services IIS,SMTP 

     (When assigning SMTP, be cautious — enabling SMTP on the wrong cert may disrupt mailflow if clients rely on a different name.)

4. Confirm SAN/CN match client connection names

   • Compare the hostname clients use (e.g., mail.domain.com, autodiscover.domain.com, server.internal) with the certificate’s Subject and SAN entries.
   • If mismatched, decide to reissue a certificate with correct SANs or change client connection settings.

5. Validate trust chain and intermediates

   • On the server, open the certificate and view Certification Path. Ensure no “untrusted” or missing intermediate warnings.
   • Install missing intermediate CA certs into Intermediate Certification Authorities store.
   • Use certutil to verify chain:

     
     certutil -verify <path-to-cert.cer> 

6. Test CRL/OCSP reachability

   • From the Exchange server (and affected clients), attempt to access CRL Distribution Point URLs and OCSP responders in the certificate. Firewalls often block outbound HTTP to CRL locations.
   • If CRL checks are failing internally and cannot be fixed, consider publishing CRLs closer to clients or using a proxy — but avoid disabling revocation checks in production.

7. Look for Schannel and Exchange TLS errors

   • In Event Viewer under System and Application, review Schannel events (TLS handshake failures) and MSExchange Transport/MSExchange OWA events for certificate or TLS errors. Error codes can indicate name mismatch, unsupported protocol, or key exchange issues.

8. Test client access and mail flow

   • Use Test-OutlookWebServices to confirm Autodiscover and web services from the server’s perspective:

     
     Test-OutlookWebServices -Identity servername | fl 

   • Use a browser from outside to connect to OWA and inspect the certificate presented.
   • For SMTP, send mail and check protocol logs or use Openssl to simulate STARTTLS:

     
     openssl s_client -starttls smtp -connect mail.domain.com:25 -showcerts 

   • Confirm MX partners can establish TLS if required.

9. Reissue or import certificate if necessary

   • If the certificate is expired, missing SANs, or private key is lost, request a new certificate from your CA. For Exchange:
     • Generate a new CSR in the EMC or using New-ExchangeCertificate, including all SANs.
     • Submit to CA, receive certificate, then import and complete the pending request:

       
       Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path "C:rtsrt.cer" -Encoding byte -ReadCount 0)) Enable-ExchangeCertificate -Thumbprint <thumbprint> -Services IIS,SMTP 

     • Remove or disable old certificates if they conflict.

10. Post-change verification

    • Restart IIS (iisreset) if bindings changed. Restart transport service if SMTP changed.
    • Re-run Test-OutlookWebServices, Test-MapiConnectivity, and validate client connections and mail flow.
    • Monitor Event Viewer for new errors.

Examples of specific scenarios and fixes

• Scenario: External users receive certificate warnings in browser/Outlook
  Fix: Ensure the public-facing name (e.g., mail.domain.com) is present in SAN; bind certificate to IIS default site; ensure the certificate is issued by a public CA trusted by client devices.

• Scenario: Mobile devices fail to sync but desktop Outlook works internally
  Fix: Check if the Autodiscover/SAN for external name used by ActiveSync is missing or points to a name with a certificate mismatch. Ensure external DNS records and firewall/NAT allow access to the correct external hostname.

• Scenario: SMTP TLS fails with partners after certificate renewal
  Fix: Confirm new certificate has appropriate subject name used in SMTP TLS (many partners expect the cert CN to match advertised HELO/EHLO name). Ensure partner trusts issuing CA and the intermediate chain is present. Update Send/Receive connectors if they reference a certificate thumbprint.

• Scenario: “Private key is missing” after importing .cer file
  Fix: This means you imported only the public certificate. Re-import the certificate using the .pfx file that includes the private key (or complete the pending request from the original CSR on the server that generated it).

Best practices to avoid certificate problems

• Use SAN certificates that include internal and external names, plus autodiscover, to avoid multiple certs and name mismatches.
• Maintain a certificate inventory with expiration dates and automated renewal reminders at least 30–60 days before expiry.
• Use a trusted public CA for external-facing services; for internal-only services, use an internal Enterprise CA with Group Policy distribution of the CA certificate to clients.
• When renewing, perform staged rollouts and test services (OWA, ActiveSync, Outlook Anywhere, SMTP) before decommissioning the old cert.
• Deploy intermediate CA certificates to servers and clients to ensure a complete chain.
• Keep server time accurate (NTP) — clock skew can cause “not yet valid” or “expired” issues.
• Harden TLS settings and verify compatibility with clients (cipher suites and protocol versions), but maintain backward compatibility if older clients still in use.

Quick command cheatsheet

• List certificates and assignments:

  
  Get-ExchangeCertificate | fl Thumbprint,Subject,NotAfter,Services 

• Enable a cert for services:

  
  Enable-ExchangeCertificate -Thumbprint <thumbprint> -Services IIS,SMTP 

• Import a certificate (.pfx):

  
  Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path "C:rtsrt.pfx" -Encoding byte -ReadCount 0)) -Password:(ConvertTo-SecureString -String "P@ssw0rd" -AsPlainText -Force) 

• Verify Autodiscover/web services:

  
  Test-OutlookWebServices -Identity servername 

• Check SMTP STARTTLS with OpenSSL:

  
  openssl s_client -starttls smtp -connect mail.domain.com:25 -showcerts 

When to get vendor or CA support

• If a public CA reports issues with a certificate they issued (mis-encoded chain, missing intermediate) or a certificate uses unsupported algorithms.
• If partner MTAs refuse TLS and troubleshooting shows their handshake failures — involve the partner and exchange TLS logs.
• For complex multi-site, load-balanced, or reverse-proxy setups where certificate termination points are unclear.

Troubleshooting certificates in Exchange 2007 is largely a process of verifying the certificate itself (names, validity, private key, chain), confirming correct bindings to Exchange/IIS services, and ensuring clients can trust and reach CRL/OCSP endpoints. Using the Certificates MMC, Exchange Management Shell commands, IIS Manager, and simple network/TLS tests will resolve most issues.