Private SSL 202 - Enforcing HTTPS on Microsoft Exchange On-Premise & OWA

Microsoft Exchange Server remains a core communications hub for enterprises maintaining regulatory control over their messaging infrastructure. From corporate communications to sensitive attachments, internal mail flow demands strict transport encryption. However, many Exchange deployments operate within internal Active Directory namespaces (such as mail.company.local or exchange.internal), preventing administrators from procuring certificates through public authorities.

Defaulting to out-of-the-box self-signed certificates or running unmanaged configurations triggers persistent browser warnings across Outlook on the Web (OWA) and breaks background synchronization for desktop Outlook clients.

Deploying trusted internal SSL certificates from SecureNT resolves these issues by delivering automated, policy-compliant encryption across all Exchange virtual directories and mail routing endpoints.

Why Default Exchange Certificates Create Friction

During installation, Exchange Server provisions a self-signed certificate. While functional for basic inter-server testing, keeping this configuration active in daily operations causes severe disruption:

• Autodiscover Certificate Errors: Microsoft Outlook actively queries the Autodiscover service. An untrusted certificate prompts repeated security warnings on client machines, eroding employee trust and degrading helpdesk efficiency.

• Mobile Synchronization Failures: Mobile devices syncing via Exchange ActiveSync (EAS) generally refuse to communicate with endpoints using self-signed certificates, severing remote mail access.

• Audit and Compliance Non-Compliance: Regulated environments subject to HIPAA, PCI-DSS, or financial controls mandate audited certificate chains with centralized revocation mechanisms—criteria that self-signed setups fail.

Using SecureNT establishes a verified, organization-wide trust chain that eliminates user-facing warnings and ensures cryptographic integrity.

Architecture & Subject Alternative Name (SAN) Planning

Exchange Server handles multiple distinct roles under a single web service instance. A valid Exchange certificate must include all relevant internal hostnames in its Subject Alternative Names (SAN) extension:

• Primary FQDN / OWA: mail.company.local

• Autodiscover Endpoint: autodiscover.company.local

• NetBIOS Server Name: exchange-srv01 (if legacy internal systems interact via NetBIOS)

[ Internal Outlook / OWA User ]
                 │
                 │ HTTPS (TCP 443) - Trusted by Enterprise Root CA
                 ▼
[ Exchange Client Access Services (IIS Front-End) ]
                 ├── /owa (Outlook on the Web)
                 ├── /ecp (Exchange Admin Center)
                 ├── /autodiscover (Auto Configuration Engine)
                 └── /ews (Exchange Web Services)

Prerequisites

• Administrative privileges on the on-premise Exchange Server (Exchange 2016, 2019, or Subscription Edition).

• Access to the Exchange admin center (EAC) or Exchange Management Shell (EMS).

• The SecureNT Root CA certificate deployed to Active Directory domain machines via Group Policy Object (GPO).

Internal DNS records configured for both mail.company.local and autodiscover.company.local.

Step-by-Step Implementation Guide

Step 1: Generate the Certificate Request in Exchange Admin Center (EAC)

1. Open your browser and log into the Exchange admin center (https://localhost/ecp).

2. Navigate to Servers > Certificates, and click the + (Add) icon.

3. Choose Create a request for a certificate from a certification authority and click Next.

4. Enter a descriptive friendly name (e.g., Exchange_SecureNT_Cert_2026).

5. Select whether to request a wildcard certificate (leave unchecked if using specific SANs).

6. Click Browse to select the target Exchange Server storing the request.

7. Confirm the domains to include. Ensure both mail.company.local and autodiscover.company.local appear in the domain list.

8. Enter your organization details: Organization Name, Department, City/Locality, State, and Country.

9. Specify a shared network path to save the generated request file (e.g., \exchange-srv01\certs\exchange.req), then click Finish.

Step 2: Submit the CSR to SecureNT

1. Visit the SecureNT Intranet SSL website.

2. Submit the new Server Certificate request (File: exchange.req).

3. Select your internal Web Server profile and assign the certificate lifespan.

4. Approve and download the issued certificate (File: server.cer) alongside the intermediate CA chain (File: SecureNT CA-Bundle.cer).

Step 3: Complete the Pending Request in Exchange

1. Return to the Exchange admin center > Servers > Certificates.

2. Highlight your pending certificate request labeled Exchange_SecureNT_Cert_2026.

3. In the right-hand details pane, click Complete.

4. Enter the network path pointing to the downloaded certificate file (e.g., \exchange-srv01\certs\server.cer) and click OK.

5. The status of the certificate will shift from Pending Request to Valid.

Step 4: Assign Services to the SecureNT Certificate

To activate the certificate for encrypted traffic, bind it to the relevant Exchange services:

1. Select the completed certificate in EAC and click the Edit (Pencil) icon.

2. Select the Services tab on the left.

3. Check the boxes for:

• IIS (Powers OWA, ECP, ActiveSync, and Autodiscover)

• SMTP (Encrypts transport mail flow between internal servers)

4. Click Save.

5. When prompted to overwrite the existing default self-signed certificate, select Yes.

Alternative via Exchange Management Shell (EMS):

PowerShell

$Cert = Get-ExchangeCertificate -Thumbprint "PASTE_NEW_CERT_THUMBPRINT_HERE"
Enable-ExchangeCertificate -Thumbprint $Cert.Thumbprint -Services "IIS, SMTP"

Verification and Health Check

1. Open a browser on an internal domain workstation and navigate to https://mail.company.local/owa.

2. Confirm the presence of the lock icon and verify the certificate path validates up to SecureNT's Root CA without revocation errors.

3. From a domain-joined machine running Microsoft Outlook, hold down Ctrl, right-click the Outlook icon in the Windows notification tray, and select Test E-mail AutoConfiguration. Run the test against your internal mailbox to verify that Autodiscover and EWS return status 200 over an encrypted, trusted connection.

Enforcing HTTPS on Microsoft Exchange with SecureNT eliminates internal trust alerts, protects mail communications against eavesdropping, and secures your messaging infrastructure with verifiable enterprise cryptography.