This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Namespace planning

In Exchange the suggested namespaces you’ll need to worry about for a basic cert for OWA and Outlook would be:

• autodiscover.domain.com
• mail.domain.com

For my lab, I want to concentrate on a SAN cert that handles just those two names and nothing else. Let's Encrypt only allows up to 100 SANs on a certificate, so be aware of that limitation if you’re planning a very complicated Exchange deployment.

There are a number of articles out there these days that talk about this. I’m a big fan of Ross Smith IV’s article and also this article by Paul Cunningham, a Microsoft MVP.

For a lab environment, setting your URLs so that all of them point to mail.domain.com with the additional autodiscover.domain.com names will make your life much easier. Just having only two SANs will make your certificate requests and DNS settings less complex.

For a more detailed tutorial on this, Gareth does a great job with this article. Anyway, if you’ve followed my advice, you only need a certificate for mail.domain.com and autodiscover.domain.com. If you’re planning something else, please use the above to make sure those other domains are added as SANs when you create your certificate request. Especially if you’re planning to have regional URLs in the bound model described by Ross Smith IV.

Running the client

Choose the domains that you want to generate the certificate for. Note that these have to be FQDNs. That means no internal server names or domain suffixes. You can specify a maximum of 100 domains in a certificate.

Assumptions made in this example

• We want to generate the certificate for three domains
  • mail.example.com
  • webmail.example.com
  • autodiscover.example.com
• mail.example.com will be the common name, hence we put it first
• OWA is running in the Default Web Site of IIS with SiteId 1.
• We want to enable the certificate for SMTP and IMAP

Unattended

Without Central Certificate Store

wacs.exe --target manual --host mail.example.com,webmail.example.com,autodiscover.example.com --certificatestore My --installation iis,script --installationsiteid 1 --script "./Scripts/ImportExchange.ps1" --scriptparameters "'{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'"

With Central Certificate Store

wacs.exe --target manual --host mail.example.com,webmail.example.com,autodiscover.example.com --store centralssl --centralsslstore "C:\Central SSL" --installation iis,script --installationsiteid 1 --script "./Scripts/ImportExchange.ps1" --scriptparameters "'{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'"

Interactive

• Create certificate with advanced options
• Manually input host names
• [http-01] Self-host verification files
• Create or update https bindings in IIS
• Would you like to add another installer step? (y/n): Y
• Run a custom script
• Would you like to add another installer step? (y/n): N
• Choose site to create new bindings: Default Web Site (or where ever OWA is at)
• Enter the path to the script that you want to run after renewal: ./Scripts/ImportExchange.ps1
• Enter the parameter format string for the script: '{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'

Verification

To make sure all is working properly, I’d encourage you to use the Microsoft's Remote Connectivity Analyzer. The Autodiscover and ActiveSync Autodiscover tests are really useful for testing this out. With Outlook 2016 requiring the use of Autodiscover to connect to Exchange, verifying that this works properly is an important step is making sure your environment is setup correctly.

References

Assign certificates to Exchange services

Import certificates into Exchange

Add MIME Type